如今，软件供应链攻击已经变得非常普遍，研究公司Gartner甚至将其列为“2022年第二大威胁”。Gartner预测，到2025年，全球45%的企业将经历一次或多次软件供应链攻击——82%的首席信息官认为他们将很容易受到此类攻击影响。这包括通过广泛使用的软件组件(如Log4j)中的漏洞进行的攻击，针对构建管道的攻击(c.f.、SolarWinds、Kaseya和Codecov黑客攻击)，或者攻击破坏包存储库本身。
Cycode的首席执行官Lior Levy解释道，“攻击者已经把重点从生产环境转移到软件供应链，因为软件供应链是最薄弱的环节。只要软件供应链仍然是相对容易被攻击的目标，软件供应链攻击就会不断增加。”
Aqua Security公司负责战略的高级副总裁Rani Osnat表示，最近备受关注的事件为软件开发行业敲响了警钟。它向我们揭露了该行业几十年来存在的不透明或缺乏透明度问题，这无疑是一件值得关注的大事。
针对使用开放源代码的代码库的研究表明，漏洞和过时或废弃的组件是十分常见的：81%的代码库至少有一个漏洞;50%有一个以上的高风险漏洞;88%使用的组件并非最新版本或在两年内没有新的开发程序。
不过，这些问题不太可能削弱开源的流行——商业软件和服务也很脆弱。当LastPass受到攻击时，它并没有丢失客户数据，但未经授权的一方能够查看和下载它的一些源代码，这可能使它更容易在未来攻击密码管理器的用户，而Twilio漏洞使攻击者能够对下游企业发起供应链攻击。
“影子代码”威胁
就像安全团队在“假设网络已被攻破”的情况下实施保护一样，CIO也必须假设所有的代码(内部和/或外部的)甚至开发人员使用的开发环境和工具都已经被攻破，并制定相应的策略来防止和最小化对其软件供应链的攻击影响。
事实上，Osnat建议CEO应该用对待“影子IT”的方式来看待这种“影子代码”。他认为，“这不仅仅是一个安全问题，而且是真正深入到你如何获得软件(无论它是开源的还是商业的)的问题：你如何把它带到你的环境中?你如何更新它?你想要有什么样的控制措施?你想要从你的供应商那里要求什么样的控制措施等?”
透明度：面向软件材料清单(SBOM)
实体供应链已经使用标签、成分表、安全数据表和材料清单，以便监管机构和消费者了解产品的最终组成部分。新的计划旨在将类似的方法应用到软件中，以帮助企业理解其软件开发过程的依赖项网络和攻击面。
白宫关于软件供应链安全的《14028号行政命令》要求为联邦政府供货的软件供应商提供软件材料清单(SBOM)，并使用软件工件(SLSA)的供应链级别安全检查表，以防止篡改。正因为如此，Forrester高级分析师Janet Worthington表示，“我们看到许多企业更加认真地看待他们的软件供应链。如今所有的公司都在生产和消费软件，我们看到越来越多的生产商来找我们，问我们，‘我怎样才能生产出安全的软件，并使用软件材料清单来证明。’”
除此之外，还有许多跨行业的项目，包括NIST的改善供应链网络安全国家倡议(NIICS)，来自微软和其他IETF成员的供应链完整性、透明度和信任倡议(SCITT)，以及OpenSSF供应链完整性工作组。
Worthington表示，“如今，每个人都在采取一种更全面的方法，他们会说，‘等一下，我需要知道我要把什么东西带进我的供应链。’”
Linux基金会最近的一项调查发现，SBOM的认知度很高，47%的IT供应商、服务提供商和受监管的行业目前使用SBOM;88%的人预计在2023年使用SBOM。
Worthington补充道，SBOM对于已经拥有软件组件和API资产管理的企业来说是最有用的。如今，拥有强大软件开发流程的人已经发现，插入能够生成软件材料清单的工具更容易。
SBOM可以由构建系统创建，也可以由软件组合分析工具在事后生成。许多工具可以集成到CI/CD管道中，并作为构建的一部分运行，甚至当你下拉库时也可以运行。它可以警告你：“嘿，你的管道中有这个组件，它有一个关键问题，你想继续吗?”
Chainguard首席执行官Dan Lorenc表示，要让这种做法发挥作用，就需要明确开发团队如何获取开源软件的政策。开发人员如何知道他们公司的“安全”政策是什么?他们如何知道他们正在购买的开源软件(这些软件构成了目前开发人员使用的绝大多数软件)确实没有被篡改?
他提到了开源的Sigstore项目，JavaScript、Java、Kubernetes和Python都使用这个项目来建立软件包的来源。他表示，“Sigstore之于软件完整性，就像证书之于网站;他们基本上建立了一个监管链和信任验证系统。”
Lorenc建议称，CIO应该首先向他们的开发团队灌输这些基本步骤，一是使用新兴的行业标准方法，锁定构建系统;二是在将软件工件引入环境之前创建一种可重复的方法来验证软件工件的可信性。
资金预算
Worthington指出，无论是组件、API还是无服务器功能，大多数企业都低估了他们正在使用的东西的数量级，除非他们进行例行盘点。他们会发现一些API没有使用适当的认证方法，或者可能没有按照他们预期的方式编写，甚至可能有些API已经被弃用。
除了漏洞之外，评估软件包背后的支持社区与理解代码的功能同样重要，因为并非所有的维护人员都希望自己的代码被视为关键资源。
Worthington解释称，“开源软件可以免费下载，但它的使用当然不是免费的。你使用它意味着你有责任了解它背后的安全态势，因为它在你的供应链中。你需要回馈它。你的开发人员需要参与修补漏洞。因此，建议企业应该准备好提供资金，要么直接给开源项目，要么用资源和资金支持他们的计划。当你制定一个开源战略时，其中的一部分是了解预算和影响。”
不要将这视为一笔开销，而是一个更好地理解你所依赖的组件的机会。它甚至有助于留住开发者，因为他们觉得自己是社区的一部分。他们能够贡献自己的技能。他们可以在简历上用到这一点。
请记住，漏洞可以在你技术堆栈的任何地方找到，包括大型机，它们越来越多地运行Linux和开源作为工作负载的一部分，但通常缺乏在其他环境中已变得常见的安全流程和框架。
保护你的管道
保护你的软件交付管道也很重要。NIST的安全软件开发框架(SSDF)和SLSA就是一个很好的起点：它涵盖了不同成熟度级别的最佳实践，从一个简单的构建系统开始，然后使用日志和元数据进行审计和事件响应，直到一个完全安全的构建管道。此外，CNCF的软件供应链最佳实践白皮书、Gartner关于减少软件供应链安全风险的指南以及微软的OSS安全供应链框架(包括过程和工具)也很有帮助。
然而，需要注意的是，简单地打开旨在发现恶意代码的自动扫描工具可能会产生太多的误报，从而无法提供真正地帮助。尽管像BitBucket、GitHub、GitLab等版本控制系统包括安全和访问保护功能(包括越来越细粒度的访问策略控制、分支保护、代码签名、要求所有贡献者使用MFA以及扫描秘密和凭证)，但它们通常必须显式启用(explicitly enabled)。
此外，像“可重复安全创建工件工厂”(Factory for Repeatable Secure Creation of Artifacts，FRSCA)这样旨在通过在单个堆栈中实现SLSA来保护构建管道的项目，还没有准备好投入生产，但CIO应该期望构建系统在未来包含更多这样的实践。
实际上，虽然SBOM只是解决问题的一部分，但是创建和使用它们的工具也在不断成熟，请求和使用它们的过程也是如此。Worthington建议，合同不仅需要明确你想要SBOM，还需要明确你希望它们多长时间更新一次，以及它们是否将包括漏洞报告和通知。例如，如果发现像Log4j这样的新的重要漏洞，供应商会告诉我吗?还是我必须在SBOM中搜索，看看是否受到了影响?
企业还需要工具来读取SBOM，并制定流程来对这些工具发现的内容采取行动。Worthington表示，“我需要一种工具，它能告诉我SBOM中已知的漏洞是什么，许可证的影响是什么，以及这种情况是否持续发生。”
Osnat补充道，CIO应该记住，SBOM只是一个使能者(enabler)，实际上并不能解决任何问题，以确保你的供应链安全。它只能帮助你应对可能发生的事件。不过，Osnat对行业响应的速度和围绕SBOM标准及代码认证正在进行的广泛合作持乐观态度，他认为这将有助于使工具更具互操作性，进而改善整个行业的透明度和报告标准化，就像SOC 2所带来的结果一样。
Osnat表示，尽管如此，CIO并不需要等到新的标准或工具才开始让安全成为开发人员的一部分。CIO应该先和首席工程师们沟通，找出适合企业的正确模式，并仔细研究如何实践这种变革以及变革可能带来的影响。
