软件供应链将成为CIO们面临一大新的安全优先事项

开源在企业中流行的一个原因，是开源技术提供了经过良好测试的构建块，可以加速复杂应用和服务的创建。但是第三方软件组件以及包和容器的便利性，在带来好处的同时和引入了风险，因为你构建的应用要和这些元素是一样安全的。

如今软件供应链攻击变得如此普遍，Gartner已经将其列为2022年的第二大威胁。Gartner的研究预测，到2025年，全球有45%的组织将经历一次或者多次软件供应链攻击，有82%的CIO认为，他们很容易遭受这种类型的攻击。这其中，包括了通过黑客利用常用软件元素（例如Log4j）中的漏洞进行攻击、针对构建管道（例如SolarWinds、Kaseya和Codecov hacks）的攻击，或者入侵包存储库本身。

Cycode公司首席执行官Lior Levy解释说：“攻击者已经把优先级从生产环境转移到软件供应链上来，因为软件供应链是最薄弱的一个环节。只要软件供应链仍然是相对容易攻击的一个目标，软件供应链攻击就会有所增加。”

Aqua Security公司战略高级副总裁Rani Osnat表示，最近发生了很多引人关注的事件，这给软件开发行业敲响了警钟。数十年来一直存在不透明性和缺乏透明度，所以这一点非常重要。

针对开源代码库的研究表明，漏洞、过时或者是废弃的组件很常见：有81%的代码库至少有一个漏洞，50%的代码库有多个高风险漏洞，88%的代码库使用的组件不是最新版本或者两年内没有新的开发进展。

不过，这些问题还不太可能阻碍开源技术的普及，因为商用软件和服务也很容易受到攻击。当LastPass受到攻击时，它并没有丢失客户数据，但未经授权的一方能够查看和下载部分源代码，这让黑客在未来可以更容易地攻击密码管理器用户，而且Twilio漏洞也让攻击者得以对下游组织发起供应链攻击。

“影子代码”带来的威胁

安全团队通常会假设网络已经被攻破，以这种预演的方式保护他们的网络，CIO也是一样，他们必须假设所有代码（内部或者外部）、甚至是开发人员使用的开发环境和工具都已经受到破坏，制定策略来防范和最大限度上减少攻击给他们软件供应链带来的冲击。

事实上Osnat建议说，CIO应该像对待“影子IT”一样对待这种“影子代码”。他说：“这不仅仅应该被视为一个安全问题，还应该是一个真正深入到如何获取软件的问题，无论是开源的软件还是商用的软件：你如何将这些软件带入你的环境，如何更新这些软件，你想拥有怎样的控制权，以及你想从供应商那里要求什么样实现怎样的控制。”

透明度：采取软件材料清单（SBOM）的模式

物理供应链使用的是标签、成分清单、安全数据表和材料清单，让监管机构和消费者可以知道产品的最终结果。新举措旨在以类似的方法应用于软件，帮助组织了解依赖关系网络及软件开发过程中存在哪些攻击面。

美国白宫关于软件供应链安全的第14028号行政命令要求，向美国联邦政府提供软件的软件供应商，应该提供软件物料清单(SBOM)，并使用软件工件(SLSA)安全检查表的供应链级别来防止篡改。Forrester高级分析师Janet Worthington说，正因为如此，“我们看到很多企业更加认真地对待他们的软件供应链，如今所有的公司都在生产和消费软件，我们看到有越来越多的生产商来找我们说，‘我是如何生产安全的软件，我可以用软件材料清单来证明。’”

有很多跨行业的项目，包括NIST的改善供应链网络安全的国家倡议(NIICS)、微软和其他IETF成员的供应链完整性、透明度和信任(SCITT)倡议，以及OpenSSF供应链完整性工作小组。

“大家都在采取更为全面的方法，而且会说，等一下，我需要知道我将要把什么带入我正在使用软件构建的供应链中，”Worthington说。

Linux基金会最近的一项调查发现，SBOM的意识度很高，目前有47%的IT供应商、服务提供商和受监管的行业在使用SBOM，88%的受访者预计将在2023年使用SBOM。

对那些已经对软件组件和API实施资产管理的组织来说，SBOM是最为有用的。Worthington说：“现在，那些拥有强大软件开发流程的人们会发现，他们在使用软件材料清单生成工具方面会更轻松一些。”

SBOM可以由构建系统创建，也可以由软件组成分析工具在事后生成。她说，很多工具可以集成到CI/CD管道中，并作为构建的一部分运行，甚至可以在你下载库的时候运行。“它可以警告你：‘嘿，你的管道中有这个组件，它有一个关键问题，你想继续吗？’”

Chainguard首席执行官Dan Lorenc说，你需要制定政策明确开发团队如何获取开源软件。“开发人员如何知道他们的公司的‘安全’政策是什么？他们怎么知道他们正在获取的开源软件——当今开发人员所用软件中绝大多数都是此类软件——确实没有被篡改？”

他提到了JavaScript、Java、Kubernetes和Python用来确定软件包来源的开源Sigstore项目。他说：“Sigstore之于软件完整性，就像证书之于网站一样，它基本上建立了一个监管链和信任验证的系统。”

“我认为CIO们应该首先向他们的开发团队灌输使用新兴行业标准方法的这些基本步骤，一是锁定构建系统，二是开发一种可重复的方法来验证软件工件的可信度，然后再将其带入环境中。”

做出贡献

Worthington指出，无论是组件、API还是无服务器功能，大多数组织对他们目前的使用情况都会低估一个数量级，除非他们运行的是常规项目。“他们发现其中一些API没有使用正确的身份验证方法，或者编写方式不是他们预期的，甚至可能有些已经被弃用。”

除了漏洞之外，评估包背后的社区支持与了解代码的作用是同样重要的，因为并非所有维护者都愿意承担起把这些代码视为一项关键资源的负担。她警告说：“并非所有的开源都是一样的。”

“开源可能是可以免费下载的，但使用起来肯定不是免费的。你使用某个开源技术，意味着你有责任去了解它背后的安全状况，因为你是要在供应链中使用的。你需要对此做出回馈。你的开发人员需要参与漏洞修复的工作中，”Worthington建议说，企业组织也应该准备好以提供资金的方式做出贡献，要么是直接贡献给开源项目，要么给通过资源和资金支持他们的那些项目。“当你制定开源战略的时候，其中一部分就是要了解预算和影响。”

不要认为这只是一种费用，而应该是一个机会，去更好地了解你所使用的这项技术。“它甚至有助于留住开发者，因为他们觉得自己是社区的一个组成部分。他们能够贡献自己的技能，可以把这些写到自己的简历里。”

请记住，漏洞在你的技术堆栈中是随处可见的，包括大型机，大型机越来越多地把Linux和开源作为工作负载一部分运行，但通常缺乏其他环境中常见的安全流程和框架。

保护好渠道

保护你的软件交付管道也很重要。NIST的安全软件开发框架(SSDF)和SLSA是一个很好的起点：其中涵盖了各种成熟度级别的最佳实践，从简单的构建系统开始，接下来是使用日志和元数据进行审查和事件响应，一直到完全安全的构建管道。此外，CNCF的软件供应链最佳实践白皮书、Gartner关于减轻软件供应链安全风险的指南、以及包括流程和工具的微软OSS安全供应链框架也很有用。

然而，需要注意的是，仅仅打开自动扫描工具去查找恶意代码，这可能会产生太多误报并且无济于事。尽管BitBucket、GitHub、GitLab等版本控制系统包括了安全和访问保护功能（包括越来越精细的访问策略控制、分支保护、代码签名、要求所有贡献者进行MFA以及扫描机密和凭据），但通常必须是要明确启用的。

此外，一些通过在单个堆栈中实施SLSA来保护构建管道的项目，例如用于可重复安全创建工件(FRSCA)的项目，实际上并没有准备好投入生产中使用，但是未来CIO应该可以看到构建系统中将包括越来越多的此类实践。

事实上，SBOM只是解决方案中的一部分，创建和使用SBOM的工具也仍在不断成熟，请求和使用SBOM的过程也是如此。Worthington建议说，你在合同中不仅要指定你想要的SBOM，还要指定你希望SBOM多久更新一次，以及其中是否包含漏洞报告和通知。“如果发现像Log4j这样新的重大漏洞，供应商会告诉我，还是我必须在SBOM中自己搜索并查看我是否受到了影响？”

企业组织还需要使用一些工具来阅读SBOM，并制定流程对这些工具的发现结果采取措施。Worthington说：“我需要一个工具来告诉我SBOM中的已知漏洞是什么，许可证的含义是什么，并且这种情况是否会持续发生。”

CIO们应该牢记，SBOM“是一种推动力，但实际上并不能解决任何问题来保护你的供应链。SBOM可以帮助你应对可能发生的事件，”Osnat说，他对行业的响应速度以及围绕SBOM标准和代码证明进行的广泛合作持乐观态度，这将有助于让各种工具具有互操作性（一些组织提出，这应该作为Linux基金会研究中特别关注的问题），这可能会推动SOC 2所面向的整个行业去提升透明度和报告标准。

也就是说，CIO们不必等待新的标准或者工具开始让安全成为开发人员角色的一个组成部分，就像近年来质量已经成为其中一部分一样，Osnat的建议是：“首先让你的CISO和首席工程师在一个房间里，一起合作找出适合你所在组织的正确模式，以及这种转变将以何种形式发生。”