诸子笔会 | 刘顺：软件开发过程中供应链安全的风险与治理
自2021年6月起，安在征文全新“改版”——“诸子笔会，打卡征文”。简单来说，我们在诸子云社群招募“志愿者”，组成“笔友群”，自拟每月主题，互相督促彼此激励，完成每月一篇原创，在诸子云知识星球做主题相关每日打卡，同时邀请专业作者群内分享，互通交流。我们的目标，不仅是在持续8个月时间里，赢取累计8.8万的高额奖金，更是要探索一种脑力激荡、知识分享的新思路和新玩法。本期发文，即诸子笔会月度主题来稿之一。
软件开发过程中供应链安全的风险与治理
文 | 刘顺
刘顺
某金融机构 安全专家
在当今这个“软件定义一切、软件使能一切”的时代，软件技术飞速发展，软件安全领域的方法和工具已逐步完善，但是软件开发过程中的供应链安全，这一新型安全风险正在使得企业面临严重的安全威胁。
软件开发过程中的供应链安全，是指企业在软件设计与开发过程中，面临的因供应链上游原因导致软件存在安全风险。与传统的软件安全漏洞相比，软件供应链安全的攻击面由原来的软件自身，扩展到软件内部的所有代码，以及供应链上游供应商的开发过程、开发工具和供应商网络边界等，攻击面的增大显著降低了攻击难度。同时，软件供应链的安全风险将影响供应链中下游阶段的安全，因此攻击影响被显著扩大。从这两个方面可以看出，软件开发过程中的供应链攻击具有低成本、高效率的特点。
软件开发过程中供应链安全风险的分类
按人员以及合作模式的不同，我们可以把企业软件的开发活动分为外包开发驻场、外包开发非驻场、采购产品、采购产品定制化开发四种类别，其中涉及的安全风险包括源代码污染、开源软件安全、源代码安全漏洞、源代码信息泄露四种，本文重点分析的是软件开发过程中的供应链安全，软件交付使用过程中涉及的软件可用性、数据安全、个人信息保护等方面的风险不在本文考虑范围之内。
针对软件开发过程中的四类供应链安全风险，具体介绍如下：
（一）源代码污染
源代码污染是指攻击者通过各种方式攻击了上游软件供应商，在软件开发、构建、传播、升级的过程中，非法对软件供应商的源代码进行篡改，对软件传播、升级进行劫持，利用软件供应商与企业用户之间的信任关系，达到绕过安全产品检测，最终达到成功攻击软件供应商下游企业的目的。
源代码污染典型的案例是发生在2020年12月份的SolarWinds攻击事件。全球最著名的网络安全管理软件供应商SolarWinds遭遇了高度复杂的供应链攻击，SolarWinds旗下的Orion基础设施管理平台，其发布环境遭到黑客组织入侵，黑客对源码中的SolarWinds.Orion.Core.BusinessLayer.dll文件进行篡改并添加了后门代码，后门代码可随软件更新被下发到下游客户的网络环境中。同时，由于Solars的令牌已经被其客户信任，攻击者伪造的令牌成功欺骗并绕过了安全防护。后门代码伪装成Orion OIP协议的流量进行通信，将其恶意行为融合到SolarWinds合法行为中，从而达到隐藏自身的目的。攻击者通过后门可以完成对目标机器的完全操控，包括任意启动进程，执行下发的文件，快速在内网中构建出攻击阵地，并向内渗透。同时该后门支持对文件hash进行校验，避免了误操作或者上传无效文件。设置的注册表项提供了持久驻留功能，保证系统重启后仍能正常执行后门功能。该攻击直接导致美国在内的北美、欧洲、亚洲和中东的一些关键基础设施，政府、军队、咨询企业、技术公司在内的18000+企业受到影响。
（二）开源软件安全
现在的软件大多数是被“组装”出来，不是被“开发”出来的。无论是企业自己开发，还是外包给供应商开发，开发出来的软件其源代码基本上都是混源代码，即由自主开发的源代码和开源软件代码共同组成。开源软件作为软件开发最基础的原材料，位于软件开发供应链的源头，开源软件的安全会直接影响最终软件的安全性。
根据奇安信发布的《2021中国软件供应链安全分析报告》，2020年开源项目总量较2019年增长了34.2%，主流开源软件包生态系统中平均每个开源项目有10.2个版本，可以看出，开源软件生态更加繁荣，整体发展非常迅猛。2020年奇安信代码安全实验室对2557个国内企业软件项目中的开源软件情况进行了分析，无一例外，所有的项目都使用了开源软件，平均每个项目使用126个开源软件，可见开源软件在企业软件开发活动中的普及程度。但开源软件的安全漏洞缺不容乐观，据统计，开源软件整体缺陷密度为10.11个/千行，高危缺陷密度为1.08个/千行。漏洞类型包括输入验证、路径遍历、注入、NULL引用、API误用等等，这些安全漏洞可直接导致企业软件被攻击。
（三）源代码安全漏洞
源代码安全漏洞是指企业开发人员或者软件供应商的开发人员，在编写自有代码时，因为编码不规范、安全意识不足等原因，导致编写的代码中存在安全漏洞，漏洞类型包括注入、跨站脚本攻击、跨站点请求伪造、敏感信息泄露等，这些包含漏洞的代码如果被发布到生产环境，可直接导致企业软件被攻击。很多供应商会因为自身规模小、监管要求不严、安全需求不强烈等原因，未开展或未体系化的开展网络安全建设工作，其开发出来的源代码可能会包含较多的安全漏洞。供应商源代码中的安全漏洞也是供应链安全中需要考虑的一个重要风险。
（四）源代码信息泄露
源代码信息泄露是指企业或者软件供应商，因数据安全管控体系不健全，或代码管理类工具配置不规范等其他原因，最终导致源代码泄露，攻击者拿到源码后可以从源码中获取敏感信息，或者基于已获得的源码开展代码安全审计，从而可以更快速、更全面的找到软件安全漏洞，以实施进一步安全攻击。在软件开发过程中，供应链安全风险主要考虑的是供应商自身原因导致源代码信息泄露的风险。
另外，一些源代码管理类的开源软件也可能导致源代码被泄露，比如最近热议的境外某黑客组织利用SonarQube（一款开源静态代码质量分析管理工具）安全漏洞（CVE-2020-27986），窃取了数十家重要单位的大量源码，并公然兜售。漏洞原因是因为SonarQube在默认配置的情况下，缺少对API 接口的访问权限控制，攻击者可利用该漏洞在未授权的情况下，通过访问api/settings/values接口从而获取到 SMTP、SVN、GitLab 凭据，进一步获取源代码数据仓库中的源代码。同时也可以利用默认的账号密码，获得敏感配置信息，从而进一步窃取企业源代码。
国家层面对软件供应链安全的治理情况
软件开发过程中面临的供应链安全具有风险种类多、威胁等级高，攻击隐蔽性强、攻击扩散范围广等特点，而且越往上游的攻击影响量级就越大。因此，近年来，围绕供应链攻击的防御和治理，也成了国家层面安全领域的重要研究方向。重要国家的一些治理措施如下：
盟国间加强供应链安全的合作，2011年6月，美国与欧盟委员会在布鲁塞尔签署了《供应链安全联合声明》，为供应链风险管理与安全提供直接的支持。2012年，美国和日本共同发布《美日全球供应链联合声明》。
2015年4月，美国国家标准与技术研究所（NIST）发布了《联邦信息系统和组织的供应链风险管理实践》NIST Special Publication 800-161，该出版物为美国联邦机构的各个级别组织在确定、评估和缓解信息和通信技术（ICT）供应链风险方面提供了相应的指导。通过采用针对供应链风险管理（SCRM）的多层特定方法，将SCRM集成到联邦机构的风险管理活动中，这其中包括了有关如何评估供应链风险和实施缓解活动的指南。
2016年10月，英国国家互联网应急中心（CERT-UK）发布供应链网络安全风险白皮书，其中,介绍了各类软件供应链的风险案例和规避建议。
2018年10月，我国发布了《信息安全技术 ICT供应链安全风险管理指南》（GB/T 36637-2018），从供应链安全风险管理过程以及管理举措两个大的方面，对重要信息系统和关键基础设施的ICT供方管理其供应链安全风险提出了规范要求。
2020年4月27日，我国国家互联网信息办公室等12个部门联合发布了《网络安全审查办法》（以下简称审查办法），要求关键信息基础设施运营者采购网络产品和服务，影响或可能影响国家安全的，应当进行网络安全审查。审查办法作为落实《网络安全法》第三十五条提出的网络安全审查制度的重要制度文件，将重点关注关键信息基础设施采购网络产品和服务可能带来的国家安全风险，确保关键信息基础设施供应链安全。
2020年5月，我国电子商会发布了《软件代码开源成分与安全检测指南》（T/CECC005-2020），规定了软件代码开源成分及其安全性检测的检测过程及方法，描述了代码中开源成分及其安全性检测的检测条款。
2021年3月，开源首次被明确列入《中华人民共和国国民经济和社会发展第十四个五年规划和2035年远景目标刚要》，支持数字技术开源社区等创新联合体发展，完善开源知识产权和法律体系，鼓励企业开放软件源代码、硬件设计和应用服务。
2021年5月，在科洛尼尔管道运输公司(ColonialPipeline)因遭遇勒索软件网络攻击暂停运营后，美国总统拜登于当地时间5月12日签署了《改善国家网络安全的行政命令》，其中包括九项关键举措，其中第四项加强软件供应链安全，这是美国在软件供应链安全采取的最强劲措施。
2021年9月，中国人民银行办公厅、中央网信办秘书局、工业和信息化部办公厅、银保监会办公厅、证监会办公厅以银办发〔2021〕146号联合发布《关于规范金融业开源技术应用与发展的意见》，旨在规范金融机构合理应用开源技术，提高应用水平和自主可控能力，促进开源技术健康可持续发展。
软件开发过程中供应链安全风险的治理措施
企业在面对软件开发过程中供应链安全风险时，可以参考上述国家层面的各类标准要求，从面向供应商的安全管控以及企业自身安全管控两个方面，开展源代码污染、开源软件安全、源代码安全漏洞、源代码信息泄露这四类安全风险的治理工作。重点举措详细介绍如下：
（一）整体上建立供应商安全管控体系
针对软件开发过程中的供应商，安全管控体系思路如下图所示，即根据合作需求背景，从合作模式、风险暴露面、风险类别三个维度对供应商进行安全风险等级划分，并按等级划分结果分别在合作前、合作中、终止合作时实施一系列的安全管控措施。
软件供应商安全管控体系思路
其中软件开发过程中与供应商的合作模式分为：开发外包驻场、开发外包非驻场、采购产品、采购产品+定制化开发。
风险暴露面即供应商负责开发的应用系统或从供应商采购的应用系统，在企业中部署的网络区域，包括互联网、内网两种。
风险类别即本文第一章介绍的四类风险，包括源代码污染、开源软件安全、源代码安全漏洞、源代码信息泄露。
最终把供应商的安全风险等级由低到高划分为1-4级，根据不同的安全风险等级制定不同的安全管控措施，包括合作前供应商安全评估、合同安全条款约束、合作中供应商安全审查共7大项管控措施。
软件供应商安全管控体系具体执行矩阵如下图所示：
在开发外包驻场的合作模式中，安全原则是把外包开发人员作为企业内部人员共同管理。包括统一配发办公终端，统一申请办公账号与权限，统一办公终端的网络权限及终端外设权限，统一开发要求与规范等等。
下面将分别介绍上述安全管控举措：
（二）合作前供应商安全能力评估
相信大家都遇到过这种场景，即企业采购回来一个应用系统，网络安全团队在对系统开展安全测试时，经常会发现采购系统中存在大量的安全漏洞。在把漏洞提交给供应商要求修复时，可能供应商的开发人员都不清楚何为安全漏洞，不清楚各类安全漏洞的影响和危害，更别提如何修复漏洞。所以，网络安全团队不仅要花时间给供应商的应用系统进行了免费渗透测试，还要花大量时间向其开发人员普及安全漏洞知识，讲解安全漏洞修复方案。如果把网络安全团队的这些工作看做一个安全服务项目，按市场上安全服务项目价格计算，可能比采购这个应用系统本身的合同价格还高。为了尽可能避免企业网络安全团队免费为供应商“打工”，针对开发非驻场外包模式以及采购的发布到互联网的应用系统，在合作前对供应商开展安全能力评估是非常有必要的。
供应商安全能力评估具体执行方式有两种，一种是通过问卷调研，另外一种是在POC阶段增加系统安全测试。
设计好供应商安全能力评估调研问卷，在合作前让供应商正式反馈，根据反馈结果可以大致了解供应商的安全能力。为了防止恶意虚假反馈，应将反馈结果作为合同附件，使其具备一定的法律效力。同时，在合作中的供应商现场安全审查措施中，也需要对供应商的反馈结果进行检查验证，如果存在虚假反馈应进行考核追责。
供应商安全能力评估调研部分样例如下：
另外，针对采购类项目，应在POC阶段增加安全测试环节，安全测试的结果应作为POC最终结果的一部分，纳入投标评价打分项。
（三）供应商合同条款安全约束
合同条款中增加安全约束的目的是为了明确供应商的安全责任，具体应增加的安全内容包括：供应商安全能力评估调研结果真实性承诺。发现安全漏洞时漏洞修复的安全要求，包括响应时间、漏洞修复时间。信息资产的保密承诺和要求，包括合作过程中负责信息资产的保密，合作结束后按要求删除已不再使用的信息资产，如开发外包非驻场场景中，合作结束时供应商应按要求删除项目中的开发代码。因供应商自身原因发生安全事件后承担的赔偿责任，比如开发外包非驻场场景中，因供应商原因导致企业源代码被泄露。
关于漏洞修复要求安全协议参考模板：
（四）供应商交付软件安全要求
在双方正式合作开始时，应提前明确软件交付时的安全要求，具体包括提供《应用系统安全渗透测试报告》（专业安全厂商提供）、《第三方开源组件清单及安全漏洞情况》，遵守《供应商软件开发网络安全红线》要求。
针对开发外包非驻场以及定制化产品开发的合作模式，供应商会为企业提供专属的源代码，因此，需要向供应商明确《供应商软件开发网络安全红线》，要求供应商在开发过程中必须满足红线中的安全要求。
《供应商软件开发网络安全红线》样例：
（五）供应商交付软件安全评估
供应商正式交付软件时，企业应对软件开展安全评估，重点包括核查《供应商软件开发网络安全红线》的满足情况，对软件进行安全渗透测试，对开源软件进行漏洞扫描等。发现漏洞或风险时按合同条款中的安全约束要求供应商修复。
（六）供应商现场或非现场安全审查
为了应对源代码污染、开源软件安全、源代码安全漏洞、源代码信息泄露风险，企业应按需对供应商开展现场或非现场网络安全审查，以评估供应商的整体网络安全能力，督促供应商做好网络安全建设。安全审查前应先制定审查列表，提前将列表同步至供应商，先有供应商开展整改和准备工作。审查列表可以按网络安全控制域的维度，分别细化具体的审查点。审查维度可以包括网络安全组织建设情况、人员安全管理情况、代码等数据安全管理情况、应用安全管控、终端安全管控、访问控制、网络边界安全防护、开发过程管理、开源软件安全管控等方面。
另外，在合作终止时的安全检查中，应要求供应商删除已不再使用的企业源代码，并对删除情况进行审查。
（七）企业自身的安全能力建设
在对软件开发过程中供应链的安全风险进行治理时，企业自身也应加强以下几方面的安全能力建设，简单介绍如下：
（1）建立研发安全体系，解决源代码安全漏洞风险
结合企业开发现状，开展SDL或者DevSecOps体系建设，以“安全左移”为原则，尽可能建立覆盖研发生命周期的安全体系。安全测试阶段应通过黑盒应用安全扫描工具、白盒源代码安全扫描工具、灰盒被动式扫描工具以及人工渗透测试等方式，尽可能发现源代码中的安全漏洞。安全运营阶段应通过外部威胁情报及时获取开源软件、采购产品的安全漏洞情况，以及与供应商相关的安全事件信息。
（2）开展数据安全体系建设，解决源代码泄露的安全风险
为解决源代码泄露的风险，企业需要体系化的开展数据安全建设工作，具体可参见8月份以数据安全主题发布的文章：诸子笔会|刘顺：企业数据安全体系建设实践。
（3）开源软件安全治理
开源软件的风险主要包括许可协议合规以及开源安全漏洞风险，目前商用的开源软件扫描工具也比较成熟，可对上述两个风险进行扫描发现，企业可通过开源软件扫描工具，在软件开发过程中对开源风险进行扫描识别。具体示意图如下所示：
上述治理过程主要包括三个安全管控点，一是开发人员在本地终端进行代码编译时，可根据漏洞策略，禁止本地终端从企业制品库拉取存在高危安全漏洞的开源软件，并通过IDE插件进行相应的提醒。二是在通过持续集成进行构建时，可根据漏洞策略禁止高危开源软件被拉取，并通过持续集成提醒开发人员进行升级修复。三是可通过外部漏洞库威胁情报，自动收集最新的漏洞信息并与内部开源软件台账进行比对，识别漏洞影响范围，并开展漏洞修复工作。
总结
本文主要是针对软件开发过程中的供应链安全风险进行分析，从与供应商的合作模式、风险暴露面、风险类别三个维度对供应商进行安全风险等级划分，并按等级划分结果分别在合作前、合作中、终止合作时提供了一些安全管控的建议。
推荐阅读
诸子笔会 |11月征文合集《供应链安全》
蔚晨：金融机构供应链安全的分析方法和应对之道张永宏：从供应链安全看企业信息化系统风控刘志诚：从供应链到生态——情景化安全的创新与挑战杨文斌：从第三方引入开始思考供应链安全孙琦：企业视角下的软件供应链安全诸子笔会 |10月征文合集《安全周》
张永宏 王振东 赵锐 蔚晨
刘志诚 刘顺 肖文棣 季奖公布
诸子笔会 |9月征文合集《安全团队》
刘志诚 张永宏 刘顺 杨文斌 蔚晨
王振东 孙琦 肖文棣 赵锐 月奖公布
诸子笔会 |8月征文合集《数据安全》
赵锐 刘顺 刘志诚 杨文斌 张永宏蔚晨 王振东 孙琦 肖文棣 月奖公布
诸子笔会 | 7月征文合集《安全自动化》
张永宏 肖文棣 杨文斌 于闽东 孙琦 刘志诚 蔚晨 赵锐 季奖公布
诸子笔会 | 6月征文合集《安全数字化》
张永宏 刘志诚 孙琦 李磊 赵锐 于闽东肖文棣 顾伟 侯大鹏 蔚晨 杨文斌 月奖公布
齐心抗疫 与你同在