文章总结： 该文解读美国国防部cATO指南，指出其通过DevSecOps流水线将合规审查从静态检查转变为持续授权运行。核心在于安全左移、机器取证及评估对象转向团队与机制。结合国内军工物理隔离现状，建议利用SBOM等机器证明实现跨网互信与离线反馈，以破解合规瓶颈并提升交付效能。 综合评分： 86 文章分类： 技术标准,安全建设,解决方案,安全开发

他山之石：从DoD cATO（持续授权）指南看军工软件合规交付的破局之路

AI与代码安全

2026年3月11日 08:57 北京

编者荐语：

技术交流及商务合作请联系13381155803【微信同步】

以下文章来源于软件研发之DevOps ，作者余仁

软件研发之DevOps .

在研发过程中，我们怎么做才能真正的提高效能，从而从一个成本中心逐步转变成与业务一起发展的价值中心，为此，该号将会从敏捷、DevOps实践等维度出发，阐述我自己的心得体会，共同学习提高。

在强监管、高涉密的行业（如军工、国防、关键信息基础设施等），软件研发团队最痛苦的往往不是攻克技术难关，而是面对漫长、僵化的安全审查和上线审批（即国内常说的等保测评、软测或上线前安全审查）。

大洋彼岸的美国国防部（DoD）同样面临着这个问题。在推进其软件现代化战略时，DoD 坦言：“Many DoD Components identify obtaining an Authorization to Operate (ATO) as the longest step in developing and deploying software. ”（许多国防部组件认为获得授权运行（ATO）是开发和部署软件中最漫长的一步。）

为了在对抗日益激烈的网络环境中保持优势，DoD 提出必须“deliver resilient software capability at the speed of relevance. ”（以相关的速度交付具备韧性的软件能力。）为此，DoD 官方发布了《持续授权实施指南》（Continuous Authorization Implementation Guide）。这份指南的核心思想是通过高度的自动化和流程重塑，将“合规审查”从一个阻碍上线的关卡，变成一条持续运转的流水线。

虽然由于两国体制、网络架构和保密规定的差异，我们无法（也绝不能）全盘照搬 DoD 的做法，但这套标准中关于“安全左移”、“机器取证”和“信任前置”的理念，对国内破局“合规卡脖子”困境具有极大的启发意义。

1. 什么是 cATO（持续授权）？从“静态打卡”到“动态信任”

在传统的 ATO 模式下，安全评估是一个“特定时间点”（point-in-time）的切片动作。系统上线前突击检查，一旦通过，往往就“万事大吉”，直到下一次大版本更新。

cATO 彻底颠覆了这种模式。指南中给出了明确定义：

“cATO is the state achieved when the organization that develops, secures, and operates a system has demonstrated sufficient maturity in their ability to maintain a resilient cybersecurity posture that traditional risk assessments and authorizations become redundant.”

持续授权运行（cATO）是一种状态，当负责开发、保护和运营系统的组织已经证明其具备足够成熟的能力来维持弹性网络安全态势时，传统的风险评估和授权就变得多余了。

这意味着，cATO 奖励的是“优等生”。只要你的团队、流程和底层平台被证明是高度成熟且安全的，你就可以持续不断地发布软件。“A cATO moves away from a control assessment point-in-time approach to focusing on continuous risk determination and authorization through demonstrated continuous assessing, monitoring, and risk management. ”（cATO 摆脱了特定时间点的控制评估方法，转而专注于通过已证明的持续评估、监控和风险管理来进行持续的风险确定和授权。）

2. 达成 cATO 的三大核心能力

要获得这种“免检通行证”，组织必须向授权官员（AO）证明其具备三大核心能力：

为了实现 cATO，授权官员（AO）必须能够证明三大核心能力：

• 对系统边界内关键网络安全活动的持续可见性以及对风险管理框架（RMF）控制的强大持续监控；
• 进行主动网络防御以实时响应网络威胁的能力；
• 以及采用和使用获批的 DevSecOps 参考设计。

此外，指南特别强调了软件供应链安全（SSSC）的重要性，指出采用获批的流水线对于“support the creation of a software bill of materials (SBOM) ”（支持创建软件物料清单（SBOM））至关重要。

3. 落地引擎：将安全基线刻进“流水线”

cATO 的落地绝不仅是一纸政策，它高度依赖于现代化的底层技术基础设施——软件工厂 (Software Factory)。

指南指出，软件工厂必须用机器和代码来代替人工检查：

自动化拦截：”Automation that includes at least one DevSecOps pipeline with automated guardrails and control gates that collect evidence for making continuous risk assessments and determinations during software development “（自动化，至少包括一条带有自动化护栏和控制网关的 DevSecOps 流水线，用于在软件开发期间收集证据以进行持续风险评估和确定。）

态势感知：”Built-in dashboards and automated alerts for monitoring and managing the risk in production “（用于监控和管理生产中风险的内置仪表板和自动警报。）

这意味着，安全规范不再是一本放在抽屉里的厚厚手册，而是变成了流水线上的一道道“关卡（Control Gates）”。代码扫描不过关？机器直接拦截，无需人工介入。

4. 评估范式的转变：从“查系统”到“查机制、查人”

这是对国内审计合规部门最具启发的一点。既然系统每天都在几十次地自动发布，审查特定版本的代码已经毫无意义，那么评估的重点就必须转移到制造软件的“机器”和“团队”上。

这种评估方法是一个根本性的转变，从对组织遵守安全控制情况的特定时间点评估，转变为对组织在整个应用程序生命周期中持续管理风险的准备状态进行定期评估。

对于人员的评估尤为关键：”The objective for assessing the DevSecOps teams is to build trust in the team executing the development, performing the security analysis, and the risk management functions. “（评估 DevSecOps 团队的目标是建立对执行开发、执行安全分析和风险管理职能的团队的信任。）换句话说，cATO 授权的是一个“靠谱的团队和靠谱的流水线”，只要是这个组合产出的软件，天然就具备可信度。

5. 典型应用场景与本土化落地的现实思考

指南给出了两种典型的应用场景（Use Cases），在将这些场景映射到国内军工和高密级网络环境时，我们必须保持清醒的现实思考。

场景一：在 DevSecOps 平台边界内部署软件 (Use Case 1)软件工厂本身已经有 ATO，开发出的软件直接部署在工厂自己的生产环境里 。这种情况在国内的低密级政务云或企业内部非密办公网中是完全可以借鉴的，即“研发运营一体化”。

场景二：跨边界交付 (Use Case 2) 与物理隔离的挑战这是军工场景下最普遍的情况：”Software is developed by a software factory that already has an ATO, but the software is deployed into another environment (e.g., a weapon system) with its own ATO… “（软件由已经拥有 ATO 的软件工厂开发，但软件被部署到另一个拥有自己 ATO 的环境中（例如，武器系统）…）

这里出现了最大的本土化分歧点。DoD 在指南中提出，为了实现这种跨边界的持续授权：必须达成协议以将软件跨越边界传递，并随后将结果和反馈传回软件工厂。DoD 的理想状态是生产环境（哪怕是武器系统）能够将运行时的安全数据、威胁情报反馈回开发环境，形成闭环。

现实思考：在目前的国内军工场景下，这种“直连开发测试环境的反馈闭环”几乎是无法实现的。由于极其严格的保密规定，涉密生产环境（如武器装备运行网络、高密级指挥网）与开发测试环境之间通常存在严格的物理隔离（Air-Gapped）。低密级网向高密级网可能只能通过单向光闸进行受限传输，而高密级网的数据（即 DoD 所谓的“反馈与结果”）绝对不允许直接流回低密级的开发环境。

因此，在本土化落地时，我们不能强求实时的自动化网络闭环，而应借鉴其“互信互认”的思想：

制品的跨网带入：开发环境的流水线在出包时，不仅输出二进制文件，必须同时输出自动化机器生成的安全扫描报告、合规证明和 SBOM（软件物料清单）。高密级生产环境在接收时，通过验证这些“机器签名”的物料，实现免二次代码级审计的“快速通行”。

离线的反馈机制：生产环境的安全事件和日志，在经过严格的人工脱密审查后，以周期性、离线的方式（如光盘导入）反馈给开发团队，用于指导下一版本的安全左移。

结语

美国国防部的 cATO 机制向我们展示了一个美好的愿景：用机器的自动化信任代替人工的流程消耗。虽然在我国军工等特殊场景下，由于网络隔离的红线，我们无法实现完美的端到端自动化流转，但其核心要义——“将安全规则固化在平台中”、“评估体系向信任人员和机制转变”、“提供机器生成的自证材料（SBOM等）”——完全可以成为我们重塑安全合规审批流程、提升软件交付战斗力的重要指南针。

需要完整版DoD发布的cATO的实施指南文件的同学，请在关注微信公众号后，通过对话框中输入:cato。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：AI与代码安全 《他山之石：从DoD cATO（持续授权）指南看军工软件合规交付的破局之路》