开源在企业中流行的一个诱因，是开源技术提供了经过良好测试的建立块，可以加速复杂应用和服务的创建。并且第三方软件组件以及包和容器的便利性，在带来益处的同时和引入了风险，由于你建立的应用要和这种元素是一样安全的。
现今软件供应链功击显得这么普遍，Gartner早已将其列为2022年的第二大恐吓。Gartner的研究预测，到2025年，全球有45%的组织将经历一次或则多次软件供应链功击，有82%的CIO觉得，她们很容易遭到这种类型的功击。这其中，包括了通过黑客借助常用软件元素（比如Log4j）中的漏洞进行功击、针对建立管线（比如SolarWinds、Kaseya和Codecovhacks）的功击，或则入侵包储存库本身。
Cycode公司首席执行官LiorLevy解释说：“攻击者早已把优先级从生产环境转移到软件供应链上来，由于软件供应链是最薄弱的一个环节。只要软件供应链依然是相对容易功击的一个目标，软件供应链功击都会有所降低。”
AquaSecurity公司战略中级总工裁RaniOsnat表示，近来发生了好多引人关注的风波，这给软件开发行业叩响了警钟。数六年来仍然存在不透明性和欠缺透明度，所以这一点十分重要。
针对开源代码库的研究表明，漏洞、过时或则是废弃的组件很常见：有81%的代码库起码有一个漏洞，50%的代码库有多个高风险漏洞，88%的代码库使用的组件不是最新版本或则五年内没有新的开发进展。
不过，这种问题还不太可能妨碍开源技术的普及，由于商用软件和服务也很容易遭到功击。当LastPass遭到功击时linux服务器安全，它并没有遗失顾客数据，但未经授权的一方才能查看和下载部份源代码，这让黑客在未来可以更容易地功击密码管理器用户，但是Twilio漏洞也让功击者得以对下游组织发起供应链功击。
“影子代码”带来的恐吓
安全团队一般会假定网路早已被攻陷，以这些预演的方法保护她们的网路，CIO也是一样，她们必须假定所有代码（内部或则外部）、甚至是开发人员使用的开发环境和工具都早已遭到破坏linux软件，拟定策略来防范和最大限度上降低功击给她们软件供应链带来的冲击。
事实上Osnat建议说，CIO应当像对待“影子IT”一样对待这些“影子代码”。他说：“这不仅仅应当被视为一个安全问题，还应当是一个真正深入到怎样获取软件的问题，无论是开源的软件还是商用的软件：你怎样将这种软件带入你的环境，怎么更新那些软件，你想拥有如何的控制权，以及你想从供应商那儿要求哪些样实现如何的控制。”
透明度：采取软件材料清单（SBOM）的模式
化学供应链使用的是标签、成分清单、安全数据表和材料清单，让监管机构和消费者可以晓得产品的最终结果。新措施借以以类似的方式应用于软件，帮助组织了解依赖关系网路及软件开发过程中存在什么功击面。
日本白宫关于软件供应链安全的第14028号行政命令要求，向英国联邦政府提供软件的软件供应商，应当提供软件物料清单(SBOM)，并使用软件型腔(SLSA)安全检测表的供应链级别来避免篡改。Forrester中级剖析师JanetWorthington说，正由于这般，“我们看见好多企业愈发认真地对待她们的软件供应链，现在所有的公司都在生产和消费软件，我们看见有越来越多的生产商来找我们说，‘我是怎样生产安全的软件，我可以用软件材料清单来证明。’”
有好多跨行业的项目，包括NIST的改善供应链网路安全的国家呼吁(NIICS)、微软和其他IETF成员的供应链完整性、透明度和信任(SCITT)呼吁，以及OpenSSF供应链完整性工作小组。
“大家都在采取更为全面的方式，并且会说，等一下，我须要晓得我即将把哪些带入我正在使用软件重构的供应链中，”Worthington说。
Linux基金会近来的一项调查发觉，SBOM的意识度很高，目前有47%的IT供应商、服务提供商和受监管的行业在使用SBOM，88%的受访者预计将在2023年使用SBOM。
对这些早已对软件组件和API施行资产管理的组织来说，SBOM是最为有用的。Worthington说：“现在，这些拥有强悍软件开发流程的人们会发觉，她们在使用软件材料清单生成工具方面会更轻松一些。”
SBOM可以由建立系统创建，也可以由软件组成剖析工具在事后生成。她说，好多工具可以集成到CI/CD管线中，并作为建立的一部份运行，甚至可以在你下载库的时侯运行。“它可以警告你：‘嘿，你的管线中有这个组件，它有一个关键问题，你想继续吗？’”
Chainguard首席执行官DanLorenc说，你须要制订新政明晰开发团队怎么获取开源软件。“开发人员怎样晓得她们的公司的‘安全’政策是哪些？她们如何晓得她们正在获取的开源软件——当今开发人员所用软件中绝大多数都是这种软件——确实没有被篡改？”
他谈到了JavaScript、Java、Kubernetes和Python拿来确定软件包来源的开源Sigstore项目。他说：“Sigstore之于软件完整性，如同证书之于网站一样，它基本上构建了一个监管链和信任验证的系统。”
“我觉得CIO们应当首先向她们的开发团队灌输使用新兴行业标准方式的那些基本步骤，一是锁定建立系统，二是开发一种可重复的方式来验证软件型腔的可效度，之后再将其带入环境中。”
作出贡献
Worthington强调，无论是组件、API还是无服务器功能，大多数组织对她们目前的使用情况就会高估一个数目级，除非她们运行的是常规项目。“他们发觉其中一些API没有使用正确的身分验证方式，或则编撰方法不是她们预期的，甚至可能有些早已被弃用。”
不仅漏洞之外，评估包背后的社区支持与了解代码的作用是同样重要的，由于并非所有维护者都乐意承当起把这种代码视为一项关键资源的负担。她警告说：“并非所有的开源都是一样的。”
“开源可能是可以免费下载的，但使用上去肯定不是免费的。你使用某个开源技术，意味着你有责任去了解它背后的安全状况，由于你是要在供应链中使用的。你须要对此作出回馈。你的开发人员须要参与漏洞修补的工作中，”Worthington建议说，企业组织也应当打算好以提供资金的方法作出贡献linux系统入门学习，要么是直接贡献给开源项目，要么给通过资源和资金支持她们的这些项目。“当你制订开源战略的时侯，其中一部份就是要了解预算和影响。”
不要觉得这只是一种费用，而应当是一个机会，去更好地了解你所使用的这项技术。“它甚至有助于留住开发者，由于她们认为自己是社区的一个组成部份。她们才能贡献自己的技能，可以把这种讲到自己的简历里。”
请记住，漏洞在你的技术堆栈中是随处可见的，包括小型机，小型机越来越多地把Linux和开源作为工作负载一部份运行，但一般缺少其他环境中常见的安全流程和框架。
保护好渠道
保护你的软件交付管线也很重要。NIST的安全软件开发框架(SSDF)和SLSA是一个挺好的起点：其中囊括了各类成熟度级别的最佳实践，从简单的建立系统开始，接出来是使用日志和元数据进行审查和风波响应，仍然到完全安全的建立管线。据悉，CNCF的软件供应链最佳实践蓝皮书、Gartner关于减少软件供应链安全风险的手册、以及包括流程和工具的谷歌OSS安全供应链框架也很有用。
但是，须要注意的是，仅仅打开手动扫描工具去查找恶意代码，这可能会形成太多误报而且无济于事。虽然BitBucket、GitHub、GitLab等版本控制系统包括了安全和访问保护功能（包括越来越精细的访问策略控制、分支保护、代码签名、要求所有贡献者进行MFA以及扫描绝密和凭据）linux服务器安全，但一般必须是要明晰启用的。
据悉，一些通过在单个堆栈中施行SLSA来保护建立管线的项目，比如用于可重复安全创建型腔(FRSCA)的项目，实际上并没有打算好投入生产中使用，而且未来CIO应当可以看见建立系统上将包括越来越多的这种实践。
事实上，SBOM只是解决方案中的一部份，创建和使用SBOM的工具也仍在不断成熟，恳请和使用SBOM的过程也是这么。Worthington建议说，你在协议中除了要指定你想要的SBOM，还要指定你希望SBOM多久更新一次，以及其中是否包含漏洞报告和通知。“如果发觉像Log4j这样新的重大漏洞，供应协会告诉我，还是我必须在SBOM中自己搜索并查看我是否遭到了影响？”
企业组织还须要使用一些工具来阅读SBOM，并拟定流程对这种工具的发觉结果采取举措。Worthington说：“我须要一个工具来告诉我SBOM中的已知漏洞是哪些，许可证的涵义是哪些，但是这些情况是否会持续发生。”
CIO们应当谨记，SBOM“是一种促进力，但实际上并不能解决任何问题来保护你的供应链。SBOM可以帮助你应对可能发生的风波，”Osnat说，他对行业的响应速率以及围绕SBOM标准和代码证明进行的广泛合作持豁达心态，这将有助于让各类工具具有互操作性（一些组织提出，这应当作为Linux基金会研究中非常关注的问题），这可能会促使SOC2所面向的整个行业去提高透明度和报告标准。
也就是说，CIO们毋须等待新的标准或则工具开始让安全成为开发人员角色的一个组成部份，如同近些年来质量早已成为其中一部份一样，Osnat的建议是：“首先让你的CISO和首席工程师在一个卧室里，一起合作找出适宜你所在组织的正确模式，以及这些转变将以何种方式发生。”
