科技云报道原创。
软件供应链安全如今已经成了一个世界性难题。从2021年底Apache Log4j“核弹级”风险爆发，时至今日影响仍然存在，保障软件供应链安全已成为业界关注焦点。
但近2年时间过去了，软件供应链安全问题似乎并没有得以缓解，安全事件层出不穷，开源漏洞风险与日俱增。
Venafi对来自全球不同企业的1000位CIO调研显示，其中82%的人表示他们的组织容易受到针对软件供应链的网络攻击。
奇安信《2023中国软件供应链安全分析报告》显示，开源项目维护者对安全问题的重视度和修复积极性较低。
同时，不活跃（超过一年未更新发布过版本）的开源软件，一旦出现安全漏洞，难以得到及时修复。
为什么人人都知道软件供应链安全问题很重要，却难以解决？
软件供应链安全与开源息息相关
要搞清楚软件供应链安全的症结，先得厘清其涵义。
基于中国信通院的定义，软件供应链安全是指“软件供应链上软件设计与开发的各个阶段中来自本身的编码过程、工具、设备或供应链上游的代码、模块和服务的安全，以及软件交付渠道及使用过程安全的总和。”
这里是把软件供应链安全分为了两部分：一是软件自身的供应链安全，二是软件供应链交界面的安全管理。
软件自身的供应链，可以简单理解为应用的代码来源，应用的代码来源主要有两个部分：一个是产品研发自己写的代码，另一个就是引入的第三方的开源组件代码。针对这两者的安全检测也是我们常说的开发安全。
软件供应链交接界面，针对的是开源软件或者商业采购第三方软件。
这部分的供应链安全管理，主要是在交付和使用过程中进行相关的准入检测，并形成标准化可溯源的软件物料清单。
事实上，软件供应链的安全的重要性提升和开源的大趋势是息息相关的。
软件开源化的趋势是一个累积的过程，十几年的时间经历了一个量变到质变的阶段，现在全球的开发者都在依赖开源组件来做应用的研发，绝大多数现代代码库都包含开源组件。
但是开源的繁荣本身就建立在一系列自由许可协议和免责条款上——其中也包括风险免责，“使用者风险自负”是开源社区的共识。
近年来，开源软件自身的安全状况持续下滑，企业软件开发中因使用开源软件而引入安全风险的状况更加糟糕，例如：危险开源组件的使用、自研代码缺陷漏洞引入、容器镜像漏洞引入等，这些风险导致软件系统的整体安全防护难度越来越大。
因此，开源软件供应链安全风险治理任重道远。
直面软件供应链安全治理挑战
尽管业界已经普遍认识到软件供应链安全的重要性，但治理起来依然面临重重挑战。
腾讯安全开发安全专家刘天勇表示，从技术角度看，软件供应链安全的治理的难点可以分成三部分：
一是检测门槛高。
开源组件的来源复杂，依靠单一的技术手段难以做到全面覆盖。
市面上常见的开源组件检测技术是基于源代码的SCA分析，但基于源码的SCA难以覆盖软件供应链交接界面的第三方软件成品。
二是修复成本高。
在企业开始做开源组件的风险治理的时候，存量业务往往会发现大量的漏洞，但这些业务大多数处于上线运营的阶段，修复的过程对研发资源是一个较大的消耗，同时对安全团队来说也是较大的推动阻力。
三是攻击影响范围广。
第三方开源组件的使用，间接扩大了软件的受攻击面，针对上游供应链环节的漏洞挖掘和恶意利用，能够快速覆盖大量的下游软件，同时相关的攻击具有较高的隐蔽性，常用的安全检测手段难以进行全面的防御，目前软件供应链攻击已经成为攻防演练中非常常用的攻击手段。
此外，供应商对产品安全性的重视程度不足、开发人员安全开发能力有限等，导致第三方供应商产品安全质量参差不齐，也加大了软件供应链安全治理的难度。
那么，企业该如何应对这些挑战？在技术上是否有对应的解决手段？
SCA和SBOM
当前，SCA（Software Composition Analysis）是目前业界主要的解决开源组件风险检测的手段。
SCA是一类工具的统称，可以通过分析源代码识别其中引用的开源组件信息（名称、版本、校验值）、组件漏洞、开源协议等信息，从而帮助开发人员和安全人员快速对于企业代码中的开源风险进行识别。
随着供应链安全开始获得更多关注，SCA工具内置了对与跟踪组件相关的漏洞和安全风险的更深入分析和管理，并成为企业生成SBOM和管理其开源使用的主要方法之一。
Linux基金会最近的一项调查发现，SBOM的意识度很高，目前有47%的IT供应商、服务提供商和受监管的行业在使用SBOM，88%的受访者预计将在2023年使用SBOM。
代码扫描和渗透测试
保护软件供应链的核心是一个应用程序安全问题，因此传统的应用程序安全代码扫描工具将在这个解决方案堆栈中发挥重要作用。
静态应用程序安全测试(SAST)、动态应用程序安全测试(DAST)、交互式应用程序安全测试 (IAST)和运行时应用程序扫描保护(RASP)工具，以及明智地使用渗透测试，可以帮助企业测试他们自己的内部代码，并提供对第三方代码的进一步检查，以作为应对风险的后盾。
相比于SCA和SBOM产品依赖于已知的、先前发现的漏洞，彻底的应用程序渗透评估可能会在检查第三方库和框架时识别出脆弱的代码使用情况，而这些代码以前可能在其他地方没有报告过。
此外，共享机密扫描和管理也正在从一个独立的工具类别快速转变为一个功能，该功能正在融入软件供应链安全工具的各个方面。
这是因为在开发和实际环境中，针对嵌入在源代码、配置文件和基础设施代码中的机密数据的网络攻击活动仍然猖獗，因此迫切需要解决这个问题。
此外，依赖关系管理和分析、受信任的存储库和注册中心、安全代码签名、CI/ CD管道安全性、第三方风险管理平台、IaC安全和CNAPP，都是软件供应链安全治理要重点关注的对象。
正如Gartner公司的高级主管兼应用安全分析师Dale Gardner所说：“当人们关注供应链安全时，他们关注的是使用SCA、SBOM等工具，这些都是解决方案中非常重要的部分，但它们实际上只是一种不全面的解决方案。”
软件供应链安全治理并非纯粹的技术问题
事实上，软件供应链安全问题是人、流程和知识的问题，而非纯粹的技术问题。
在解决软件研发过程的供应链安全问题时，需要贴合SDLC（软件开发生命周期）考虑供应链安全风险。
为此，Goolge提出了SLSA（Supply-chain Levels for Software Artifacts）框架，微软提出了SCIM（Supply Chain Integrity Model）框架以及CNCF（云原生计算基金会）的软件供应链最佳实践，三种框架都强调对于源代码、第三方依赖、构建系统、制品、发布、部署的安全性。
以SLSA框架为例，SLSA是一个标准清单和控制框架，用于缓解软件项目中的代码和软件包的供应链风险。
SLSA框架从三个方面评估软件供应链的安全等级，分别是源码、构建和依赖，并可划分为4个级别：
Level 1：构建过程是完全脚本化或自动化，且能够基于结果识别来源源码；
Level 2：使用有身份认证能力的版本控制和托管服务，确保构建来源是可信的；
Level 3：源码和构建平台符合可审计标准，且有成品完整性保证；
Level 4：所有变更均有双人评审，且有封闭的、可重复的构建过程。
以Level 4等级要求为例，在软件构建过程中企业需要实践以下4点：可验证的版本控制、双人评审、安全的自动化构建流程/环境、可重复构建的流程。
结语
软件供应链上每一个环节的安全问题，都有可能成为黑客攻击的切入口。千里之堤毁于蚁穴，把住软件供应链每个关卡，莫让小小漏洞成为洪水猛兽。
免责声明：此文内容为第三方自媒体作者发布的观察或评论性文章，所有文字和图片版权归作者所有，且仅代表作者个人观点，与 无关。文章仅供读者参考，并请自行核实相关内容。投诉邮箱：editor@fromgeek.com。
免责声明：本网站内容主要来自原创、合作伙伴供稿和第三方自媒体作者投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。任何单位或个人认为本网站中的网页或链接内容可能涉嫌侵犯其知识产权或存在不实内容时，应及时向本网站提出书面权利通知或不实情况说明，并提供身份证明、权属证明及详细侵权或不实情况证明。本网站在收到上述法律文件后，将会依法尽快联系相关文章源头核实，沟通删除相关内容或断开相关链接。
