保护您的软件供应链 ： 解决方案指南

保护您的软件供应链的五个注意事项 供应链的现实是，最终产品及其用户受到过程中涉及的每个组件，人员，活动，材料或程序的影响。 |synopys.com|1 正如Synopsys在年度“开源安全和风险分析”（OSSRA）报告中指出的那样，开源和第三方软件的使用继续以快速的速度增长。这意味着您的开发团队无疑在一定程度上在软件开发生命周期中使用开源。 而且，如果您的团队是软件提供商，那么您构建应用程序所依赖的开源，第三方和商业组件将使您成为供应链的一部分。但是，重要的是要注意，供应链并不会因您的团队而停止-它超出了您的开发和交付活动，并一直延伸到应用程序的最终用户。 您的供应链包括涉及应用程序或在其组装、开发和部署中发挥作用的所有内容，还包括开发团队创建的专有代码和组件，以及用于构建软件并将其交付给最终用户的基础架构。 研究传统供应链的示例可以帮助增加软件供应链讨论的清晰度。考虑汽车制造。这个行业的供应链始于原材料供应商，他们向零部件制造商提供金属、棉花、皮革、木材等。这些制造商采用原材料并生产零件，如螺钉，织物，螺母和螺栓。然后将这些组件传递给汽车零件和系统制造商，他们制造制造车辆所需的汽车零件（发动机，变速器）。最后，这些零件被发送给原始设备制造商，他们在装配线上制造车辆并将其出售给消费者。 当您考虑此制造过程中涉及的无数输入时，您可以开始了解可能引入风险的许多地方。制造这辆车的零件质量如何？汽车制造商组装这些零件的质量如何？当用户开车时，这辆车的实际性能如何？它如何应对事故和非理想驾驶条件等事件？ 供应链的现实是，最终产品及其用户受到过程中涉及的每个组件、人员、活动、材料和程序的影响。此工作流程任何部分的弱点都会带来风险，而减轻这种风险的唯一方法是完全了解整个供应链。这同样适用于软件供应链。 用最简单的术语来说，如果没有对供应链的全面了解，一个组织就无法准确或完整地管理其风险。由于有如此多的活动部件，它所需要的只是一个未知的弱点或设计缺陷，以创造利用的机会。 当今的软件供应链 分析公司Gartner旗下的在线市场供应商Capterra的一份报告显示，过去一年中，超过五分之三（61%）的美国企业受到软件供应链威胁的直接影响。 Capterra报告指出，开源软件是供应链风险的关键来源，并指出94%的美国公司以某种形式使用开源软件。 不安全的开源显然会对软件开发行业内外的企业产生影响。例如，广泛使用的ApacheLog4J实用程序中的零日漏洞允许攻击者在易受攻击的服务器上执行任意代码。 但是开源并不是供应链完整性的唯一风险。SolarWinds漏洞是由单个泄漏的密码造成的。有了它，黑客就能够访问其系统并利用例行更新来访问数千个客户的敏感数据。在CodeCov供应链漏洞中，黑客使用Docker映像中的秘密来安装后门并访问客户的数据。 为了应对安全漏洞的上升，拜登总统发布了一项行政命令（EO14028），详细说明了与联邦政府做生意的公司必须如何保护其软件的指导方针。为了加强美国的网络安全形象，该命令促使全国范围内重新审查组织安全实践，远远超出了该命令中指定的公司。 该命令还引发了对软件安全实践的集体调查。EO14028的关键部分建议增强企业软件供应链。该命令为现有的软件安全实践增加了另一层考虑因素：组织通过供应链安全的角度审查其现有活动。结果是在概述安全措施时必须解决的要求增加。 软件供应链安全的关键考虑因素 从根本上说，保护供应链的任何努力都必须考虑如何保护应用程序免受上游风险的影响，以及如何防止组织产生下游风险。 为了为解决供应链安全提供一个更简洁的起点，Synopsys确定了五个应该推动您的安全活动的考虑领域。回答这五个问题应该产生对供应链安全工作中成功和弱点的重要见解，并告知您的安全活动。 从根本上说，任何保护供应链的努力都必须考虑如何保护应用程序免受上游风险的影响。 产 以及如何防止您的组织 生 下游风险。 |synopys. 问题1 你使用的开源安全吗？ 了解开源风险 在解决供应链安全问题时，开源的普遍性是一个基本问题。虽然开源的风险并不比专有代码高或低，但未能充分保护它会给组织的整体安全性带来巨大风险。您的开发人员很可能在他们创建的几乎所有内容中都使用开源，这意味着您的应用程序的很大一部分是由您没有编写的代码组成的。OSSRA的年度报告证实了这一点：该报告检查的代码库中有近100％包含开源，这些代码库中有近80％的代码是开源的。 根据定义，开源来自不受控制的来源：组织外部的开发人员。保护供应链意味着保持对应用程序组成的所有内容的可见性，尤其是当它来自组织外部时。 重要的是要注意，开发人员有意和无意地将开源包含在他们的工作中。你的供应商也是如此；他们的开发人员可能会在不知不觉中将开源纳入他们的项目中。虽然这本身并不是一件坏事，但它确实为上游风险引入了一条途径，使其能够进入您的应用程序。您有责任跟踪供应链中的开源组件、许可证和漏洞及其相关风险。但是考虑到这项工作的规模，手动跟踪是不够的，而且太劳动密集型了。 了解法律风险 由于许可证违规和冲突而引起的法律影响通常比安全风险少，因此很容易转化为合并和收购，供应商纠纷和分销问题。对于软件供应商和分销商而言，供应链弱点带来的法律风险对组织的声誉和财务安全构成威胁。 开源管理不善往往是法律风险的罪魁祸首，因为开源的存在会使知识产权的识别和监控变得相当模糊。在臭名昭著的思科诉自由软件基金会诉讼，其中思科收购了包含不合规开源软件的固件。通过继承许可冲突，思科将组织暴露于本来可以避免的法律和声誉影响。这再次强调了供应链中的一切都有可能影响整个运营。将软件风险视为业务风险并对其进行相应的处理至关重要。 您有责任跟踪供应链中的开源组件、许可证和漏洞及其相关风险 。 |synopys.com|3 |synopsys.com|第4页4 了解运营风险和已知漏洞之外的风险 当团队使用过时的组件，没有最近开发活动的组件或项目中的组件而没有足够的开发人员社区来积极维护代码时，可能会引入运营风险。 代码质量、可靠性和可维护性问题，操作风险是安全风险的门户。如果没有开发人员发现并修复项目中的Bg，也就没有开发人员发现、披露和修复安全缺陷。当利用声誉和历史较差或未知的项目时，尤其如此。这些类型的项目为威胁行为者带来了低挂的果实。 风险也可能以恶意包的形式出现，恶意包包含伪装成合法包的恶意软件。它们用于通过开源库或第三方依赖项渗透软件供应链，并在激活后执行有害操作 。恶意软件包可能对应用程序的完整性和安全性构成严重风险。一旦恶意软件包的恶意软件感染了系统，它可能会窃取敏感数据，禁用安全软件，修改或删除文件，甚至接管整个系统或网络，传播到其他设备，进一步增加其损害。 问您是题否需要2提供软件材料清单？ 软件可以通过许多途径进入应用程序。有意和无意的（即，传递依赖）添加可以通过 •软件包管理器 •复制/粘贴和AI生成的片段 •C/C++等缺乏包管理器的语言 •容器映像、动态链接库和其他第三方二进制文件或库 所有这些都会产生广泛的风险表面和模糊的可见性。如果没有完整、动态的应用程序视图，你、你的供应商和你的消费者都无法自信地确定你面临的风险。维护软件材料清单（SBOM）是最佳实践，也是成功的供应链安全计划的基石。有时也需要遵守法规。SBOM本质上是代码库的“成分列表”，它可以是建立可见性的关键，但是要准确和完整，它需要在正确的时间进行编译。 仅仅分析软件包管理器的依赖关系是不够的，仅仅依靠几天、几周或几个月前编译的SBOM也是不够的。为了使SBOM有效，它需要用隐藏在代码中的依赖项不断填充，而不管语言、依赖项类型或版本如何。它不能停止在开源;自定义和商业代码也需要包括和跟踪。 以ApacheLog4J零日漏洞为例；拥有最新SBOM的组织能够在披露后的数小时内确定其风险并开始缓解活动，而无需返回并扫描其整个应用程序组合。 如果没有完整、动态的应用程序视图 ，你、你的供应商和你的消费者都无法自信地确定你面临的风险。 |synopsys.com|第4页5 问题3 你写的代码安全吗？ 由于开源代表了大多数应用程序代码，因此它也代表了大部分攻击面也就不足为奇了。但是，确保开发人员编写的代码保护敏感数据和系统免受网络攻击仍然至关重要。 无意中编码到应用程序中的安全缺陷和弱点为缓冲区溢出、SQL注入和跨站点脚本等攻击打开了大门。如果发生系统破坏，这些安全缺陷会使敏感数据容易暴露。威胁行为者可以利用这些弱点来注入恶意代码，然后有途径渗透由操作该软件的组织维护的系统。 避免这些问题的努力通常包括代码审查，希望对源代码的更多关注将有助于识别问题。然而，大多数软件开发人员没有接受过安全编码方面的培训，许多安全漏洞过于复杂，无法在手动代码审查过程中发现和跟踪。静态分析解决方案可以自动查看代码执行和数据路径以及识别安全漏洞，是确保您可以相信自己不会引入任何下游风险的重要工具。 也就是说，组织应始终专注于不断提高其产品的安全性。避免安全漏洞的最佳方法是永远不要首先创建它们。组织应投资于培训其开发人员如何安全地编码 ，并创建安全倡导者，以领导灌输供应链安全文化。 无意中编码到应用程序中的安全缺陷和弱点为缓冲区溢出、 SQL注入和跨站点脚本等攻击打开了大门。 容器化是云原生方法的理想解决方案，但它也为威胁进入供应链引入了额外的途径。 |synopsys.com|6 问题4 您的开发和交付基础架构是否安全？ 数据存储需求不断增长，部署期限越来越短，快速的可扩展性从未如此重要。 作为回应，软件行业越来越依赖云技术为其应用程序提供动力。这种云原生方法的一部分意味着采用支持可扩展性和敏捷性的应用程序部署方法-容器化和基础设施即代码(IaC)做得很好。 确定将哪些软件打包到容器中 容器使应用程序或微服务可以轻松快速部署、修补和扩展。它们还确保跨多个不同操作系统和硬件平台的一致性能。这使得容器化成为云原生方法的理想解决方案-但它也为威胁进入供应链带来了额外的途径。 开发人员在容器化应用程序时最常见的方法是从基础映像开始，通常是开源的，并在其上构建。附加的第三方和自定义代码层被添加到该基本图像之上,然后在执行最终图像时被组合到单个文件系统中,表示为二进制文件。基本的软件组成分析工具假定通过包管理器（如YUM）添加层中的文件，这是该工具将用于确定组成的工具。 然而，这并不完全有效。当使用Docerfile中的某些命令（如ADD、COPY或RUN）将文件添加到图层时，无需使用包管理器即可完成。只有容器映像的真正二进制分析才能检查组件签名，以识别所有开源组件，无论其来源如何，以及容器映像中存在的任何敏感数据。 |synopsys.com|第7页7 使用基础架构作为代码安全地进行部署 如今，云平台的运营方式不可或缺的是支持基础架构的配置、管理和配置方式。为了支持虚拟化和容器编排，服务器现在以临时方式运行，由规范构建，在 根据需要的基础。这些规范由使用Terraform和Ansible等软件的团队构建，使操作能够以自动化方式进行。但是，这些规范也可能引入安全漏洞，这些安全漏洞可能会在应用程序部署的规模上成倍增加，每周可能会有数万到数十万次。 例如，由未经授权的特权升级或基础架构配置中的网络暴露创建的无意和故意的后门并不是新的风险。新功能是谁负责构建和组装服务器配置。这曾经是IT运营工程师的工作，该工程师受过安全配置服务器和预测威胁方面的培训和经验。责任已经转移到开发团队，他们可以使用基础设施即代码(IaC)轻松地为他们正在构建的应用程序指定部署配置。这方面的缺乏经验可能会导致错误和疏忽，使攻击者更容易渗透到基础设施中，从而使攻击者更接近应用程序的用户、运营商和数据。 IaC如此有价值的部分原因在于它是由代码组成的。因此，它像代码一样编写和阅读，它被保存和版本化为代码，它