2023年是开展供应链安全，尤其是开源治理如火如荼的一年，开源治理是供应链安全最重要的一个方面，所以我们从开源治理谈起。我们先回顾一下2023的开源治理情况。我们从信通院《2023年中国企业开源治理全景观察》发布的信息。信通院调研了来自七个行业、105家企业的开源软件治理能力，受到供应链安全传导的作用，2023年互联网、软件和信息服务企业均开启了开源治理活动。当然整体而言，本次调研占比较高的是金融、通信、互联网行业，以中大型企业为主。
- 开源软件使用数量大幅增长，10万以上占12%；
- 2021年，25%的企业开源软件使用数量刚刚破万；
- 2022年，仅有3%的企业使用开源软件的数量上十万；
- 2023年，已有12%的企业使用开源软件的数量破十万。
近两年，大多数企业认识到开源软件的风险，逐渐运用工具做开源治理，相比于之前人工维护开源软件，自动化扫描工具准确度更高、颗粒度更细，所以调研结果中的开源软件企业数量整体大幅增长。在金融行业，除了六大国有银行早就深入开展开源治理活动之外，已经影响到股份制银行、农商行、城市银行等。而2023年证券行业也逐渐加入开源治理行列。央企、国企、以及软件测试/安全评测中心也开启了开源治理活动，可以说2023年是开源治理的元年。
这些企事业单位排名前十的开源治理活动，通过下表我们了解一下。
通过上面开展前10的开源治理活动可以看到，根据威胁情报给出的开源组件相关的漏洞，对当前系统中已运用的开源组件进行分析，并采取响应的替换、清退操作仍然是主要采取的活动。例如Log4j组件，这些活动更多的针对存量系统开展的活动。而企事业单位更多是对正在规划建设的IT系统进行开源治理活动，例如通过私服仓库的建立、软件成分分析工具的引入、开源治理管理体系的建设等全面开展活动，才能最大程度上规避开源风险。
开源治理活动中，到底谁对开源软件的安全负责呢？信通院的调研中没有给出明确的定论，看以下的统计数据。
25%的企业：谁先引入谁负责；
25%的企业：按部门职责进行划分；
28%的企业：谁使用谁负责；
22%的企业：由技术委员会评估确定。
这说明不同企业对开源软件谁来负责并没有达成共识，可能参与调研的人所处的岗位也决定了调研结果存在差异性。
其实我们所说的开源软件包括了两大类，其中一类是指开源基础软件，例如：开源操作系统（例如Linux、Android等）、开源数据库（例如MongoDB、Azure RTOS等）、开源编译器（例如GCC、Clang等）、开源中间件（例如Tomcat、Redis等）等。另一类是开源组件，是以源代码形式发布的软件。例如Log4j、Shiro等。其实开源组件的数量远远高于开源基础软件。这两类开源软件在开源治理过程中，应该还是有很多不同的处理方式的。
引入开源软件后，企业会对哪些系统进行持续跟踪呢？
调研结果是开源漏洞信息跟踪为88%、版本跟踪为60%、开源许可证跟踪为58%、社区基本情况的跟踪为41%。这些调研结果仅仅是参与调研者对于开源治理大相关活动的一个认识。企业从引入开源软件、检测、评估、维护、更新、清退开源软件，是一个相对复杂的过程。这里面牵涉到很多技术和管理上的事情。例如对于开源软件引入来说，开源基础软件于开源组件的来源不同，开源基础软件大家往往通过其官方网站进行下载，而开源组件大家往往去中央仓库（例如maven中央仓库）去拉取。还要分是企业自己开发团队引入开源软件，还是由于采购供应商的软件而引入的；对于很多企业，都是在相对封闭的内网进行开发，但是又不得不使用在互联网上中央仓库中开源组件，需要什么样的流程和制度才能既不影响生产又要保证引入开源组件的安全呢？等等这些问题都需要在开源治理活动中不得不考虑的。
另外，部分企业要求做到开源软件收敛，归一化，如何做呢？这种需求一般是架构部门提出来，有些企业把开源软件选型的责任落到架构团队，而架构团队就需要考虑如何减少引入开源软件的数量，对引入开源软件方法建立模型，这也是一个具有挑战性的工作，希望在2024年有企业能够给出一些研究成果。
企业处理开源组件漏洞的方式？
87%企业采用版本升级方式、72%企业采用手动方式下载应用补丁、77%企业则采用替换组件或者删除该组件、而还有10%企业采用不处理方式。这一组调研答案应该是多选题，很多企业勾选了多个开源组件漏洞处理方式。对于不同开源组件漏洞可采用不同的处理方式。的确对一些开源组件无法进行修复，因为由于某些开源组件只能适配某些框架、编译器版本以及依赖特定版本的组件，如果对该组件进行升级或替换，则框架也需要对应升级，编译器版本也需要升级、一些依赖的组件也需要升级，这些升级会带来复杂的、大量的工作，采用不处理方式是相对比较稳妥的处理方式。
对内部所有存量开源软件的管理，大多数企业是如何处理的呢？
调研结果显示，超过70%的企业，仅在新增的安全事件、生态变化等外部因素触发时针对存量开源软件进行非周期检查；仅有20%的企业会对存量开源软件的安全合规性与依赖情况进行周期性分析检查；10%的企业不针对存量开源软件进行检查。
这个调研结果出乎作者的意外。是什么原因让这些参与调研的企业不对存量系统进行开源治理呢？很多企业存在已上线运营的系统，如果有系统运行在互联网上面，则会存在很大风险，因为恶意者可以时刻利用开源组件漏洞来攻击我们这些系统，如果其中有高传染性的开源组件，则很容易被探测到，作为司法证据。
另一项问题调研显示，超过50%的企业缺乏软件成分分析（SCA）工具，且尚未建立SBOM（软件物料清单）的生成与管理机制。这的确反映了当前开源治理中一个重要内容，采购一款SCA工具对于开源治理还是一个必要选项，还好国内SCA工具厂商提供了企业可选的多种产品。
下面我们看看不同行业对开源治理各项指标的关注度。
通信行业：软硬协同、供应链复杂，更关注第三方软件管理
金融行业：在严格的监管法规要求下，重视风险管理（如引入管理、扫描工具、SBOM、SCA等）、软件测评和退出、安全漏洞管理和持续监控等，且规模越大的金融企业期望达到的开源治理能力成熟度越高
金融行业非常重视开源软件带来的风险，在国内也是最早一批做开源治理的企业。在开源治理中，往往是引入供应商的SCA产品，同时引入咨询团队，帮助银行做开源治理管理体系，SCA工具整合到现有的开发流程中，同时考虑对存量系统建立台账等工作。
汽车行业：行业整体生产流程高度规范化、重视功能安全和信息安全，因此更关注开源治理的管理制度（对开源软件的审查、评估、是否合规）、开发测试（以确保软件质量和安全性）
能源行业：涉及大量系统和设备、对供应商和合作伙伴要求更高，更关注第三方软件管理和运维管理
传统制造业：应用较少，对开源软件治理能力的关注度整体偏低
汽车行业，尤其是新兴电动汽车厂商，软件在整个汽车制造中，规模和比重越来越大，通常有几亿行代码，尤其是车载软件，对于汽车驾驶的安全性至关重要。加上出海受到海外监管的需要，对于质量安全和信息安全都非常重视。整车厂软件规模会更大，而且会引入大量的设备供应商和相应的软件，这些软件的安全也需要关注。
软件和信息服务行业：由于核心业务是软件开发和交付，积累了大量的软件资产和技术栈，同时面临海内外更加严格的政策，更注重存量软件管理、组织机制、软件测评和开发测试等方面的实践活动。
互联网行业：由于业务规模和复杂度高，开源软件使用量庞大，但在开源软件治理方面投入相对较少，更多的关注点可能集中在如何使用开源软件快速交付、业务迭代。
对于软件企业和互联网企业，尤其是一些行业头部企业，受到供应链安全传导影响，在近两年也逐渐重视供应链安全。但是互联网企业和软件企业的特点，他们更愿意直接采购一款SCA工具，自行组织建设一部分开源治理规范流程。不像金融行业建立比较完善的开源治理体系。
回顾了2023年，我们再来展望一下2024年，供应链安全仍然是国内企业关注和建设的重点，而且会继续下沉和延伸。在当前世界形势下，由于广义的网络安全是由于各个领域的信息安全组成的，而信息安全又是由软硬件和网络设备安全构成的，包括操作系统安全、中间件安全、交换机安全、编译器安全等等。现在我们面临的安全是整个供应链的安全，除了关注自身软件研发过程中的安全，更多的是关注由于供应链安全带给企业自身的风险。下面我们一起展望一下2024年供应链安全的趋势。
- 供应链安全继续向下传导，受到供应链关系影响，相关的上下游企业会更关注供应链安全；
- 信创环境下，国产服务器、操作系统、数据库、中间件等更加关注供应链安全；
- 在汽车制造企业，安全向底层的基础支撑软件延伸，而由于出海原因，又要关注国际上的安全相关的法律法规；
- 在军工科研院所，在供应链安全方面，考虑的会更多，开始注重IDE、编译工具链方面的安全；
- 在整个经济环境形势下，还是国企、央企、大型科技企业和互联网企业、汽车生产制造企业等仍然是更关注供应链安全，但是民营企业开始关注供应链安全。
在供应链安全相关的技术和工具方面，具有下列发展趋势。
- 需要厂商在技术上有更多的突破，更成熟的工具满足企业对于更高自动化的要求；
- 工具具有与其它系统快速集成能力，要求接口丰富且能适配各种Devops工具厂商；
- 集成到DevSecOps平台的工具，能够有更多的控制能力、数据度量能力，除了大厂能够在引擎提供数据的基础上进行分析和处理之外，技术和资源相对较弱的企业更希望工具本身能够提供更多的数据分析功能和控制功能；
- 在SAST、SCA工具继续在企业运用之后，更多的企业会关注IAST、Fuzzing test以及二进制分析；
- 检测工具更适配标准，做到可据可依。CNAS对应的代码审计标准GB/T 34943、34944、34946。行业标准例如GJB、PCI DSS、MISRA、AUTOSAR等等。
- 另外，对于金融企业头部银行，开始把安全左移做到极致，在借助于自动化威胁建模，把安全需求与自动化工具覆盖需求结合起来，真正实现闭环管理。
（结束）