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