供应链安全背景

近年来，针对软件供应链的安全攻击事件呈快速增长态势，造成的危害也越来越大。 不仅仅包含在开发，交付，运行三个环节引入的安全攻击和漏洞风险，开源软件的可持续风险，开源软件的多方依赖，开发供应商提供的代码风险。

供应链安全将是未来的重要挑战

Gartner 预计超过70%的应用程序因使用开源组件而产生缺陷和漏洞。供应链安全将是未来的重要挑战，从网络安全角度去思考的话，可以明显看到当前的商业组织似乎更多的关注自身网络安全建设，但日防夜防、“家贼”难防，任何一个薄弱的供应链都可能成为这个难防的“家贼”。

供应链安全威胁来源

  • 软件/组件更新

  • 开源软件自身漏洞

  • 开源软件引用依赖存在漏洞

  • 开源依赖混乱

  • 恶意开源软件

  • 开源项目后门

  • 恶意开发者提交

  • 供应商代码存在漏洞/后门

  • 第三方人员开发代码存在漏洞/后门

  • 证书被盗

  • 软件开发工具存在漏洞

  • 设备预先安装了恶意软件

法规

《中华人民共和国网络安全法》《网络安全审查办法》《关键信息基础设施安全保护条例》等政策法规强调加强软件供应链安全保障。

2021年5月12日，美国发布了《关于改善国家网络安全》的第14028号行政命令(EO)，明确要求美国联邦政府加强软件供应链安全管控，迅速提高软件供应链的安全性和完整性。今年5月，美国国家标准与技术研究院 (NIST)更新了解决软件供应链风险的网络安全指南，该指南帮助组织将网络安全供应链风险考虑因素和要求纳入其采购流程，并强调监控风险的重要性。

《中国银监会办公厅关于加强互联网业务系统交易安全风险防范的通知》【银监办发（2018）20号】提出金融机构缺乏开源软件安全评估机制、引入选择标准、原则及使用安全策略，要求加强开源技术应用安全评估以及具备出现问题时的异常处置能力。

《中国银保监会办公厅关于开展银行业和保险业网络安全专项治理工作的通知》【银保监办发（2019）129号】要求金融机构建立新技术引用、开源技术应用安全评估与准入机制，加强科技创新、新技术应用的风险监测与处置，深入排查业务流程设计缺陷，推动网络安全风险监测与开发过程的联动，防止因业务创新而降低网络安全管控标准。

《关于开展金融科技应用风险专项摸排工作的通知》【银办发（2020）45号】加强金融科技应用风险防控，切实保障人民群众信息和资金安全，人民银行组织开展金融科技应用风险专项摸排工作。其中包括应不定期组织针对开源系统或者组件的安全测评，及时进行漏洞修复和坚固处理，应对商业银行应用程序接口进行源代码安全审计、渗透测试等技术检查，及时处理安全漏洞，有效控制安全风险。

《金融网络安全 Web应用服务安全测试通用规范》（JR/T 0213—2021）本标准给出了金融网络安全Web应用服务安全测试的通用规范，包括原则、方法和过程，既可作为各金融机构进行Web应用服务安全测试的参考标准，也可以作为行业主管部门、专业测试机构进行检查、检测的参考依据，用以指导。该规范要求应针对开源的高危系统及高危组件设置单独的测试清单并定期进行更新。

《关于规范金融业开源技术应用与发展的意见》（银办发[2021]146号）要求金融机构结合实际贯彻执行

Log4j漏洞

　　从2021年11月全球知名开源日志组件Apache Log4j被曝存在严重高危险级别远程代码执行漏洞以来，黑客已经在尝试利用此漏洞并执行恶意代码攻击，所有类型的在线应用程序、开源软件、云平台和电子邮件服务都可能面临网络安全风险。攻击者可以利用该漏洞远程。

　　根据业界众多网络安全公司的观测，目前大多数Log4j漏洞利用主要是挖矿软件，但攻击者也在积极尝试在易受攻击的系统上安装更危险的恶意软件。据外媒报道，漏洞发现以来，Steam、苹果的云服务受到了影响，推特和亚马逊也遭受了攻击，元宇宙概念游戏“Minecraft我的世界”数十万用户被入侵。美联社评论称，这一漏洞可能是近年来发现的最严重的计算机漏洞。

SolarWinds供应链攻击事件

黑客将恶意代码部署到“Orion”系统的更新中，据统计该系统有超过33000个用户。这次袭击非常隐蔽且手段高明，甚至软件开发人员在14个月后才发现了端倪。由于没有意识到这个漏洞，SolarWinds向安装了这些软件的客户发布了软件更新。这使得黑客不仅可以访问SolarWinds系统，还可以访问每个安装了更新的人的系统。

Apple/Quanta攻击事件

在Apple/Quanta的受攻击事件中，Quanta公司的系统在2021年4月遭到攻击。他是苹果产品的主要台湾供应商。勒索软件集团REvil声称窃取了最新款Macbook的设计蓝图，并索要5000万美元的解密秘钥。当Quanta公司拒绝付款后，REvil开始在暗网公布被盗的蓝图。

SCA软件成分检测

软件成分分析 Software Compostition Analysis（SCA） 是一种用于管理开源组件应用安全的方法。通过 SCA，开发团队可以快速跟踪和分析引入项目的开源组件。同时，SCA 工具可以发现所有相关组件、支持库以及它们之间直接和间接依赖关系。SCA 工具还可以检测软件许可证、已弃用的依赖项以及漏洞和潜在威胁。扫描过程会生成物料清单 Bill of Materials（BOM），从而提供项目软件资产的完整清单。

针对sca工具的选用：

1.代码安全性，代码作为企业重要的数字资产，在对于sca检测的时候，需要做到不上传代码检测sca或者可本地部署，才可以保证代码的安全性。

2.评估sca工具的漏洞库是否齐全或采用多个sca工具进行查缺补漏

3.直接依赖必要，间接依赖检测也是必要的

4.优选需要可构建组件代码，可检测组件代码漏洞、非公开组件漏洞

5.接入简单（可将sca集成到CI/CD流水线中）、自动扫描、定期扫描

6.漏洞信息丰富，修复建议完善，报告可导出

7.优选可与禅道等需求管理平台对接的工具

因为资金有限，我优选还是开源的，已经尝试使用opensca，能用就挺好

https://github.com/XmirrorSecurity/OpenSCA-cli

供应链安全实践

事前：供应链相关资产收集

1.软件/系统/组件资产盘点，包括系统名称、系统网站、开发人员（自有、三方、供应商）、代码仓库、负责人，软件成分（sca软件成分分析）

2.开发流程调查：开发测试交付流程、代码访问权限、开源软件更新与安装

3.权限最小化：内部系统遵循权限最小化原则，按需使用，权限应该经过审批后发放，重要系统保留访问日志

4.供应商安全可靠性评估：针对第三方、合作伙伴、商软提供商，评估安全资质如三级等保及相关安全证明，检索供应商历史出现的安全漏洞及事件进行综合评估，针对人员需签写保密合同及相关协议保留事后可追溯索赔的权力。

5.应急演练：基于实际情况进行演练编排，主要考察多方配合包括（安全事件响应、安全事件处置、可靠的灾难恢复、安全事件溯源、事件复盘及流程调优），保证安全事件出现时能及时应对避免损失。

6.漏洞知识库建立，历史漏洞进行宣传推广，增加技术人员安全意识，避免修改漏洞沟通成本

7.建立开源软件选用机制，提前对开发侧要接入的开源软件进行安全检测，及提前制定商采软件的安全风险责任划分

事中：组件、代码过程中准入机制

1.开源组件接入前扫描软件成分（SCA）、代码安全检测（SAST）

2.代码上线前扫描软件成分、代码安全检测

3.制定组件安全红线，红线内组件及漏洞需要上线前修复完成

4.持续跟进未升级组件、未修复漏洞

5.供应商、三方代码接入前检测，检测后评级漏洞进行修复，无法修复漏洞，需要重新评定是否采用

事后：存量治理/流程闭环

对事前盘点的系统进行至少每季度一次的组件安全进行盘点，避免出现遗漏安全问题，针对中/低危组件漏洞跟开发约定排期进行升级/修复，对升级修复的组件进行Poc验证，验证通过后关闭漏洞

组件安全事件应急响应

误报？！需要安全人员自身具备漏洞敏感性，判断漏洞情报的准确性及漏洞利用难度，结合自身的实际情况开镜像漏洞处理活动。

多方面构建漏洞情报，针对新发现的组件漏洞及时跟进

1.更新拦截规则 及时封堵攻击

2.保留攻击日志 进行攻击溯源

3.官方提供修复补丁及修复方案及时进行修复

最后

基于每个企业不同的情况，因地制宜才是检测及处理最好的方式，以上仅供参考。