写在前面
自从和几个小伙伴一起创办墨菲安全以来，有一年半多的时间了，创业对于我来说，很有意思的一个地方，就是有机会可以和各行各业很多非常有意思的人一起交流，在这个交流的过程中能够不断的提升自己的认知，以我自己创业之前的经历来说，我接触的大多都是互联网和互联网安全这个圈子的人，而现在有很多机会去接触到更多行业的客户和合作伙伴，可以有机会去了解不同行业的业务、安全和他们所在行业的一些成熟的治理经验，除此之外也能了解不同行业的专家、大佬的不同思维模式和很多有意思的经验和经历。这对于我们去做一个更包容、更通用的产品有非常大的帮助。
那么，这篇文章我给大家分享一下我和超过 180 家各行业企业的安全负责人和一线的工程师们一起交流关于企业软件供应链治理问题过程的一些收获，我会把大家讨论和关心的共性问题做一些总结和提炼，然后也结合我自己在产品上的一些思考，分享给大家。
这一篇文章中的每一个核心问题，我大概不会展开说的很细，主要还是梳理思考这些问题的一些关键思路和拆解过程，至于如何解决这些问题，以及一些解决方案的实现方式，我后面计划把这些问题逐一拆解，再通过文章、直播等方式去做一些分享。
致谢
这篇文章的创作过程得到了很多来自互联网、金融、科技出海等各个行业在软件供应链安全领域有非常丰富的实践经验的技术大佬，他们是程岩同学、黄扬洋同学、吴圣同学、崔泷跃同学、张国超同学、杜中伟同学、苏嘉鹏同学、邱晨曦同学、小孟同学、高渐离同学，非常感谢他们贡献的场景、治理思路和建议。
一、软件供应链安全主要包含哪些威胁？
企业生产及办公过程中从外部引入的供应链软件从形态上来说主要包含三大类：开源组件、开源软件、闭源软件；从使用场景上来说分为两大类：办公软件及用户生产服务构建的软件；从付费角度来说分为商业软件及免费软件；总之，这些供应链软件由公司之外的第三方主体（组织或个人）开发并拥有知识产权的软件。
这些供应链软件在企业使用过程中会给企业带来的风险有四大类，按照影响面的通用性和危害程度，可以分为：软件安全漏洞导致的攻击、软件投毒攻击、软件知识产权合规风险、供应中断风险。
软件安全漏洞导致的攻击
顾名思义，但凡是软件都可能会存在安全漏洞，而且是越复杂的软件漏洞自然越多，同时使用的越广泛的供应链软件相对来说漏洞越多，因为攻击者可以通过挖掘这一类应用广泛的组件存在的漏洞来攻击更多的企业，谋取更多的利益；同样，一些专门从事漏洞挖掘的安全专家同样乐于去挖掘这些应用广泛的供应链软件的漏洞，这样他可以获得更多的漏洞赏金和社区影响力；
通常是谁在利用软件安全漏洞进行攻击或模拟攻击行为：
1）全球以勒索、挖矿为主要手段的黑灰产，对于他们来说，利用一个或多个应用广泛的供应链软件存在的漏洞对全球范围内的企业发起扫描，一旦发现漏洞后便实时数据窃取或数据加密后的勒索，或者干脆就入侵服务器挖矿，这是一种非常高效的攻击获利手段；
2）区域性或国家级的攻防演练的过程中，攻击者常用的攻击手段就是准备一堆供应链软件的 Nday&0day 来对企业目标进行渗透攻击，以达成攻破目标的目的。
3）针对重点企业及国家关键基础设施企业的针对性攻击，近几年外部攻击者惯用的攻击手段就是对国内的关键基础设施及企业的软件供应商发起攻击，以窃取敏感数据或者发起破坏。因为这些关基单位本身安全防护做的不错，那么攻击就是转而攻击关基的大量供应商以达到获取数据及关键信息的目的。
4）随着大模型AI的技术的广泛应用和普及，针对模型训练、推理过程中，较多的用到了开源/第三方库、算法或组件，可能因算法后门和软件供应链安全导致训练数据、代码、模型泄漏，这一类的风险也不容忽视；前段时间3月24号的时候，OpenAI发布声明，向其用户和整个ChatGPT社区道歉，道歉声明ChatGPT因为一个开源库存在安全漏洞，导致一部分用户的聊天数据泄露。此后OpenAI向社区发布悬赏计划，以最高2万美元的奖励悬赏社区白帽子为其找漏洞。
软件投毒的攻击
软件投毒的本质是人为的为供应链软件创造一个可用于攻击的漏洞或者后门，以达到攻击的目的，当前我们看到的主流投毒攻击包含 3 大类：
1）是针对商业软件的投毒，通常是入侵某应用广泛的商业软件公司，然后在该公司的商业产品更新中植入后门，等该软件的客户更新时对客户发起感染，非常典型的就是 solarwinds 事件；这一类攻击可以极其隐蔽，国内这两年也出现过不少这样的事件。一方面厂商的安全防护能力不一定有那么强，另一方面，这些有网络或管理特权的软件，管控的力度不会有正常应用那么严格（如放在管理网段，默认就放行各种网络）；
2）是针对开源软件的包管理生态的中央仓库的投毒，比如 npm、PyPI 等针对 nodejs 及 python 开源组件的投毒是非常猖狂的，墨菲安全实验室每周大概能监控到超过 100 起的开源组件投毒事件；尤其是在大型攻防演练期间，这个数据还会有大幅上升，可见投毒是近几年一种新兴且有效的攻击方式，在传统的攻防演练中的攻击手段无法突破的情况下，很多攻击者往往采取投毒的攻击方式。
3）是针对 github 等这类开源代码托管平台中托管的一些开源项目的投毒，这类攻击相对少见，但是今年我们有 2 个客户也遇到过类似的问题，开发人员在复用一个 github 开源项目时，不慎引入了一个带后门的开源项目，导致线上服务被攻击。
4）快手的安全大佬给我提供了第四种的攻击方式：跟第一类有点类似的，不是直接攻击商业软件公司本身，而是攻击开源组件下载量比较大的下载源或者镜像（如一些软件国内站点），国内的镜像源问题比较多，常用的python这种，官方在删除了恶意包之后，国内其实是不删除的，需要主动联系维护方（豆瓣这种是联系不上）。还有yum源这种，学校维护的，其实也很容易出问题（虽然安装时有校验，但是很多公司其实是关闭校验的）。此外还遇到通过网络或者搜索引擎对官方站进行劫持的。
软件知识产权合规风险
软件本身作为知识产权类的产品，在软件销售和流动的过程中很容易发生知识产权相关的合规风险，这类风险主要分为 2 类：
1）是自主可控，当前随着国际形势越来越复杂，各个国家都在提自主可控，国内尤其是关键基础设施对这个事情的关注度尤其高，但是实际上这里面很多所谓的自主可控是参杂了水分的，所以这两年国家监管及关键基础设施企业内部正在加紧对外购软件的自主可控率进行审查，防止一些套皮的虚假自主可控；
2）是使用开源组件所带来的开源许可证合规风险，像强著佐权的许可证如 AGPL，要求即使在 SaaS 情形下利用软件通过网络提供服务也必须公开源代码；这类场景的开源许可证很多公司就会遇到合规风险，所以我了解我们一些客户公司在内部私有源内直接禁用掉了所有 GPL 相关开源组件，2021 年国内出了一起法院对违反开源许可证的正式判例，这就意味国内的法律对开源许可证的认可，而目前很多企业在软件开发的过程中是明显缺乏开源许可证合规的管理的，这无形之中埋下了极大的风险。而在和不少客户交流的过程中，我们发现一些软件厂商在生产软件比如iot sdk、软件安装包、固件交付给海外客户及国内重要客户时，客户会要求给出组件许可清单、许可证使用的问卷以及自行执行扫描以判断是否合规，不合规就不会入选供应商名单。
供应中断风险
这类风险通常来说目前来自金融、运营商等关基相关的企业和单位非常关注，当前供应中断的风险主要来自一些开源组件不维护或者维护质量较差，一旦当前使用的组件版本出现较大 bug 或者安全漏洞，而官方又不能及时更新版本解决问题带来的隐患，尤其是一些金融机构，一些开源组件一旦选型后在企业内部依赖的非常深，一旦出现问题官方无法维护更新，需要自己去更新维护的成本就会非常高。所以通常在使用开源组件选型时，对开源组件的维护状况、维护者的质量进行有效的评估就显得尤其重要。当前一些头部企业有能力投入进行统一的重打包（如先进行一层安全的封装再给业务调用）和维护，但其他公司则可能还没有这方面的投入，一旦官方开源组件不维护了就会比较被动。
二、全球及中国关于软件供应链安全相关的监管趋势如何？
欧美法律法规：
2021 年 5 月 12 日，拜登政府签发《改善国家网络安全行政令》[1] 明确要求联邦政府必须采取行动，迅速提高软件供应链的安全性和完整性，并优先解决关键软件问题。此行政令是在 Solarwinds 投毒事件及科洛尼尔输油管攻击事件背景下发布的。
2022 年 4 月，美国食品药品监督管理局 （FDA） 在 FDA-2021-D-1158《医疗器械网络安全指南草案》[2]中建议医疗器械企业在上市前提交时将“网络安全材料清单”替换为“软件材料清单”
2022 年 5 月 5 日，美国国家标准与技术研究院（NIST）发布 SP 800-161《联邦信息系统和组织的供应链风险管理实践》[3] 标准，该标准文件用于指导联邦政府如何科学管理软件供应链安全风险。
2022 年 8 月，美国国家安全局 （NSA）、网络安全和基础设施安全局 （CISA） 以及国家情报总监办公室 （ODNI） 联合发布发布了《保护软件供应链：开发人员推荐实践指南》 [4]，对开发者、软件供应商及软件使用方如何提升软件供应链安全提供指导。
2022 年 9 月 14 号，美国政府发布《通过安全软件开发实践增强软件供应链的安全性》[5]的备忘录，该备忘录要求所有为联邦机构提供软件产品及服务的第三方必须提供符合标准的 SBOM 以证明自己软件的安全性，同时通过这种方式来帮助联邦政府机构在发现新漏洞时快速识别相关风险。
2022 年 9 月 15 日 欧盟发布了题为《网络弹性法案》[6]（Cyber Resilience Act）的草案，旨在为联网设备制定通用网络安全标准。法案要求所有出口欧洲的数字化产品都必须提供安全保障、软件物料清单 SBOM、漏洞报告机制，以及提供安全补丁和更新。违反规定的公司将面临最高 1500 万欧元或全球营收 2.5%的罚款。
小结：自 2021 年以来（实际更早几年开始）欧美先是政府层面发布了一些关于软件供应链安全防护的法规及标准，紧接着各行业开始陆续出台了相关的监管要求和落地指南及标准，从联邦政府及关键基础设施企业严格要求开始，逐步将需求传导到了整个软件及数字化行业，从而在欧美涌现了以 snyk 为代表的大量解决软件供应链安全需求的安全厂商。
国内法律法规及标准
2018年10月10日，国家市场监督管理总局和中国国家标准化管理委员会正式发布了国家标准GB/T 36637-2018《信息安全技术 ICT供应链安全风险管理指南》。该标准面向我国信息通信技术（以下简称ICT）供应链安全，旨在提高网络运营者ICT供应链安全管理水平，切实保障我国重要信息系统和关键信息基础设施的ICT供应链安全风险。
2021 年 7 月，工业和信息化部 网信办 公安部 印发 《网络产品安全漏洞管理规定》[7]，致力于规范网络产品安全漏洞发现、报告、修补和发布等行为，防范网络安全风险 。
2021 年 10 月， 中国人民银行、中央网信办等五部门发布关于规范金融业开源技术应用与发展的意见[8]，意见文件对金融行业的开源软件安全治理提出了明确要求。
2021 年 11 月，银保监会向所有金融机构发布《关于供应链安全风险提示的函〔2021〕371 号》 2022 年 3 月 7 日，国家药监局器审中心发布《医疗器械网络安全注册审查指导原则（2022 年修订版）》，文件要求医疗器械产品需为用户提供全部现成软件清单的能力。
- 2022 年 9 月 30 日 关于国家标准《信息安全技术 软件供应链安全要求》[9]征求意见稿征求意见的通知发布，这是国内完全针对软件供应链安全的又一个国家级标准。
2022 年 10 月 30 日，国家标准《信息安全技术 软件产品开源代码安全评价方法》[10]立项完成，启动制定
2023 年 5 月 1 日，GB/T 39204-2022《信息安全技术关键信息基础设施安全保护要求》将正式实施，其中在 7.9 节对供应链安全管理提出明确要求
小结：当前软件供应链安全风险在全球及中国都是共识的严重安全威胁，国家层面正在密集出台相关的法律法规及标准文件，指导各行业加速软件供应链安全的治理工作，以保护国家关键基础设施的安全性和用户的数据安全。
三、如何快速评估企业所面临的软件供应链安全威胁？
作为 CSO/安全负责人，当前是否要关注所在组织的软件供应链风险，这首先需要思考的问题就是当前组织所面临的软件供应链安全威胁有多大？关于这个问题，我们来给出一个简单公式：
软件供应链安全威胁 = 供应链软件引入规模 x 单位供应链软件所带来的潜在威胁
供应链软件引入规模
那么，这个问题就被拆解成两个关键问题，咱们分别来解答，首先是如何快速评估供应链软件引入的规模，本文的第一个问题，我们已经说了企业供应链软件包含生产环境和办公环境中使用的开源组件、开源软件、闭源软件三大部分，那么我们首先需要收集和统计我们能直接看到的软件（先大概列一下思路，之后我会专门写一篇文章来讲这个）：
- 开源组件：统计私有源（nexus、jfrog）、代码仓库、容器镜像仓库等
- 开源软件：统计代码仓库、容器镜像仓库等
- 闭源软件：采购合同记录、企业内部办公软件市场、代码仓库等
然后，通过软件成分分析工具及指纹识别工具来识别我们不能直接看到的供应链软件（开源软件依赖的开源组件，商业软件依赖的开源组件，容器镜像及主机依赖的供应链软件）
- 开源组件依赖：通过源代码成分分析工具对项目代码进行扫描，如对全量代码仓库（gitlab、svn）进行扫描
- 开源软件依赖：通过源代码成分分析工具对项目代码进行扫描，如对全量镜像仓库（harbor）及主机（linux、windows、macos）进行扫描
- 闭源软件依赖：通过二进制成分分析工具对闭源软件的二进制安装包、运行文件等进行扫描，如将所有采购的软件的软件安装包上传到成分分析系统进行扫描
之前有不少企业安全负责人在交流的时候，说他们企业几乎没有使用开源组件或者很少，那么他大概说的是第一部分能直接看到的供应链软件吧，其实还有大量他无法直接看到的供应链软件依赖（就是间接依赖，包括开源和闭源商业软件的间接依赖）；
通过以上步骤，你大概会得到一份关于三类软件的供应链软件引入规模统计数据，如果你做的非常细致的话，他可能就是一份完整的企业软件供应链资产台账。通过这份统计数据，你可以了解当前企业的供应链软件引入规模及分布情况。
单位供应链软件所带来的潜在威胁
因为不同类型的供应链软件所带来的潜在安全威胁是不一样的，比如 Java 和 nodejs 相关的开源组件带来的安全风险就要远远大于 python 及 go 开发语言，python&go开源组件本身数量没有java和nodejs这么多，java历史悠久、node生态繁荣，python的组件数量大概是java的一半，使用上，国内企业服务大概有一半项目是用java开发的，python和go写在线服务的没有那么多，关注度也就没那么高，所以在评估企业面临的软件供应链安全威胁时，需要引入单位供应链软件所带来的潜在威胁的评估概念。
具体如何展开评估呢？当然最好的方法就是对已识别供应链软件进行安全漏洞匹配，可以通过成熟的 SCA 工具进行源代码及二进制文件的检测；如果你当前还不具备这样的工具，那么可以简单的对开发语言及供应链软件类型进行统计，然后抽样统计；
我所接触的客户企业比较常见的方式是使用 SCA 工具（如果没有采购相关工具，可以先找厂商申请试用）对全量代码仓库、容器镜像仓库及企业收集的一些商业外采软件的二进制安装包、常见的办公软件安装包进行扫描，输出统计报告。这里要分别关注下软件安全漏洞导致的攻击、软件投毒攻击、软件知识产权合规风险、供应中断风险这四类风险的分布情况。
这里我也分享下我对于不同行业和业务类型的企业通常所面临的软件供应链安全威胁情况的了解（基于我交流过的大量企业所积累的经验）：
- 互联网企业：外采系统较少，自研系统以 Java 为主，Java 开源组件安全漏洞威胁较大；另外就是办公软件引入的威胁不容忽视（互联网企业对员工办公环境管理相对宽松，容易下载有后门和投毒的办公软件）
- 金融行业：外采及外包联合开发系统较多，需要重点关注外采软件的软件供应链审查及商业软件 SBOM 资产台账建设，另外头部一些的金融机构自研较多，而且也是 Java 为主，需要关注开源组件的安全漏洞威胁
- 运营商、能源等关基行业：外采及外包联合开发系统较多，需要重点关注外采软件的软件供应链审查及商业软件 SBOM 资产台账建设，另外就是办公软件引入的威胁不容忽视
- 制造及智能制造：外采及外包联合开发系统较多，需要重点关注外采软件的软件供应链审查及商业软件 SBOM 资产台账建设，除此之外需要关注一些 IoT 设备的固件引入的风险
- 涉出海业务企业：首先需要关注开源组件许可证风险，海外对许可证审查比较严格，另外就是自研的系统较多，需要重点关注开源组件漏洞
四、关于软件供应链安全治理思路是什么？
先说结论，软件供应链安全的治理需要实现供应链资产的调用透明、调用过程中引入的风险透明并具备持续风险处置的能力，从这三个方面的需求出发，软件供应链安全 = 软件供应链应用安全治理 + 软件供应链攻击面管理；软件供应链应用安全主要解决的是软件供应链在引入和应用过程中的持续漏洞及合规治理，将安全治理左移，而软件供应链攻击面管理主要是保障供应链软件发布后的持续监测和应急处置。
软件供应链攻击面管理之资产透明：
这一点在我们和蚂蚁的长期合作过程中，被蚂蚁负责应用安全的小哥提的比较多的词汇就是关于供应链软件资产及风险的透明管理和纵深防御的理念。那么关于如何做到资产透明，本质上是对企业引入供应链资产的准入准出管理，以及供应链资产从准入后到生产、办公过程中的应用跟踪。
从准入上来说需要对重点的几个入口进行把关，比如开源组件引入（关键点是私有源仓库、镜像仓库），商业软件的准入（关键是采购流程），办公软件的引入（关键点是企业办公应用市场，mdm 终端管理）
对于任何一个企业来说，软件资产的管理永远是一个动态的过程，我们需要持续跟踪软件资产的流动，比如从引入到二次开发、编译构建、测试、部署，全过程的跟踪，最终我们需要看到的是在什么时间点，任何一个供应链软件资产被通过直接或间接依赖的方式引入到哪个应用中，并部署在哪个机器。
关于准出，准出的管理首先得卡住增量，然后逐步替换下线存量，增量的卡位你往往卡住准入的关键点，设置黑名单即可，关于存量的准出下线，首先要制定配套的替代方案，然后准确识别存量的调用情况，再逐步有序的下线存量的调用，降低存量风险。
供应链风险的透明管理
供应链软件的风险来自于在特定场景下使用了有安全缺陷的供应链软件所带来的安全漏洞、组件投毒、合规风险及供应中断的潜在威胁，那么我们可以通过一个公式来对安全风险进行说明，安全风险 = 供应链软件本身存在的缺陷 * 触发该缺陷的场景；从这个公式中可以看到首先我们需要通过一个完善缺陷知识库（漏洞知识库、许可证知识库、组件特征知识库）来匹配供应链软件对应的风险缺陷，然后就是对于触发该缺陷的场景的识别，包括漏洞利用点、代码中对漏洞利用点的调用分析，漏洞依赖的前置条件等等。
过去，软件供应链安全风险的治理是缺乏触发该缺陷的场景的检测能力的，所以对安全风险的识别是不闭环的，也就意味着安全风险的不透明。今天如果我们要解决软件供应链风险透明的问题，那么意味着就必须解决关于漏洞触发场景的识别。这也是墨菲安全在软件供应链安全检测能力探索上的一大创新和进步。
供应链风险的左移治理
我们都知道安全风险的治理越左移效率越高，且同时要遵循纵深防御的思路；关于左移最重要的就是管好准入，开源组件的准入，选型评估（安全、合规、性能、可扩展性、业务场景适配等），这些评估项最好都有专业的自动化工具做支撑，通常业界比较成熟的做法就是设置私有源安全网关，对高危风险组件设置管理基线，对入到私有源的组件持续进行安全漏洞和投毒检测，此外就是通过准入评估的开源组件最好做一些安全相关的封装（这一点在和工行的安全专家老师交流时提供了非常好的思路）；
商业软件的准入，需要在采购的时候进行二进制的软件安全风险评估，屏蔽长期存在安全漏洞或者对安全维护能力较差的厂商；同时要求采购的商业产品主动出具安全检测报告也是一个很好的选择，最起码厂商需要出具符合标准的 SBOM 清单以供安全评估和资产台账的登记。
通常我们知道大多数企业是没有办法在准入的入口做非常严格的卡位的，而且即使做了严格的卡位，也并不能解决掉所有的高危风险，主要有几方面的原因：往往越是主流的使用的多的开源组件被曝出的漏洞就越多，而开发者在选择主流开源组件的时候除了这些组件之外其实没有太多可选项，所以很多时候准入的时候并不能一刀切；另外第二方面原因是一般准入的时候开源组件评估并没有很大的安全风险，但是随着后续开源组件不断爆出新漏洞和威胁，出现了大量新的安全漏洞，对线上业务造成很大影响，基于这两方面的原因，所以基于供应链软件在开发流程中的安全纵深防御就显得尤为重要了，从开发者的代码开发环节、代码入仓、编译构建、容器镜像、发布上线、线上持续监控 0day 漏洞及投毒情报等环节进行安全检测和持续修复是保障全生产流程软件供应链安全的关键所在。
五、软件供应链安全治理应该从何入手？
看完前面四个问题，你差不多会认为软件供应链安全治理是一件非常复杂的工程，通常面对复杂的工程，我们需要对他进行解构，并找到切入点。这里分享一下我们不少客户的一些最佳实践：
暂时无法在飞书文档外展示此内容
风险摸底
第一步，你首先得对当前公司存在软件供应链安全风险做一个快速的摸底，让公司管理决策层对软件供应链安全风险有一个清晰的认知，这几乎是任何一项安全工作开展的前提。至于怎么快速的摸底，大概有几种手段：
1）使用检测工具对代码仓库的所有存量代码做一次扫描（可以申请一个墨菲安全商业工具的一个月免费试用），输出一份全量仓库的依赖及关联漏洞分析报告；
2）使用检测工具对 harbor 仓库的所有容器镜像做一次扫描，输出一份全量镜像仓库的依赖及关联漏洞分析报告；
分析报告怎么写呢？首先你得说一下软件供应链安全是什么？过去同行都出了多少这样的问题，导致了什么样的严重后果，然后再通过前面说的代码仓库和容器镜像仓库的检测结果来侧面说明下类型的安全威胁有多少，大概是一个什么样的规模？如果 ok 的话，最好找 1-2 个漏洞做一个演示，以证明这样的问题有多严重。这样可以比较立体的呈现软件供应链安全威胁有多严重，简单提炼成一个公式就是：软件供应链安全威胁 = 典型的安全问题及危害 x 这类问题的规模。
这一步的最终目的是让公司管理决策层对软件供应链安全潜在风险有准确认知，同时让软件供应链安全能力建设的必要性和价值得到充分认可，事情本身的价值及必要性确定之后，接下来就是落地方案的设计及运营。
制定治理规划
第二步，在前一步明确清楚相关风险且安全价值得以呈现之后，我们需要设计一套关于软件供应链安全治理的整体方案，这个方案的整体设计思路就是我们在第四个关键问题的设计思路上说表述的核心思想，这一章节我们重点谈谈如何找到合适的切入点，将整体解决方案的第一步扎实落地，万事开头难，在这个过程中我们需要把最高优先级的高危风险组件列出来，以治理高危风险组件为切入点，推动将软件供应链安全的检测及治理能力嵌入至开发流程，核心关键点其实就是主要关注到代码仓库的接入集成、编译构建过程的集成、私有源网关插件接入、容器镜像仓库配置对接等等，一旦安全的能力潜入至开发流程，那么后续持续提升软件供应链安全治理水平就有了非常好的抓手。
能力深化
第三步，其实到第二步就已经算是建立了初步的治理能力，顺利的话也会取得阶段性的成果，那么接下来要做的就是基于这个治理流程基础作为抓手，再迭代安全治理能力，把源头的准入准出、过程的持续检测修复和事后的应急预警，把安全能力逐步提升，包括漏洞情报的覆盖、治理组件范围的扩大、安全左移的完善度等等；
六、如何构建高效的软件供应链安全持续运营体系？
谁是主导者？
先来聊一聊在软件供应链安全治理体系中，应该谁来作为主导和负责的角色，有哪些角色怎么高效协同？
我们知道，运营的目的是让安全能力高效解决预期的核心痛点问题，进而产生公司价值。而软件安全漏洞最终解决问题的人一定是开发者，那么所有跟软件安全相关的问题，想要效率高，就必须缩短安全问题到开发者之间的距离，流程越长效率越低，过去很多企业解决软件安全问题的模式是以安全工程师为核心，研发工程师配合的模式：
暂时无法在飞书文档外展示此内容
导致这种模式的原因是研发不懂安全，然后安全检测工具又非常专业，最后就是只能安全工程师使用安全工具检测出安全问题后，经过一系列的理解、验证、工单发送等流程后传递给研发，研发再理解安全工程师表述的问题，然后分析自己写的代码，研究如何去修复这个安全漏洞，修复过程中不懂的再和安全扯皮，或者不认可的或者看不懂的漏洞，就干脆不修复了。就算费劲修复了，也得在找安全确认一下。这一套流程下来，我们看到实际是非常复杂的，导致漏洞修复效率极低。
那么有没有一种可能，让研发工程师直接使用工具解决安全问题，而安全工程师只需要配置一些安全策略指导研发需要解决哪些问题即可，最多是在一些非常复杂的安全问题上，安全工程师给予研发一些支持。这样整个安全问题处置流程路径就会变的更短，效率更高。
暂时无法在飞书文档外展示此内容
清晰的管理策略和好用的工具支撑
如果确定了研发工程师是代码安全的第一责任人，安全工程师制定安全管理策略的同时通过产品工具赋能研发工程师的大策略，那么运营过程中有几个关键点：
暂时无法在飞书文档外展示此内容
首先，管理策略要清晰，清晰到可执行的程度，根据这个策略，研发工程师结合安全提供的产品工具，具体需要执行哪几步操作就能够满足。一定要简单且清晰，一看就懂，不然就很难执行；然后管理策略的执行结果是可以回收的反馈的，这可以让所有的研发和研发 leader 能够看到做了哪些事情，具体产生了哪些价值，这样即方便了后续的过程管理，同时也可以对结果进行奖惩。
然后，安全工具要能够极低成本嵌入至研发当前的开发流程，尽量不要改变研发当前的工作习惯，同时工具的使用成本要低，给研发交付的应该尽可能是具体可执行的操作，这个操作是在前面管理策略中明确的。所有的操作有结果反馈。这里面有几个关键点，首先是面向研发要说“人话”，尽量不要专业术语，其实对研发来说，他希望你描述的风险是清晰且具象的，具体到对业务会造成什么实际影响；此外，针对这些问题的处置措施是清晰的，具体到需要执行一个什么样的动作，是升级某一个组件版本？还是修改什么配置？做这样的操作会存在什么的隐患和效果？最好是透明的。
持续运营，润物无声
最后，针对开发者的持续培训和技术支持工作是必不可少的，持续的培训、宣导和工具迭代、及时高效的技术支持，是润物细无声的操作，也是必须的操作。培训的内容主要是围绕不同的角色的不同操作场景进行开展，另外最好嵌入新员工的入职培训流程，作为入职必备项去卡位。最终我们还需要持续的能够对各个环节的各个角色的工作质量和结果能够反馈出来，做的好的持续有正反馈，激励持续提升，做的不好的也能够通过数据持续反馈出来帮助及时发现问题，及时提升和调整。
七、软件供应链安全治理过程中最大的技术难点及挑战是什么？
开发者修复问题成本
这里的开发者是泛指维护这个软件项目的技术人员，包括自研软件的开发者、外采商业软件的运维者等，过去一年跟很多企业的应用安全负责人沟通，很多工作在推进运营落地的时候很难，因为你会发现几乎每一项涉及软件安全相关的工作，都需要软件的开发者和维护者深度参与，但是软件的开发者和维护者通常又不懂安全专业，而懂安全问题的专家似乎又不太懂业务和工程技术，那么两者在一起协同去解决软件安全相关的问题就会变得尤为困难。
如果安全工程师能把针对软件安全的所有问题转化成需要研发去做的操作，比如通过 IDE 插件执行一键升级？比如安全把漏洞修复的操作转化成研发需要在 gitlab 上做的一个代码 merge 的操作？如果能做到这种程度，是不是开发人员也没必要费劲去理解这个安全问题是什么，然后再研究如何修复。看起来如果能做到这种程度，那将是一件非常酷的事情？
当然，做到这种程度并不简单，就拿开源组件漏洞的修复来说，首先安全工具识别出来真正会对线上代码逻辑造成攻击的开源组件漏洞，这一步将大大降低一些误报，因为通常代码中会依赖大量存在缺陷的开源组件，但是大部分的开源组件安全漏洞并不会在线上代码逻辑中被触发；第二，接下来是修复漏洞，通常开源组件的漏洞修复需要升级组件版本至一个安全的版本，同时这个时候要兼顾升级之后带来的兼容性问题，研发同学最担心的就是修复完就挂了；第三，将修复行为转化为工具的一键操作，毕竟开发者去理解文字版的修复方案再梳理代码逻辑，然后再执行修复操作，这个过程也大大增加了理解成本和错误操作的风险。
关于安全漏洞的一键修复，墨菲安全在上面三个维度投入了非常多的精力去实现，目前能够基于兼容性评估、自动帮助开发者一键修改到最佳修复版本（支持回滚），大大提升开发者修复漏洞的效率，这个能力也几乎是所有客户关注的核心能力，去年这个时候，我们说我们做了一件修复能力，很多客户和开发者还表示质疑和担心，但是今天我们已经有超过80%的开发者用户在使用这个功能，一键修复漏洞的成功率90%以上。
资产台账的动态管理
企业的供应链软件资产是不断的动态变化的，只要研发还在工作，公司还在采购软件，采购的商业软件还在维护升级，办公电脑还开着机，那么企业的供应链软件资产就会不断的新增和更新。供应链软件资产每天的动态更新就会带来新的安全隐患，所以资产台账的动态管理就尤为关键。
想要持续动态管理这些资产，有三个关键点：
1）将软件成分分析工具集成至企业软件准入及生产管理流程，如 gitlab、私有制品仓库、CI/CD、容器镜像、软件采购流程及内部办公软件上架流程
2）保障软件成分分析工具的识别覆盖率及准确率，包括对源代码的识别、二进制文件识别及 IoT 固件识别
3）资产关联到人，且资产关联到线上发布的应用，并支持对资产的分类分级标签，进行分类分级治理
供应链软件漏洞及情报能力
每天大概有几十个 CVE 漏洞及在野漏洞被曝出，还有每周超过 100 起的组件投毒事件，每天面对这么多层出不穷的风险，企业需要快速的应对这些通用漏洞可能带来的攻击。这些威胁一旦出现漏判或者误判很有可能对企业的线上业务带来严重威胁。所以高质量的漏洞及投毒组件情报能力对企业持续做好软件供应链安全的高质量保障就非常必要，定义高质量的漏洞及情报能力可以用四个字来总结：全、准、快、精。
情报的全：需要保障覆盖率，这是一件非常有挑战的事情，既要及时覆盖 CVE 漏洞，又要关注一些在野漏洞，还有每天都在发生的软件投毒，这就要求有非常强的情报采集能力（技术+圈子），此外就是很强的组件投毒挖掘能力，更强一点的话就是要有能力挖掘一些自己独家的漏洞情报；
情报的准：每天有各种各样的情报，哪些才是真正有威胁甚至高危的漏洞情报，这就需要从各个渠道收集到这些情报后进行分析研判，首先判断漏洞的真实性，然后深入研究分析漏洞的前置利用条件、影响范围及影响程度，最后输出一个客观的结论，便于负责应急运营的同事做出准确的应急动作；
情报的快：攻防的对抗就是时间的对抗，0day 漏洞和投毒这种事情一旦攻击者比企业更快拿到情报且分析出来攻击样本，那对于企业来说，被入侵的风险就大大增加，所以情报的挖掘和分析效率就显得极其重要。情报的采集和分析，应该有足够强的安全专家再加上沉淀下来的分析流程（借助一些自动化的辅助工具提升效率），为情报分析设置合理的阶段，并不需要一口气分析出来 poc，先确定漏洞的真实有效性，影响程度，再分析如何处置，最后才是 poc。
情报的精：漏洞如何排查？指纹是什么？准确的影响范围？有缺陷的类、函数及调用方法是啥？如何修复？如何止损？这些都是在应急处置中，真正有价值的高质量情报，往往缺一不可。
八、如何衡量软件供应链安全治理的好与坏？
还记得在贝壳工作的时候，有一次工作述职，鸟哥（贝壳技术副总裁，如视负责人）问了我一个问题：安全负责人的职责是什么？
我记得当时的回答是：安全负责人就是负责随时能把公司的安全风险向公司管理层说清楚，并且给出科学的风险治理建议及对应的成本收益评估，方便管理层在公司风险控制方面做出正确的决策，最后是负责将决策高效的执行落地。
所以，我认为如何衡量软件供应链安全工作治理的好？那就是随时能够说清楚公司在这个方面存在的风险情况，并且能够科学的帮助公司评估每个阶段的治理目标，并最终负责执行落地。
我们把这件事拆解开来看：
1）随时说清楚公司在软件供应链安全方面存在什么样的风险？做好软件供应链资产盘点及风险识别，包括对业务分类分级的风险识别。
2）科学帮助公司评估出当前阶段的治理目标？通常包括同行业同体量公司的横向对比，公司战略目标的关联拆解，公司业务背景下重大风险的识别，结合这几个点给出当前公司的合理治理目标
3）高效执行落地？目标的合理拆解，科学的实施方案及组织协同。
如果随时能把以上三件事情做好，并且随时能给出清晰的结论，那么我们相信公司管理层会认为这类风险非常的透明和可控。那我们作为安全负责人就是公司喜爱的好同志。
九、国内外关于软件供应链安全治理有哪些最佳实践？
通过我的观察以及和上百家的客户交流发现，国内软件供应链安全的治理需求正在快速释放，但是关于软件供应链安全的治理思路明显还在沿用老的肌肉记忆，也就是开发安全那一套思路在开展工作，比如在国内提到软件供应链安全治理，大家说的更多的还是 DevSecOps 或者 SDL，实际上 DevSecOps 或者 SDL 更适用于企业自研软件的安全治理解决方案，而针对软件供应链安全的治理，在欧美目前比较前沿的思路有两个：
1）以 SNYK 的开发者优先理念为代表的软件供应链安全治理新思路，开发者是解决软件安全问题的最终用户，也是关键所在，所以软件供应链 2.0 的产品思路应该围绕如何直接面向开发者提供安全能力，缩短安全问题处理的流程，极大提升处置效率。墨菲安全非常认可这个思路，并且在和国内很多企业客户交流的过程中，其实我们发现这是几乎大家都所期待的方向，只不过这对于过往安全管理流程及安全产品设计会带来很大的挑战，新的产品能力需要设计者非常懂企业的开发场景、开发者及安全攻防，这无疑是非常大的挑战，也是今天墨菲安全整个团队正在努力的方向。
2）以 Google SLSA 框架为核心理念的关于软件供应链持续可信验证的治理思路，对供应链软件的生产、分发、使用等全过程进行持续的签名和验证，防止供应链软件在整个生产及应用的过程中被篡改所带来的安全风险，当前 Google Cloud 的托管 CI/CD 平台内置了这样的安全能力，但是在国内几乎没有关于这个能力的实践。
当然，在国内我们依然看到非常多优秀的公司正在积极的探索和实践以新的方式去落地软件供应链安全的治理，我们看到像蚂蚁、美团、快手等一系列互联网公司，还有像中国移动、电信等运营商，以及一些头部的金融机构都在积极的探索和实践。目前来看，大家分别从软件成分分析、漏洞及投毒情报、私有源的准入准出治理等方面其实也已经有了更多新的创新的研究和治理思路，只不过要逐步形成一套成熟的体系和技术能力还需要一些时间。
十、关于软件供应链安全理解的误区？
软件供应链安全在国内大概也有这 2-3 年提的比较多，因为国际竞争形势和重大事件的双重推动下，从国家监管到行业监管再到企业内部安全治理方面，软件供应链安全被提及的越来越多，但是大家对于软件供应链安全的理解不尽相同，我这里也简单梳理一些经常会碰到大家对软件供应链安全理解的误区，分享给大家。
软件供应链安全 = SCA？
为什么大家会简单的把软件供应链安全和 SCA（软件成分分析）划等号，我认为大概有两个方面的原因，一方面是因为 SCA 确实是软件供应链安全治理过程中的一个基础技术或者产品工具；另外一个方面是因为 SCA 在国内外权威市场调研机构的报告中很早就有成熟概念被提及，所以大家其实对 SCA 这个概念更熟悉，然后现在软件供应链安全火起来了，SCA 又是其中被提及的最多的产品概念，所以这个时候很多人一提起软件供应链安全就会关联到 SCA。
实际上 SCA 只是治理软件供应链安全过程中的一个基础工具，大概就相当于新冠病毒治理过程中的核酸检测和病毒分型化验相关的角色。更多的承担了成分分析的工作，实际上软件供应链安全的治理还需要依赖私有源网关、投毒及漏洞情报、代码合规管理、持续可信验证等很多技术及产品工具。
软件供应链安全 = 开源风险治理？
大概率是因为在企业的供应链软件中，开源相比闭源软件来说，开源占比是要远远高于商业外采软件的，这也导致开源安全漏洞对企业的影响相对商业外采软件要大，所以一提到软件供应链安全，大家自然而然就关注到开源安全治理。
实际上，软件供应链安全 = 开源风险治理 + 闭源软件风险治理（含商业和免费闭源软件）
软件供应链安全 = DevSecOps？
过去大家干了 5-10 年的 DevSecOps 和 SDL，主要都是解决开发安全的问题，但是过去 DevSecOps 的管理理念更多的是解决自研的软件安全。而今天软件供应链安全还是会更多覆盖非自研部分的代码及商业外采软件，包括未来随着企业数字化和信息化程度越来越高，企业软件的开发会越来越组件化，由供应链组成的成熟度会越来越高，这也会使得未来企业软件安全的治理模式会从传统的DecSecOps模式转变成供应链安全治理的新模式。
