今年 NSA 开源行业日的观察

图片来源：

Opensource.com

今年，我参加了在马里兰州举行的 NSA 开源行业日，并想总结一下让我感到惊讶和不惊讶的事情。让我们看看这些观察结果是否具有争议性或有帮助！更重要的是，我们将看到，鉴于开源、敏捷开发实践和基于组件的开发的现实情况，组织机构是否能够有效地管理、治理和保护其应用程序。

哪些是不令人惊讶的？

组织机构正在寻找开源救星。他们正在寻找可以追究责任的个人或事物。他们想要“一个可以全权负责的人”。他们习惯于以这种方式思考，这是基于他们从授权专有软件的独立软件供应商那里获得的以往支持。现在，他们转向像红帽这样的供应商，以获得开源基础设施软件支持。但是，这种模式不适用于来自不同项目或平台的数百或数千个开源组件。需要一种新的模式。
开源 = Linux、MySQL、JBoss。当人们想到开源时，他们会想到大型基础设施软件——他们不会想到用于构建应用程序的开源组件。许多人没有意识到或计划到，应用程序的 80% 是由开源组件组成的。在他们接受这个现实之前，他们很难实施必要的流程来保护基于组件的应用程序。
关于开源贡献的争议。虽然人们一致认为不应共享机密或秘密系统的工作，但对于非敏感工作存在分歧。并且有人质疑共享这项工作的价值。这引发了关于自定义更改如何导致难以维护的内部版本分支，以及与利用新的开源版本相关的变更控制问题的讨论。这是一篇关于政府项目中关于开源的 5 个误解的有趣文章。
关于访问代码是否给黑客带来优势的争议。 很多人讨论了“众人拾柴火焰高，代码更安全”的说法，以及关于访问代码是否给黑客带来优势的有趣对话。有些人认为是的，但另一些人则认为这无关紧要，因为黑客可以简单地从二进制文件中反向工程他们需要的东西。
组织机构无法跟上软件的最新版本。 许多小组成员和与会者都感叹他们无法保持软件的最新状态——即使是大型基础设施软件也是如此。在考虑组件的背景下，这个问题甚至更加令人望而生畏。

哪些是令人惊讶的？

人们仍然相信黄金存储库谬论。 也许这不应该令人惊讶，但对于许多开源挑战的下意识反应是“我们只需要确保开发人员使用当前版本。” 或者，“我们应该确保只有最新版本可以从互联网上下载。” 虽然拥有一个存储库来提供一些控制是很好的（顺便说一句，我们确实提供了 Nexus Repository Manager！），但我们知道不存在所谓的黄金存储库。这种方法存在许多问题：开发人员会绕过它；对于初始开发工作来说，它会过于限制等等。当然，存储库只是一个开始，但在整个软件生命周期中，包括对生产环境的支持，您都需要指导和治理。
人们仍然认为审批流程是管理 OSS 的方法。 一个组织讲述了他们如何设立了一个开源审查委员会。从首席信息安全官的角度来看——事情是这样的……警告，这很痛苦！

OSS 组件的所有者（想要使用它的人）——他们撰写一份深入的审查报告，包括业务价值……它提交给法务部门，我们确保我们没有遗留问题或合同问题。一旦法务部门完成，我们就提交给审查委员会—并且根据项目的进度—他们会与其他排队的项目一起优先处理它。然后它会通过安全审查—它提供什么功能，还会影响什么？我们必须了解基线—我必须了解我的企业以及我今天的网络是什么样子。我们考虑隐私要求、事务性要求。我们是否安全地执行这些操作？是否正在使用协议？一旦完成，我们将使用自动化工具深入研究代码。在整个审查结束时—法务、技术、安全—我们做出风险管理决策。我们是否希望它进入我们的企业？这是与开发人员的讨价还价—我们喜欢这个，我们需要更改这个……

我并不是说这些不是重要的考虑因素。我只是说，即使工作流程是自动化的，但基于组件的量、种类、复杂性和发布节奏，这种方法是行不通的—。在利用短冲刺的敏捷开发环境中考虑这种方法！这就是为什么开发人员抵制策略努力的原因。开发人员被迫绕过流程以赶上截止日期。或者他们不得不依赖已经获得批准的组件，即使它们不是最适合这项工作的组件。

人们将应用程序安全等同于 DAST / SAST。 虽然这些技术肯定会发挥作用，但一些组织强行将这些技术应用于管理开源使用。但是，有多少组织真正想参与开源组件代码？他们转向组件是为了获得“开箱即用”的功能。他们转向组件是为了不必自己构建它。他们不想参与代码——他们通常甚至没有代码。当已经知道关于这些组件的信息时，为什么要等到在开发过程中使用组件时才扫描源代码？这些信息可用于在开发过程的开始阶段选择最佳组件。虽然 DAST/SAST 有其用武之地，但基于组件的开发不能以我们管理将组件缝合在一起的自定义代码的相同方式进行管理。

主要认识

您是否同意这些观察结果？您是否同意我们需要采取行动？根据会议上进行的对话，这些共同主题表明开源方面取得了坚实的进展

供应链管理。鉴于应用程序开发过程由外部采购的组件支持，使用供应链原则来管理开发生命周期是一个共同的主题。人们认识到需要支持整个软件生命周期，并且组织机构对应用程序负责，无论应用程序由什么组成。人们了解如何使用组件来提高开发人员的效率，只要可以管理安全性、许可和质量风险。
自动化是关键。 即使我没有听到一次 DevOps，但也有很多关于自动化开发和交付过程的讨论。虽然这种自动化通常侧重于应用程序交付工具链（IDE、构建工具、CI、CD 等），但它可以引发关于策略自动化的对话。自动化策略可以直接在用于开发和交付软件应用程序的工具中提供指导和执行。
给开发人员他们想要的东西。 人们越来越认识到，安全性需要为开发人员提供他们想要的东西。首席信息安全官 (CISO) 了解，如果他们的控制阻碍了开发过程，开发人员将绕过他们的控制。他们意识到他们必须克服许多应用程序安全工具造成的“误报”和“漏报”负担。他们开始意识到，在开发人员的上下文中向他们提供信息需要集成到他们使用的工具中。例如，看看 Sonatype 的 CLM 平台如何集成开源安全数据并在开发人员每天工作的 IDE 中自动化策略。
修改安全性以适应当今应用程序的开发方式。 安全性和质量工作必须与现代开发方法保持一致——这不仅仅是适应开源的使用。有很多关于敏捷开发的对话，以及安全性和质量工作如何适应这种结构。除其他外，这意味着策略和合规性工作必须适应短期的敏捷开发周期。
组织机构必须对外部采购的代码和组件承担责任。 人们越来越认识到，使用开源的开发人员必须有效地管理它。但是，这种责任不应仅落在开发人员身上；整个组织机构都需要支持这项工作。并且组织机构必须以支持开发过程自然进行的方式来做到这一点，而不是强行套用遗留方法。答案不能是我们只是不使用开源——否则会损失太多的价值。这是来自高盛的一段视频，它代表了开源提供的价值。
（各种）孤岛需要被移除。 虽然 DevOps 通过打破开发和 IT 运维孤岛而处于领先地位，但阻碍敏捷性的不仅仅是组织摩擦。在主题演讲中，NSA 首席技术官兼首席架构师帕特里克·道德博士谈到他们如何摆脱基于飞地的架构，因为“孤岛”使得分析跨飞地的数据变得困难。相反，他们已转向利用开源技术来交付基于云的实用程序、数据和存储支持的架构。组织机构意识到，如果他们消除组织、技术和架构孤岛，他们更有可能实现敏捷性和速度目标。