CognitiveOps/cogniops-resilient-devsecops

# CogniOps — 面向弹性 DevSecOps 的有限自主认知 AI Agent [](https://github.com/CognitiveOps/cogniops-resilient-devsecops/actions/workflows/ci.yml) [](https://github.com/CognitiveOps/cogniops-resilient-devsecops/releases) [](evaluation/results/) [](docs/showcase-evidence.md) [](CITATION.cff) [](https://www.python.org/) [](LICENSE) ## 问题 现代 DevSecOps pipeline 涵盖了云 CI/CD、边缘部署、回滚弹性、加密验证以及人工审批（human-in-the-loop）。在严格的安全约束下协调这些问题非常困难： - 部署回滚必须迅速执行，且不能违反策略。 - 边缘 OTA 更新必须经过验证，即使在资源受限的硬件上也是如此。 - 认知 agent 可以提出优化建议，但绝不能为了刷指标而作弊（game the metrics）或绕过安全护栏（guardrails）。 CogniOps 将这些问题视为一个统一的控制问题：一个**认知控制平面**负责监督一个**确定性基座（deterministic substrate）**，具备受限的操作、结构化的输出以及因果推理能力。 ## 架构 ``` flowchart TB subgraph control["Cognitive Control Plane"] runtime["Runtime Agent\nperceive → plan → guard → act\nmitigate"] design["Design-Time Agent\nmetrics → causal graph → proposal\nimprove"] security["Security Compliance Agent\nfeed → audit → proposal\naudit"] end subgraph substrate["Deterministic Substrate"] direction LR gh["GitHub Actions"] opa["OPA"] pqc["PQC / ML-DSA"] cr["Cloud Run"] bq["BigQuery"] end runtime -->|bounded actions| substrate design -->|validated proposals| substrate security -->|compliance proposals| substrate style control fill:#f0f7ff,stroke:#0969da style substrate fill:#f6f8fa,stroke:#656d76 ``` ### 设计原则 - **运行时绝不修改结构** — 不涉及 PR，也不修改 YAML。 - **设计时绝不执行缓解措施** — 仅提供建议，在提升（promotion）前必须经过验证。 - **LLM 仅用于规划 agent** — 所有其他模块均为确定性模块。 - **每次 LLM 调用都有兜底方案** — 安全默认值（NO_OP）、审计日志、schema 验证。 - **受限的操作面** — 仅支持 `NO_OP`、`BLOCK`、`ROLLBACK`、`QUARANTINE`、`ESCALATE`。 ## 功能说明 | 场景 | 关注点 | 测量指标 | |----------|---------|------------------| | **S1** | 云 CI/CD | 部署前置时间 (TTD)、变更失败率 (CFR)、部署频率 (DF) | | **S2** | 边缘 OTA | 下载延迟 (TDL)、部署成功率 (DSR)、边缘 TTD | | **S3** | 弹性 | 云端和边缘故障的平均检测/恢复时间 (MTTD/MTTR) | | **S4** | PQC 验证 | 验证时间 (TTV)、验证成功率 (VSR)、失败检测率 (FDR) | | **S5** | 可解释性 | 审批延迟 (AL)、审计完整率 (ACR) | | **SS1** | 策略审计 | 确定性 OPA 策略案例的 CFR、FDR | | **SS2** | 自适应威胁 | 注入完整性/运行时故障下的 MTTD、AL、ACR | ## 证据 该系统基于**跨越 54 项对比的 5,833 个指标样本**（阶段 1）以及随后的**阶段 2**修复流程进行了评估。详见 [`docs/showcase-evidence.md`](docs/showcase-evidence.md) 中的详细证据。 ### 部分结果 | 场景 | 指标 | 提升 | 效应量 | 备注 | |----------|--------|------------:|------------:|------| | S3 云端 | MTTD | **−65%** | d = −0.94 (大) | 运行时 agent 比静态阈值检测并升级（escalate）得更快 | | S3 云端 | MTTR | **−32%** | d = −0.47 (小) | 完整变体（运行时 + 设计时）恢复得更快 | | SS2 | AL | **−23%** | d = −1.25 (大) | 设计时 agent 减少了人工审批延迟 | | S4 | FDR/VSR | 100% | — | 所有被篡改的 artifact 均被检测出；所有有效签名均通过验证 | | S1 | CFR | 0% | — | 在基线或 agent 变体中均未出现部署失败 |  *阶段 1 效应量热图（涵盖 8 个场景的 54 项对比）。蓝色 = 提升，红色 = 恶化。完整表格请参见 [docs/showcase-evidence.md](docs/showcase-evidence.md)。* ### 客观的局限性 评估也暴露了实际的开销成本： - **S3 边缘 MTTR** 在运行时 agent 介入下恶化了约 150%，这是由于 Cloud Run 的往返延迟所致。 - **S5 AL** 恶化了约 200%，因为认知 `/decide` 调用增加了约 23 秒的系统开销。 - 设计时 agent 自主提出了基座调优建议，改善了原始指标，但其中一些提升是休眠门控（sleep-gate）产生的假象，而非真正的延迟降低（已作为 Goodhart 定律记录在案）。 这些权衡均已被如实报告，未作隐瞒。详见 [`docs/showcase-evidence.md`](docs/showcase-evidence.md)。 ### 可复现性 评估产物已进行版本控制并带有时间戳： - 原始指标导出：[`evaluation/results/raw/`](evaluation/results/raw/) - 统计学对比：[`evaluation/results/analysis/`](evaluation/results/analysis/) - 实验运行脚本：[`evaluation/scripts/run_experiment.py`](evaluation/scripts/run_experiment.py) - 标记快照：[`v0.1.0-alpha`](https://github.com/CognitiveOps/cogniops-resilient-devsecops/releases/tag/v0.1.0-alpha) 每份原始导出文件均包含 CSV schema 和 BigQuery 表元数据。分析文件包含上表中使用的 Mann–Whitney U 统计量、Cohen's *d* 效应量以及 bootstrap 置信区间。 ## 技术栈 | 层级 | 组件 | |-------|-----------| | Agent 框架 | Google ADK (`LlmAgent`)、Vertex AI Gemini 2.0 Flash | | 语言 | Python 3.12、类型提示、Pydantic v2、FastAPI、pytest | | CI/CD | GitHub Actions、Workload Identity Federation (OIDC) | | 基础设施 | Terraform — Artifact Registry、Cloud Run、BigQuery、IAM | | 安全 | OPA (Rego)、通过 liboqs 实现的后量子 ML-DSA (FIPS 204) | | 可观测性 | BigQuery `agent_metrics.runs`、结构化 JSON 日志 | ## 仓库结构 ``` ├── baseline/ # Deterministic DevSecOps scenarios S1–S5, SS1–SS2 ├── runtime-agent/ # ADK runtime agent: perceive → plan → guard → act ├── design-agent/ # ADK design-time agent: metrics → causal graph → proposal ├── security-agent/ # ADK compliance agent: feed ingestion → audit proposal ├── evaluation/ # 2-axis evaluation framework, SQL, plots, tests ├── infra/ # Terraform IaC ├── security/ # OPA policies ├── functions/ # Cloud Functions for metrics ingest ├── docs/ # Architecture, guardrails, evaluation evidence └── scripts/ # Integration and dispatch scripts ``` ## 快速开始 ``` # 克隆 git clone git@github.com:CognitiveOps/cogniops-resilient-devsecops.git cd cogniops-resilient-devsecops # 创建 virtual environment python -m venv .venv . .venv/bin/activate # or .venv\Scripts\activate on Windows # 安装 dependencies pip install -r requirements.txt # 运行 tests pytest ``` 运行完整场景需要一个配置了 Workload Identity Federation 的 GCP 项目。详细设置请参见 [`docs/thesis-setup.md`](docs/thesis-setup.md)（保留自原始论文文档）。 ## 意义与价值 这项工作展示了： - 如何构建一个**安全第一的认知 agent**，具备显式的护栏和受限的操作。 - 如何**将确定性基座与 AI 推理分离**，从而使故障具备可解释性。 - 如何**利用统计学效应量（而不仅是准确性）严格评估 agent 系统**。 - 如何**客观地报告局限性** — 包括 agent 表现得更差的情况。 ## 论文 Yanna Koutroumpi，*“面向边缘环境的弹性 DevSecOps 认知 AI Agent”*，硕士论文，2026 年。 注：软件实现强调**有限自主性** — 每一个操作都被限制在一个小型的确定性操作面上，并由护栏进行验证。 ## 未来工作 本次发布是论文基线的稳定快照。评估工作揭示了具体的扩展方向： - **边缘本地推理** — 将运行时 agent 的推理移至边缘（量化 Gemma / 蒸馏分类器 / 编译规则引擎），以消除导致 S3 边缘 MTTR 占主导地位的 Cloud Run 往返延迟。 - **多 agent 协作** — 通过协商协议协调运行时、设计时和安全 agent，而不是让它们独立运行。 - **情景记忆与自学习** — 将 `runtime_decisions` 和 metric 追踪反馈给 agent，以闭环实现持续改进。 - **扩展场景覆盖** — 增加供应链安全、多云部署和跨司法管辖区合规场景。 - **渐进式信任提升** — 基于积累的安全运行记录，形式化自动跨越 影子（shadow） → 建议（advisory） → 强制（enforce）模式的演进。 - **跨组织评估** — 将基座移植到 GitLab CI、Azure DevOps 和 AWS，以测试架构的可移植性。 ## 致谢 这项工作是在西阿提卡大学 [人工智能与深度学习硕士项目](https://aidl.uniwa.gr/) 攻读硕士学位论文 *“面向边缘环境的弹性 DevSecOps 认知 AI Agent”* 期间完成的。本仓库的代码将其实现为一个具有确定性护栏的**有限自主性**系统。 - **论文导师：** [Christoforos Kachris 教授](https://www.linkedin.com/in/christoforos-kachris-69b70b15/) ## 许可证 MIT — 详见 [LICENSE](LICENSE)。

标签：DevSecOps, 上游代理, 人工智能代理, 后量子密码学(PQC), 学术研究, 安全规则引擎, 策略引擎(OPA), 边缘计算, 运维自动化