作者：北京海鹰科技情报研究所 刘津玮

2022年7月28日，美国Kessel Run实验室（空军寿命周期管理中心第12支队）的前任指挥官、第三部门资本合伙公司前董事布赖恩·比奇考夫斯基和哈德逊研究所高级研究员、前国防部高级研究计划局官员、Vecna机器人技术公司的前总裁丹帕特在“岩石战争”网站发表联名文章，介绍运用Kessel Run实验室开发的DevSecOps工具缩短开发与作战之间差距的三大原则。

‍引言

美国国防部可运用软件团队开发的DevSecOps模型工具，将能力开发与软件、软件运行集成实现作战需求快速反馈，成功实现现代化转型。DevSecOps是“Devlopment”、“Security”、“Operations”的缩写，它是一种文化取向、自动化方法和平台设计方法，指在软件开发生命周期的从最初的设计到集成、测试、部署直至软件交付的每个阶段自动集成安全性。

很多人觉得，美国军方会通过利用一系列信息技术如软件、计算和数据传输等来快速更新武器，然而美国军队结构仍然是20世纪中期的状态，仅仅是对夕阳产业进行了优化。对此心怀不满的柴兰等离任官员曾在电视节目里暗示，美国逐渐失去其优势，或将成为中国的手下败将。想要跨出那一步做出改变是很艰巨的事情，只有通过具体的建议和实际行动才能将一切付诸现实。

一、DevSecOps工具

美国国防部可运用软件团队开发的DevSecOps模型工具，将能力开发与软件、软件运行集成实现作战需求快速反馈，成功实现现代化转型。DevSecOps是“Devlopment”、“Security”、“Operations”的缩写，它是一种文化取向、自动化方法和平台设计方法，指在软件开发生命周期的设计到集成、测试、部署直至软件交付的每个阶段自动集成安全性。

为了实施DevSecOps，团队应该在整个软件开发生命周期中引入安全性，以最大限度地减少软件代码中的漏洞。确保整个开发人员和运行团队共同承担遵循安全最佳实践的责任。通过将安全控制、工具和流程集成到DevOps工作流程中，在软件交付的每个阶段启用自动安全检查。DevSecOps将安全性应用于典型DevOps的计划、编码、构建、测试、发布和部署六个阶段。

DevSecOps是一个循环过程，应该不断迭代并应用于每个新的代码部署。漏洞利用和攻击者在不断发展，现代软件团队的发展也很重要。

二、DevSecOp工具运用原则

DevSecOps在开发人员、测试人员、安全团队和运维团队之间架起了桥梁；它改善了团队之间的沟通和协作，其目标是更快、更高效地交付。但是需要遵循联合创新组织的三个原则。首先，专注明确的作战挑战或者问题；第二，组织架构需要避免人工智能“死亡之谷”；第三，确保整个团队能够全方面地执行DevSecOps来推动学习和快速改进的良性循环。

第一个原则是始终高度关注待解决的单一军事问题。这不是一个新概念，国防高级研究计划局有一个版本是著名的海尔迈尔教义的第一要素，它类似于设计思维和“精益”方法背后的理念。

迄今为止，国防部的选择明显缺乏重点，他们并没有理解究竟依靠什么方法才能完成有效的数字现代化转型。一些初创企业在找到牵引力和增长点之前会多次转向，围绕着其成功的核心理论探索一些不同的产品，只有这样他们才能扩展其经过验证的模型。然而国防部高估了标准化，想要寻求一种完美的工具来完成所有工作，期望一个联合人工智能中心可以在整个国防部应用人工智能，或是认为小型企业总是通过纳新进行创新研究，这个想法既不成熟也不现实。

相比之下，Kessel Run实验室在过去两年间为第609空天作战中心提供软件支持，建立空中任务并执行空中控制命令的时候，发现拥有小范围和明确用户是至关重要的。国防和工业领导者们常常滥用商业类比—寻求“军事物联网”来创造“即插即用”的能力，这些想法太过于天马行空，无法解决特定任务的挑战，也无法掩盖或者忽略像数据分类这类独特的国防问题。

当新兴技术可以产生广泛变革型影响时，从小处入手似乎是有悖常理的。然而，将人类和机器融合在一起的有效解决方案工程的复杂性，是需要一种能够及早证明价值的方法。要么快速失败，要么最终走向成功。

第二个原则是用于软件开发的组织应该掌握整条生产路径。在某些情况下，组织壁垒或受保护的资金可以从既得利益和日常运行中分离。众所周知，国防部高级研究计划局资助的互联网的前身等早期创新，这些创新可能无法在其他地方开发。

将创新引入独立的新组织的另一个缺点是，创新是别人的工作，而不是项目办公室在现代化工作中所做的一部分。国防部受到预算的困扰，使得资助新团队比资助现有项目中的新方法更容易。但可以通过创造强大的组织激励机制进行创新，向致力于实施新技术的前瞻性程序部门投入资源。

虽然组织模式具有多样性，但重要的是为负责采办和交付军事能力的项目办公室赋予创新能力。Kessel Run实验室几乎是独一无二、创新的团队，也就是程序部门。程序部门应不断寻求能够支持这些预期结果的新想法和新技术，在保持良好结构基础上与成果保持一致。而国防部应该注重交付而不是计划。当负责交付的小组拥有全新组织激励机制的创新团队时，“死亡之谷”就会消失。

第三个原则是任何开发工作，如果想通过使用数字化工具（包括软件和数据）来交付能力，则应在使用中持续收集反馈信息，并结合反馈进行后续开发。只有开发人员不断从用户反馈中学习，并迅速改进软件、在短时间内更新软件，才是有价值的。对于像Kessel Run实验室一样的通过网络提供功能的项目，负责程序的部门本身应该成为DevSecOps的一个部分，负责管理构建和运行云环境的完整路径。运行网络、修复软件和确保软件可用的团队应该与开发团队保持一致。

在二战时期，在建造最复杂武器B-29超级堡垒轰炸机的过程中，设计目标是把完美设计运用在批量生产中。然而这意味着任何设计的改动将需要更新蓝图，必须以巨大的代价在生产线上层层推进。B-29进行了许多设计变更仍然能正常工作这一事实足以载入史册。但是软件与硬件不同，唯一的设计书就是源代码可以每天更改数百次。采用持续交付机制，可以在几分钟内以接近零的成本更新软件，借助这种精心设计的软件和交付机制，可以使更改操作系统变得容易且成本低廉。这还允许通过从用户数据中收集的实验和知识，形成一种学习和持续改进的文化。开发团队可以分析这些数据，快速交付高可靠性软件产品。

遗憾的是，国防部的组织习惯并没有融入当今数字时代，仍然保留二战时代的观念，坚持强调“优秀蓝图的价值”而忽略软件运行的反馈。他们不断在通过减少对支出资金的限制、调整收购规则和赋予更多创新责任来改善这种情况，甚至还有一个完整的改革委员会，但往往是徒劳的。而Kessel Run团队用DevSecOps工具将能力开发与软件、软件运行三个方面结合到一起，可以更有效地更新空中作战中心的传统规划和执行软件。

三、结束语

一支数字化的军队可以通过战术、决策支持和武器的不断创新，来创造充满活力的未来，但要实现这一目标，需要吸取商业软件的经验教训。

公司和开发人员使用不断发展的商品基础设施，将系统和代码连接到一起，并在这基础之上添加新的东西。传统作战系统的设计核心是围绕着硬件构建的；而在数字时代，无限组合的代码块、网络服务器和系统接口则代替了物理元件。

国防部可能会掀起新一轮数字军事创新的浪潮。这不是从架构定义、通用标准、通用开发平台的授权或为团队纳新开始的，而是从明确当前最重要的问题开始的，然后给予组织正确的工具和架构，从而让组织交付更好的成果。

声明：本文来自海鹰资讯，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。