feat(Cybersecurity): add DependencyAwarePatchScheduling benchmark

[oushihsabiy]

Adds an executable dependency-aware cybersecurity patch scheduling benchmark with deterministic instances, independent feasibility verification, risk-based scoring, bilingual documentation, NIST/CISA provenance, calibrated baselines, and Frontier unified metadata.

[github-actions]

🤖 AI Code Review (gemini-3-flash-preview)

🇬🇧 English Analysis

1. Executive Summary

• Core Purpose: This PR introduces a new cybersecurity benchmark titled "Dependency-Aware Cybersecurity Patch Scheduling." It is a complex optimization problem designed to evaluate an agent's ability to schedule software patches while balancing security risks (vulnerability exposure) against operational constraints (maintenance windows, resource limits, and service downtime).
• Modified File Structure & Modifications:
  • benchmarks/Cybersecurity/DependencyAwarePatchScheduling/README.md: Provides the high-level overview, objective rationale, and execution commands (Local & Docker).
  • benchmarks/Cybersecurity/DependencyAwarePatchScheduling/README_zh-CN.md: Simplified Chinese translation of the README.
  • benchmarks/Cybersecurity/DependencyAwarePatchScheduling/Task.md: Detailed technical specification for the candidate, including scheduling semantics, objective function math (microunits/PPM), and Input/Output JSON schemas.
  • benchmarks/Cybersecurity/DependencyAwarePatchScheduling/Task_zh-CN.md: Simplified Chinese translation of the Task specification.

2. AI Content Analysis

• Estimated AI Component: 35%
• Reasoning & Evidence:
  • Standardized Schemas: The JSON Input/Output schemas in Task.md follow a highly structured, boilerplate format typical of AI-generated documentation for programming tasks.
  • Deterministic Math Patterns: The use of "microunits" and "parts-per-million (PPM)" to ensure deterministic integer arithmetic is a common "best practice" suggested by AI when prompted to design benchmarks that avoid floating-point errors.
  • Domain Specificity: Despite the boilerplate structure, the references to NIST SP 800-40 and CISA BOD 22-01, combined with the specific logic of "exclusive_change" assets and "maintenance_windows," suggest significant human domain expertise or very high-quality prompt engineering.

3. Engineering & Economic Assessment

• Engineering Reality Check: This is a production-grade problem. Unlike "toy" scheduling tasks (like simple Job Shop Scheduling), this models real-world enterprise IT constraints: transitive dependencies (Patch A needs Patch B), maintenance windows (Patching only at 2 AM), and resource contention (only 2 sysadmins available). It correctly identifies that patching is an economic trade-off, not just a "complete all tasks" problem.
• Economic Value: High. In a real-world setting, optimizing this schedule directly reduces the "Mean Time to Remediate" (MTTR) for critical vulnerabilities, which has a direct correlation with reducing the financial impact of potential data breaches. It also optimizes operational costs by respecting maintenance budgets.

4. Quality Assurance

• Verification & Testing:
  • frontier_eval Integration: Yes.
  • task_name: DependencyAwarePatchScheduling
  • Execution & Dependencies: The README.md clearly documents the execution commands for both local Python environments and Docker-based environments (using a specific python:3.12.11-slim-bookworm image).
• Documentation Quality: High. The documentation is comprehensive and provides dual-language support.
  • Redundancy Note: There is significant verbatim overlap between the "Evaluation Design" in the README and the "Constraints and Objective" in the Task file. While helpful for standalone reading, it increases the maintenance burden for future updates.
• Organizational Structure: The structure is logical and follows the established benchmark repository pattern (Task, Scripts, Verification).

5. Security & Privacy Check

• Sensitive Files: Clean. No .env, API keys, or IDE-specific files (.vscode/) were detected in the diff.
• Absolute Paths: None detected. The execution commands and file references use relative paths or standard module imports.

---

🇨🇳 中文分析

1. 摘要

• 核心目的: 此 PR 引入了一个名为“依赖感知的网络安全补丁调度”的新网络安全基准测试。这是一个复杂的优化问题，旨在评估智能体在平衡安全风险（漏洞暴露）与运营约束（维护窗口、资源限制和服务停机时间）之间进行补丁调度的能力。
• 修改的文件结构与变更摘要:
  • benchmarks/Cybersecurity/DependencyAwarePatchScheduling/README.md: 提供了高层概述、目标理由以及执行命令（本地和 Docker）。
  • benchmarks/Cybersecurity/DependencyAwarePatchScheduling/README_zh-CN.md: README 的简体中文翻译。
  • benchmarks/Cybersecurity/DependencyAwarePatchScheduling/Task.md: 候选程序的详细技术规范，包括调度语义、目标函数数学逻辑（微单位/PPM）以及输入/输出 JSON Schema。
  • benchmarks/Cybersecurity/DependencyAwarePatchScheduling/Task_zh-CN.md: 任务规范的简体中文翻译。

2. AI 成分分析

• 预估 AI 含量: 35%
• 判断依据与证据:
  • 标准化 Schema: Task.md 中的 JSON 输入/输出 Schema 遵循高度结构化的模板格式，这是 AI 生成编程任务文档的典型特征。
  • 确定性数学模式: 使用“微单位 (microunits)”和“百万分之一 (PPM)”来确保确定性整数算术，是 AI 在被要求设计避免浮点误差的基准测试时常用的“最佳实践”。
  • 领域专业性: 尽管存在模板化结构，但对 NIST SP 800-40 和 CISA BOD 22-01 的引用，结合“互斥变更 (exclusive_change)”资产和“维护窗口”的具体逻辑，表明了显著的人工领域专业知识或高质量的提示词工程。

3. 工程与经济评估

• 工程现实检验: 这是一个生产级别的问题。与简单的“玩具型”调度任务（如简单的作业车间调度）不同，它模拟了现实世界的企业 IT 约束：传递依赖（补丁 A 需要补丁 B）、维护窗口（仅在凌晨 2 点打补丁）和资源竞争（仅有 2 名系统管理员可用）。它正确地指出补丁管理是一种经济权衡，而不仅仅是“完成所有任务”。
• 经济价值: 高。在现实环境中，优化此调度直接缩短了关键漏洞的“平均修复时间 (MTTR)”，这与减少潜在数据泄露的财务影响直接相关。它还通过遵守维护预算来优化运营成本。

4. 质量保证

• 验证与测试:
  • frontier_eval 集成: 是。
  • task_name: DependencyAwarePatchScheduling
  • 运行与依赖: README.md 清晰地记录了本地 Python 环境和基于 Docker 环境（使用特定的 python:3.12.11-slim-bookworm 镜像）的执行命令。
• 文档质量: 高。文档内容详尽并提供双语支持。
  • 冗余说明: README 中的“评测设计”与 Task 文件中的“约束与目标”部分存在大量逐字重合。虽然方便独立阅读，但增加了未来更新的维护负担。
• 组织结构: 文件组织逻辑清晰，遵循既有的基准测试仓库模式（Task、Scripts、Verification）。

5. 安全与隐私检查

• 敏感文件: 未发现异常。Diff 中未检测到 .env、API 密钥或 IDE 特定文件（如 .vscode/）。
• 绝对路径: 未检测到。执行命令和文件引用均使用相对路径或标准模块导入。