全球软件供应链安全治理方向及趋势

问题一：软件供应链安全是一个很大的话题，今天我看各方对软件供应链安全的定义都不太一样，国内我看大家提SCA、开源安全治理更多一些，海外也在提一些更前沿的概念，比如基于sigstore技术实现的软件持续安全验证的产品Chainguard，不知道在座的各位，你们对于软件供应链安全的理解是什么样的？或者说你们当前在软件供应链安全这个领域更关注什么？

软件供应链安全的理解 开发环节：软件开发涉及到的软硬件开发环境、开发工具、第三方库、软件开发实施等等，并且软件开发实施的具体过程还包括需求分析、设计、实现和测试等，软件产品在这一环节中形成最终用户可用的形态。 交付环节：用户通过在线商店、免费网络下载、购买软件安装光盘等存储介质、资源共享等方式获取到所需软件产品的过程。 使用环节：用户使用软件产品的整个生命周期，包括软件升级、维护等过程。

软件供应链安全这个领域更关注 开源软件持续安全， Kubernetes 1.24版本和 Sigstore 社区宣布，Kubernetes 将在生产中采用 Sigstore 来签署工件和验证签名，这使得 Kubernetes 用户第一次能够验证他们正在使用的发行版正是它所声称的。 入口管控，出口管控

第三方组件的风险识别应该从组件引入环节开始做好控制，包括禁止高危组件的引入、将漏洞检测插件默认集成到开发者的IDE中； 需要在软件构建、测试、部署的全流程中集成三方软件的检测和修复能力； 持续获取三方组件最新漏洞情报； 尽可能的将安全的修复方案做的足够简单，这样和研发人员一起推进修复的时候才能更高效。

问题二：今天软件供应链安全受到大家的广泛关注，从根本上来讲各位认为最主要的原因是什么？为什么是这两年大家对这个事情突然一下子就关注起来了？包括近期欧美出台了软件供应链安全相关的法规，美国白宫的备忘录要求供应商自证安全、欧盟要求产品提供sbom，否则最高可以处罚1500万欧元或全球营收2.5%，各位对此怎么看？

软件供应链的安全攻击事件一直呈快速增长态势，造成的危害也越来越严重，其中，开源软件的安全问题尤其值得关注。

生产模式的变化。用户对软件功能、应用实效等方面的需求越来越高，这就要求开发者在短时间内实现相应功能，还要持续不断地进行迭代更新。软件系统往往由自主研发的、开源获取的、外包开发的、商业购买的等多种来源的部件组合而成，为了响应快速开发的需求，软件供应链中第三方来源的如开源、外包、商业等成分软件的占比会增加，从而引入更多“不可控”成分，增加了软件安全评估的难度，也提高了软件供应链风险。

软件自身的变化。软件系统规模越来越大，程序逻辑越来越复杂，因此对软件的理解和分析也越来越难，这也造成了对软件把关和分析技术的门槛越来越高。另外，开源、库文件等提高了代码复用性，但在算法、结构、逻辑、特性等复用的同时，也带来了缺陷、漏洞等风险的复制，极大增加了供应链的攻击面，会造成某一点问题的大面积爆发，利用Struts2 等开源漏洞攻击的影响面之广就是个很好的例子。

环境渠道的多样。软件产品开发、构建、部署、交付等环节的生产线环境和发布渠道越来越多样化、多元化，IDE、代码管理系统、Bug 管理系统、构建工具、CI/CD 工具、云平台部署、交付方式等的选择越来越多，这些辅助工具或渠道的不安全因素会作为“基因”传导至软件产品中，也会增加软件供应链的攻击面。

产品安全自我证明是指开发人员必须提供以证明其符合安全软件开发框架的文档。政策层面，用户，厂商

问题三：我理解供应链软件的生产方、传播及分发侧、应用侧（企业）各方都需要协同，才能保障最终交付给客户/用户的软件的安全性，那么在这各个环节，大家作为不同的角色，能稍微分享下目前在软件供应链安全这块都做了哪些工作吗？请xx代表企业分享一下你们在企业内部是怎么开展软件供应链安全治理工作的，主要遇到哪些挑战？请xxx代表开发者，也就是供应链软件生产方分享下？

第三方组件的风险识别应该从组件引入环节开始做好控制，包括禁止高危组件的引入、将漏洞检测插件默认集成到开发者的IDE中； 需要在软件构建、测试、部署的全流程中集成三方软件的检测和修复能力； 持续获取三方组件最新漏洞情报； 尽可能的将安全的修复方案做的足够简单，这样和研发人员一起推进修复的时候才能更高效。 挑战整体上云，涉及这些链路，组装生产产品，都得去设计关键扫描，其实最优选基础包，底层架构，计算引擎，存储，业务网关

问题四：今天不管是企业里的信息安全专家还是软件开发者，大家日常处理安全工作都会使用一些外部的技术工具或者产品来说辅助开展安全相关的工作，大家觉得对于你们来说，怎么定义一款好的安全产品？单纯从你们的角度来出发，什么样的产品是一个好的安全产品？

足够简洁，可以自动化管理链路，

问题五：大家都知道在软件供应链安全这个方向，开源的软件供应链始终还是大头，开源让整个软件生态越来越繁荣这事毋庸置疑的，但是开源软件同样也带来了很多安全漏洞，关于如何能够让这些开源的项目变得越来越安全？大家有什么好的意见和建议吗？ 虽然开源是创新和构建高质量软件的一种经过验证的机制，但取得成功的同时也成为了自身的牺牲品，因为开源软件无处不在导致它成为了供应链攻击的一大目标。企业需要加深对开源工作机制的理解，包括治理和代码，并通过采用开发者优先的安全工具和方法，来加强他们的供应链管理。

大多数安全成熟度比较高的企业（也就是那些制定了开源软件安全策略的企业）主要依赖于行业漏洞咨询(60%)、自动监控包中错误(60%)、来自包维护者的通知(49%) )。 自动化监控可以说是那些安全成熟度高的企业和那些没有策略的企业之间一个最显着的差距，那些没有策略的企业中，只有38%使用某种自动监控，而安全成熟度高的企业这一比例达到了60%。

Jarvis说，如果企业没有制定开源软件安全策略，那么他们现在就应该着手了，可作为加强其开发安全性的一种方式，即使是轻量级的策略也是一个很好的开始。

问题六：传统的供应链安全，比如饮用水，我们今天谁从超市买一瓶矿泉水，都不会担心这个水是不是有毒或者质量有问题，说明饮用水的供应链安全管理其实已经非常规范了，那么作为软件来说，各位觉得未来有没有可能软件供应链的安全管理也能做到这种成熟度？这里面会有哪些挑战？需要做哪些事情？相对传统供应链安全来说，有哪些值得借鉴的？

通过 Dart 和 GitHub 团队的共同努力，自 10 月 7 日起，GitHub 的 Advisory Database (安全咨询数据库)、Dependency Graph (依赖项关系图) 和 Dependabot (依赖更新机器人) 开始支持 Dart 开发者生态，这也意味着 GitHub 为 Dart 和 Flutter 应用的供应链安全提供了全面支持:

GitHub 的 Advisory Database (安全咨询数据库) 为漏洞报告者和项目维护者之间提供了一个协作平台，漏洞报告者和项目维护者可以共同合作，在漏洞被公开之前私密讨论并修复漏洞。 Dependency Graph (依赖项关系图) 主要是分析 Dart / Flutter 项目的 pubspec.yaml 和 pubspec.lock 文件来确定项目依赖关系。 Dependabot 是 GitHub 收购并免费开放的一个检测依赖项安全性的工具，一旦你依赖的 Dart package 版本发现新漏洞时，Dependabot 就可以发出通知并自动创建拉取请求 (Pull Request)，将 package 版本升级到没有漏洞的版本。查看过往推文: Dependabot 开始支持 pub package 版本检测 了解更多。

生态建立，融入日常生产中，无侵入式去影响产品生产，全链路形成闭关，主关意识。