风险升级！CIO需要更加关注软件供应链安全使用开源软件可以提高开发人员的工作效率，但并不意味着它更安全。在数字化转型加速的时代，开源的复杂性和发展速度限制了软件供应链安全控制在驱动创新方面的有效性。 软件供应链攻击已变得如此普遍，以至于Gartner将其列为到2022年的第二大威胁。研究预测，到2025年，全球45%的组织将遭受一次或多次软件供应链攻击，82%的CIO认为他们将更容易受到攻击。这些攻击包括通过广泛使用的软件组件（如Log4j）中的漏洞进行的攻击、对构建管道的攻击（例如：SolarWinds、Kaseya和Codecov黑客攻击），或黑客自行破坏软件包存储库。 CycodeCEOLiorLevy解释说：“攻击者已经将攻击的重点从生产环境转移到了软件供应链上，因为软件供应链是最薄弱的环节。”，“软件供应链还是比较容易被攻击的目标，软件供应链攻击将继续增加。” 最近发生的引人注目的事件为软件开发行业敲响了警钟，AquaSecurity战略高级副总裁RaniOsnat说。“我们已经看到数十年的不透明和缺乏透明度，这就是为什么它是如此重要。” 一项对使用开源代码的代码库的研究表明，漏洞和过时或过时的组件很常见：81%的代码库至少有一个漏洞，50%的代码库有多个高危漏洞，88代码库百分比库使用的组件不是最新版本或两年未更新但未经授权的一方能够查看和下载其部分源代码，这可能使将来攻击密码管理器的用户变得更加容易，而Twilio漏洞允许攻击者对下游o发起供应链攻击组织。警惕“影子代码”的威胁 CIO们需要考虑最坏的情况：假设所有代码，无论是内部还是外部，甚至开发人员使用的开发环境和工具都已被破坏，因此，制定相应的政策来保护其软件供应链免受攻击并将其影响降至最低。 事实上，Osnat建议CIO在影子IT时考虑“影子代码”（在没有IT监督或安全审查的情况下添加的脚本和库）的潜在风险。“这不仅仅是一个安全问题，这是一个需要你深入思考如何获取软件的问题，无论是开源软件还是商业软件：你如何将它引入你的环境，你如何更新它，你想如何你想要什么控制，你想从你的供应商那里得到什么。”提高透明度：促进使用软件材料清单 实体供应链已经使用标签、成分列表、安全数据表和材料清单，因此监管机构和消费者知道对产品的期望。新举措旨在对软件应用类似的方法，帮助组织了解依赖网络和软件开发过程的攻击面。 白宫关于软件供应链安全的第14028号行政命令要求为联邦政府服务的软件供应商提供一份软件法案材料(SBOM)并使用软件工件的供应链级(SLSA)安全列表来防止篡改。正因为如此，“我们看到很多公司更加重视他们的软件供应链，”高级工程师珍妮特·沃辛顿(JanetWorthington)说。Forrester的分析师。来找我们说，‘我如何生产可以用软件物料清单证明的安全软件’。”。 有很多跨行业的项目，包括NIST的国家供应链网络安全改进计划（NIICS），微软和其他IETF成员的供应链完整性、透明度和信任计划（SCITT），以及OpenSSF供应链完整性工作组. Worthington说：“每个人都在采取更全面的方法并说，等一下，我需要知道我正在将什么带入我的供应链，我正在使用什么来创建软件”。 Linux基金会最近的一项调查发现，软件物料清单采用的意识很高，目前有47%的IT供应商、服务提供商和受监管行业使用SBOM，88%预计到2023年SBOM会这样做。 SBOM对于已经拥有软件组件和API资产管理的组织最有用。“今天拥有强大软件开发流程的人会发现更容易插入可以生成软件物料清单的工具，”Worthington说。 SBOM可以由构建系统创建，也可以由软件组成分析工具事后生成。许多工具可以集成到CI/CD管道中并作为构建的一部分运行，即使你删除了库，她说。“它可以警告你：‘嘿，你的管道中有这个组件，它有一个关键问题，你想继续吗？’” Chainguard的首席执行官DanLorenc说：“为了让它有用，你需要澄清你的开发团队如何获取开源软件的政策”，“开发人员如何知道他们公司的政策是什么以及什么被认为是“安全的”？他们如何知道他们正在购买开源软件（这就是开发人员目前使用世界上所有软件的绝大多数）真的一点都没有受到损害吗？” 他指出了JavaScript、Java、Kubernetes和Python用来构建包的开源Sigstore项目。“Sigstore之于软件完整性就像证书之于网站；他们基本上建立了监管链和信任验证系统，”他说。“我认为首席信息官应该首先在他们的开发团队中灌输这些基本步骤：第一，使用新兴的行业标准方法锁定构建系统，第二，创建一种可重复的方法来验证软件工件的真实性，然后再将它们引入环境”为你使用的开源组件做贡献 Worthington指出，无论是组件、API还是无服务器功能，大多数组织都会低估他们正在使用的功能，除非他们进行例行盘点。“他们发现，其中一些API没有使用正确的身份验证方法，或者它们可能没有按照预期的方式编写，其中一些甚至已被弃用，”她说。 撇开漏洞不谈，评估软件包背后的社区支持就像重要的是了解代码的作用，因为并非所有维护者都希望他们的代码被视为关键资源。“并非所有开源都是平等的，”她警告说。 Worthington说：“开源可能可以免费下载，但使用它肯定不是免费的。您对它的使用意味着您有责任了解其背后的安全状况，因为它在您的供应链中。你需要提供Itcontributions。你的开发人员需要参与修复错误。”，他建议组织也应该准备好以金钱形式捐赠，直接捐赠给开源项目或提供资源和财务支持的计划。“当你制定开源战略时，其中一部分就是了解预算和影响。” 不要认为这只是一种支出，它实际上是一个更好地了解您所依赖的组件的机会。“它甚至有助于留住开发人员，因为他们觉得自己是社区的一部分。他们能够贡献自己的技能。他们可以在简历中使用它，”她补充道。 请记住，在您的技术堆栈中的任何地方都可以找到漏洞，包括大型机，它们越来越多地将Linux和开源作为工作负载的一部分运行，但通常缺乏安全流程和框架。保护您的软件交付管道 保护您的软件交付管道也很重要。NIST的安全软件开发框架(SSDF)和SLSA是一个很好的起点：它涵盖了各种成熟度级别的优秀实践，从简单的构建系统开始，然后使用日志和元数据进行审计和事件响应，直到完全安全的构建管道。CNCF的软件供应链最佳实践白皮书、Gartner关于减轻软件供应链安全风险的指南以及Microsoft的OSS安全供应链框架（包括流程和工具）也很有帮助。 但是，需要注意的是，仅仅打开旨在查找恶意代码的自动扫描工具可能会产生太多误报而无济于事。尽管BitBucket、GitHub、GitLab等版本控制系统包括安全和访问保护功能（包括越来越细粒度的访问策略控制、分支保护、代码签名、要求所有贡献者进行MFA，以及扫描秘密和凭据），它们通常必须明确启用。 此外，诸如可重复安全创建工件工厂(FRSCA)之类的项目旨在通过在单个堆栈中实施SLSA来保护构建管道，但首席信息官应该期望构建系统在未来纳入更多此类实践。 事实上，虽然SBOM只是答案的一部分，但创建和使用它们的工具正在成熟，请求和使用它们的工具也在成熟。Worthington建议，合同不仅需要指定您想要的SBOM，还需要指定它们更新的频率，以及它们是否包括漏洞报告和通知。“如果发现像Log4j这样的新的严重漏洞，供应商会告诉我，还是我必须自己在SBOM中搜索以查看我是否受到影响？” 组织还需要工具来阅读SBOM，并制定流程以根据这些工具的发现采取行动。“我需要一个工具来告诉我（SBOM）已知的漏洞是什么，许可证的影响是什么，以及这是否会持续发生，”Worthington说。 首席信息官应该记住，SBOM“它是一个推动因素，但它并没有真正解决任何问题，保护供应链。它可以帮助你处理可能出现的事件，”Osnat说，他对行业的响应能力和围绕SBOM标准和代码认证的广泛工作。该合作乐观地认为，它将有助于使工具具有互操作性（Linux基金会研究中的组织提出的一个特别关注）。这可能会导致整个行业的透明度和报告标准得到与SOC2相同的改进。尽管如此，CIO不必等待新的标准或工具开始让安全成为开发人员角色的一部分，就像近年来质量一样，奥斯纳特说。他的建议是：“首先让您的CISO和首席工程师坐在一个房间里，弄清楚什么适合您的组织以及如何对其进行转型。”原文链接：https://www.cio.com/article/410904/the-new-cio-security-priority-your-software-supply-chain.html译者介绍张增斌，社区编辑，多年经验安全攻防，主要研究方向：安全开发、逆向破解、漏洞挖掘、黑灰产攻防对抗。
