大音大象,决胜战场!美军软件现代化回顾总结之三:核心机制

*微信订阅号推送规则更新，星标空天界，读懂政策、把握趋势、链接生态

《空天防务观察》导读：军用软件，正成为一切现代国防和军事活动的核心要素，在先进国家中，软件与驻留运行的平台和硬件解耦，软件模块高可互用，软件更新敏捷、隔空投送、任务中战斗中更新……然后，任务功能软件（如采用新一代人工智能技术的任务自主性软件）与平台载具的飞行、航行、行驶、机电运行管控……等运行功能软件也解耦。

软件，看不见，摸不着，“运动”起来才见效。但它，大音希声，于无声处藏惊雷；大象无形，居无相处演世界。军用软件及其科研、生产、应用、迭代或演进的工具与模式，正在成为未来战争的决胜要素。

本号先前曾先后发布李亮 ¦ 美军软件现代化回顾总结之一：支柱（李亮，2025年9月12日，点击题名可直接访问）和李亮 ¦ 美军软件现代化回顾总结之一：支柱（刘宇石，2025年11月25日，点击题名可直接访问），分别分析了美军推动软件现代化的五大支柱、美军“软件工厂”面临的主要核心问题。如果说支柱是骨架，那么本文探讨的核心机制就是让这幅骨架活起来的血肉。

很多人认为美军软件现代化的核心机制就是基于“开发、安全和运维一体化”（DevSecOps）方法构建软件敏捷开发流程，也就是“计划、编码、构建、测试、发布、部署、运行、监控、反馈”的敏捷软件开发循环。这一看法本身没错，但简化了一个关键事实：这并非一个循环，而是存在四层循环，自动化难度递增、涉及范围扩大。正是四层循环的差异性和难度递进关系，影响了美军的软件现代化，是相关举措不断推出的深层原因。

被简化的DevSecOps循环

美军在推动软件现代化过程中，明确将DevSecOps作为主要的软件研发方法，并通过5000.87《软件采办路径操作》、《软件现代化战略》等战略文件，以及后续的《体系级DevSecOps基础》《体系级DevSecOps参考设计》等一系列技术文件来推进这个方法落地。

简单理解，DevSecOps就是一个莫比乌斯环式的迭代循环：计划、编码、构建、测试、发布、部署、运行、监控、反馈，并将安全活动嵌入每个阶段。这概括了DevSecOps的主要活动，但忽视了一个关键维度：在涉及开发环境、测试环境和生产环境等不同场景，这个迭代循环的制约条件与运行要素的差异很大。

图1 美军DevSecOps就是一个莫比乌斯环式的迭代循环（图片来自互联网）

对于商业互联网软件，在开发环境、测试环境和生产环境的迭代循环差异相对较小，数据互通，通常可以通过基础设施即代码、容器化和自动化流水线较容易地打通各个循环。但对于嵌入式软件，特别是航空、导弹、雷达等关键任务系统软件，需要在实际硬件上运行，与多种传感器、武器系统和指挥控制网络交互，并且必须在极端环境下保持可靠性，测试环境循环与实际作战环境循环之间存在无法忽视的差异。因此，美军的DevSecOps循环必须考虑多层迭代层级，每一层都是下一层的基础和前提。

四层循环：从简单到复杂

基于对美军软件现代化政策文件、软件工厂实践、运行授权管理的分析，美军的DevSecOps循环实际上存在四层。

第一层：软件团队内部的自动化测试循环

这是最基础、自动化程度最高的循环。开发团队通过构建代码仓库和集成测试环境，打通代码提交、自动构建、静态分析、单元测试和集成测试的循环。这一层级的核心是持续集成、持续交付、自动化测试管道。

美军软件工厂的实践中，这一层级已经相当成熟。以美空军“一号平台”为例，其提供的DevSecOps工具链已经将代码提交、静态安全测试、动态安全测试、容器镜像扫描、依赖库漏洞检查等环节自动化。开发人员提交代码后，管道自动触发构建、集成和测试，如果测试失败则自动阻止合并，形成了最基础的响应式质量门槛。

图2 美军软件工厂构成示意图（含持续集成、持续交付、自动化测试管道，图片来自美军文件）

然而，这一层循环距离真实场景最远，保真度最低。它只能验证代码在逻辑上的正确性，无法验证软件在实际硬件上的行为，更无法验证软件在复杂作战环境中的表现。

第二层：软件团队与硬件团队衔接的集成测试循环

这是将软件与硬件初步融合的循环。当代码在集成测试环境中通过后，下一步需要验证软件在实际目标硬件上的行为。这就需要构建硬件在环、软件在环和人在环等仿真测试环境。

美军在武器系统软件开发中广泛采用硬件在环、软件在环技术。并提出任务和安全关键型软件密集型系统，如作战系统，需要额外的环境（例如，系统集成实验室和硬件在环测试台）来确保适当的测试、验证、仿真、压力测试。

硬件在环测试接入完整真实控制器硬件，实时仿真机运行高精度被控对象模型，通过真实物理 IO、总线与控制器硬件物理连接，形成完整实物闭环；可复现极限故障、极端工况，无需动用昂贵真实样机。

硬件在环测试仅仅是第一步，在复杂武器系统中，还涉及和武器系统的集成测试，这比硬件在环测试更急复杂，根据美军软件现代化试点项目总结，与复杂武器系统的集成主计划的对齐和协调，以及与测试主计划的对齐和协调是软件现代化推进的难点之一，核心问题是，软件采用了敏捷模式而硬件仍然是瀑布模式，对齐难度可想而知。美国很多大型国防承包商建立了精益实验室、试制平台体系或者针对型号的敏捷试验单元，来解决这一难题。

图3 一个电机控制器的硬件在环测试环境（图片来自互联网）

第三层：研发机构与真实环境仿真试验机构衔接的循环

这是将软件置于高保真场景或模拟量产场景中的验证循环。当软件在研发机构内部环境中验证后，下一步需要在更接近真实量产或真实作战的环境中进行测试。这就涉及与任务集成实验室甚至联合仿真环境等多系统联调模拟及数字孪生环境的衔接。

任务集成实验室与单系统级的硬件在环、软件在环不同，任务集成实验室不局限于单个控制器、单套设备的验证，而是将多套武器平台、传感器、指挥控制系统、通信网络纳入统一任务场景下联调，核心目标是验证完整杀伤链、任务链的闭环能力。

举例来说，联合仿真环境是美国防部为解决F-35等复杂武器系统试验鉴定挑战而发展的重要基础设施。联合仿真环境能够构建高保真度的任务级作战场景，将武器系统置于虚拟但极度真实的作战环境中进行测试。美军明确要求F-35初始作战试验鉴定必须完成64项联合仿真环境试验。然而，这种衔接循环涉及到多个机构之间的协同，就产生了新问题：

任务集成实验室等机构是否有责任和能力支持研发机构的软件测试和反馈。
项目管理上是否要求软件研发机构和任务集成实验室等机构对接开展测试验证工作。

图4 联合仿真环境模拟网络示意图（美国海军部文件图片）

‍第四层：研发机构与用户单位衔接的循环

这是最复杂、也是真正的DevSecOps循环。

前三个场景中，软件的测试和运行仍然在开发机构的控制范围内。而真正的敏捷开发要求开发团队与最终用户形成紧密闭环，这个最终用户通常就是作战人员。

这个循环有多复杂呢，从美军最近正在推动运行授权（ATO）的改革可以看出来。在传统模式下，软件要想部署到作战人员手中，必须经过严格的试验鉴定流程和运行授权流程。据美军报道这个流程完全阻碍了软件敏捷迭代，"在传统软件开发流程中，需要对成品软件进行数年测试才能获得运行授权，因此，软件无法快速进行更新，也无法确保军力的有效发挥。"

这一层级的特点是：

涉及多个利益相关方：开发团队、试验鉴定机构、用户单位、授权官员等多方参与。
制度性挑战最大：需要改革传统的采办、试验鉴定和运行授权流程。
自动化难度最高：需要将用户反馈、试验鉴定结果和授权决策都整合到自动化流程中。
价值最大：只有打通这一层，软件才可能真的做到“以作战所需速度交付”。

四层循环的自动化难度递增

四种循环场景的自动化难度呈现明显的递增趋势，其原因本质上并非技术问题而是管理和协同问题，尤其是涉及到软件研发机构与外部机构和用户部队的协同时管理问题更大，这也是美军软件现代化的难点和持续推进变革的根本原因。

为了解决这些问题，美军采取了一系列措施。

首先，美国防部指令5000.87新增了敏捷迭代路线的软件采办路径，其中明确将MVP（最小可行产品）、MVCR（最小可用能力版本）作为软件迭代的初始单位不断迭代，并强调“软件永未完成”的持续开发理念。但这种顶层理念的变革涉及软件研发机构与外部验证机构、用户部队之间的协调，并不是以采办为主要诉求的管理指令能够落实的。

其次，美军正在将传统瀑布式、与研发分离的试验鉴定流程，转变为与软件周期同步的迭代式试验鉴定，即为测试左移（前移）、持续评估、自动化优先和指标复用、结果共享。这意味着每个软件版本开发过程中，都要结合试验鉴定的要求和指标来开展单元测试、功能测试、安全测试和集成测试，并通过控制门禁实现持续评估，最大限度的利用自动化和指标复用、结果共享，将试验鉴定的管控要素嵌入到研发过程，而不是在软件完全开发完成后进行一次性的、耗时数年的试验鉴定。

第三，美军提出“开发试验鉴定即连续体”（dTEaaC）的思路，希望将分散的、事件驱动的试验鉴定过程向集成的、数据驱动的方法论的转变。利用基于数字孪生和数字线程构建测试的数字主干，连接研制试验鉴定（DT&E）和作战试验鉴定（OT&E），并在软件试验鉴定过程中践行这一思路。

第四，美军在具体装备研发项目的数字化水平评估中，加入了软件现代化和数字工程协同水平的评估，一是评估在数字运行环境中与基于全数字原型开展系统级集成测试的情况，二是评估在运行环境中与基于物理原型开展系统级集成测试的情况。

用户协同和运行授权是大同最外层循环的关键机制

在四层循环中，第四层（研发机构与用户单位衔接的循环）是最难打通的一环，当前最大瓶颈有二：用户协同和运行授权。

在用户协同方面，基于DevSecOps方法的敏捷开发严重依赖用户参与和用户反馈。然而即使不考虑参与意愿，作为用户的具体部队也缺少参与的制度安排。针对这一问题，美空军部提出“用户协议”模式，组织空军软件工厂和用户部队签署用户协议，以推动用户长期参与开发和长期反馈。

另一方面，原来用户部队接触的都是交付之后的软件，采用DevSecOps方法后，软件从成果形成后再交付变为MVP-MVCR的“尽早”交付。用户就必须先接受很不完善的“最小可行产品”之后在实际使用中持续迭代完善，这个变化需要一个适应过程。根据美军公布的信息和相关报道，在很多实践中，用户部队一开始并不习惯不完善的软件，产生了很多不满，但后期逐步化解了这些不满，认可了软件持续升级优化的研发逻辑。

图5 风险管理框架构成（图片来自美国NIST文件）

运行授权的实质是其交付验证。美军软件交付验证的依据是联邦政府的《联邦信息安全管理法案》，军方将其落地为“运行授权”机制，其核心是风险管理框架（RMF，图5），流程涉及研发、运行、采办管理、安全管理等多个单位，流程繁琐，通常需要6 个月到 2 年，严重拖累敏捷开发的节奏。

图6 美军新的“网络安全风险管理框架”（美国防部图片）

‍为解决这一矛盾，美军先是提出了局部优化的持续运行授权（cATO），之后又提出部分颠覆式的快速轨道计划，仍不过瘾，2025年底又提出从根本上逻辑重构的“网络安全风险管理框架”（图6）。可以看出，其管理逻辑仍在不断调整。

来源 / 空天防务观察作者 / 李亮

排版 / 清风审核 / 明月

▌声明：为分享前沿资讯及有价值的观点，#空天界微信公众号转载此文，并经过编辑。

未按照规范转载及引用者，我们保留追究相应责任的权利

部分图片难以找到原始出处，故文中未加以标注，如若侵犯了您的权益，请第一时间联系我们。