首页 >>软件供应链安全风险
软件供应链安全风险
发布来源: 代码审计SDL 发布时间:2021-08-26

软件供应链安全风险介绍

软件供应链本身就是软件的生产过程,始终贯穿于软件研发生命周期(SDL)当中。在软件系统研发过程当中,时刻面临着有意或者无意引入漏洞的威胁。

阶段案例
需求设计手机被劫持:2016年,一家境外公司设计的软件被美国的手机制造商使用。该软件会每隔72小时,手机将会把文本,通讯录,通话记录通过加密的方式上传到境外的服务器上
编码SolarWinds:2020年12月13日,美国网络安全公司FireEye发布分析报告称,SolarWinds 旗下的Orion基础设施管理平台的发布环境遭到黑客组织入侵,黑客对文件SolarWinds.Orion.Core.BusinessLayer.dll的源码进行篡改添加了后门代码,该文件具有合法数字签名会伴随软件更新下发。后门代码伪装成Orion OIP协议的流量进行通信,将其恶意行为融合到SolarWinds合法行为中。FireEye称已在全球多个地区检测到攻击活动,包括北美、欧洲、亚洲和中东的一些政府、咨询、技术公司。
软件分发终端用户设备感染恶意软件:2012年——美国一家大型软件公司的研究人员调查盗版软件时发现恶意软件预装在他们几乎的20%的设备上。从工厂到分销商、运输商或经销商过程中新的台式机和笔记本电脑在发货后被安装了恶意软件。
收购及部署卡巴斯基杀毒软件:多年以来,美国多次指称俄罗斯黑客入侵美国系统、甚至干扰美国总统大选,情报部门也一直在调查卡巴斯基实验室与俄罗斯政府可能存在的联系。2017年9月13日,美国国土安全部下令所有联邦机构禁止使用卡巴斯基实验室生产的软件,原因是“俄罗斯政府方面可能进入该系统”。2017年12月,2018年度国防授权法案(NDAA)中新增禁令,禁止所有联邦部门使用卡巴斯基公司制作、参与或者主导的类似产品、服务。受舆论压力,卡巴斯基也于早前的12月7日关闭向政府部门销售产品的华盛顿办公室,不过产品继续向美国非联邦客户销售。
运营在日常维护更新中安插后门:2020年,攻击者通过例行更新插入后门,导致成千上万的公共和私有网络被渗透。
销毁敏感数据泄露:2019年一名研究人员购买了旧电脑,闪存,手机,硬盘等,在85个设备中只发现了两个正确擦除数据,同时还发现数百个个人身份信息,包括社会安全号码,护照号码,信用卡号等。
  • 以上数据翻译自:https://www.cisa.gov/sites/default/files/publications/defending_against_software_supply_chain_attacks_508_1.pdf

供应链安全风险防护

无论是软件供应链防护体系,还是安全开发体系,又或者是DevSecOps开发体系,目前主流思想是通过工具链+体系咨询的方式进行落地,通过体系建设,勾勒整体开发流程,使用工具,减少人工参与成本,提高安全性,加速体系落地和推广。

构建安全开发体系

在安全开发过程中,主要目的是为了从安全漏洞产生的根源上解决应用安全问题,通过对软件开发流程的控制,保证产品的安全性。

图片

SDL security development lifecycle(安全开发生命周期),是微软提出的从安全角度指导软件开发过程的管理模式。SDL是一个安全保证的过程,侧重点是软件开发,它在开发的所有阶段都引入了安全和隐私的原则。SDL流程是一组必须的安全活动,按照传统的软件开发申明周期进行分组,可以分为7个阶段,17个分组。

图片

由于企业的开发人员的技术参差不齐,部分相关开发者心中没有安全的相关概念、项目的上线及迭代更新没有相应的规范等等,这些问题都将会是导致出现安全问题的根本原因,而安全开发规范流程正是从根本原因解决这些问题。安全开发对软件开发过程中所有参与该项目的相关角色,都将引入相关的安全概念,形成一个闭环,从而解决出现安全的根本问题。对于拥有庞大的开发团队的组织,由于大量的开发人员以及产品的频繁迭代,推动安全开发规范流程是目前最好的减少相关应用产品的安全问题的解决方案。

完善安全开发工具链

构建合适的安全开发体系需要使用工具进行支撑,整体的流程可以使用安全开发管控平台来管理,每个阶段又会执行多个安全活动,调用多个工具来检测防护。以下国内外常见的安全工具链。

Gartner安全开发工具链

图片

悬镜安全开发工具链

图片某证券DevSecOps落地实践

图片

默安DevSecOps工具链

图片

安全开发管控平台

以企业应用开发全生命周期为基础,以安全基线、安全开发指引、信息资产管理、开源组件漏洞扫描、源代码扫描、安全运维管理等为核心,构建知识库、集成安全工具的安全开发管控平台。实现安全开发自动化,知识化,安全管理统一化、安全运营标准化。平台包含了各阶段流程的梳理、评审机制的建立、相关资源库的建设,通过数据接口收集各阶段安全数据、开发数据及漏洞样本,打造覆盖应用开发安全建设和使用全生命周期的一体化安全管控平台。以下是常见的安全开发管控平台架构图:

某金融机构安全开发运营管理平台

图片

开源网安SDL流程图

图片

软件成分分析SCA

软件物料清单实际上就是构成软件程序或应用程序的成分列表。软件物料清单实际上就是构成软件程序或应用程序的成分列表。与汽车行业一样,这些组件可能来自成千上万家供应商——没错,现代软件其实就是由开源及商业解决方案,再加上少量代码与子程序所拼接而成的。这种软件代码复用机制,使得开发人员不必从零开始重新创建所有内容,从而显著节约时间并提高应用程序开发效率。在软件行业,SBOM(Software Bill of Material,软件物料清单)会记录代码库中所有开放源代码和第三方组件的列表,可以列出并管理这些组件的许可证,代码库中使用的组件的版本及其补丁程序状态。

字段SPDX值SWID值
供应商(3.5) PackageSupplier:<Entity> @role (softwareCreator/publisher),@name
组件(3.1)PackageName:<softwareIdentity> @name
唯一标识(3.2)SPDXID:<softwareIdentity> @tagID
版本(3.3)PackageVersion:<softwareIdentity> @version
组件散列值(3.10)PackageChecksum:<Payload>/../<File>@[hash-algorithm]:hash
相互关系(7.1)Relationship:CONTAINS<Link>@rel,@href
SBOM编辑人(2.8)Creator:<Entity> @role (tagCreator),@name

下图为软件物料清单中组件关系的基本关系,左侧表格为需要跟踪的信息,右侧图形则展示了各软件组件间的关系。

图片

软件成分分析系统允许企业更早识别并缓解系统或许可源代码内的潜在缺陷,因此有效控制风险。此外,软件成分分析系统还将帮助开发人员更好地审查嵌入至当前项目中的成品代码,推动软件开发安全实践的普及。而在软件使用者方面,更高的透明度则能够有力支持采购决策,轻松了解开发方是否严格遵循软件许可要求。软件成分分析系统的最大意义,很可能体现在网络安全保障与风险控制层面。

目前开源SCA可以尝试owasp社区提供的dependency check 和dependency track,国内主要安全厂商均有自己的SCA安全产品,有能力的小伙伴可以自行尝试。

源代码审计工具

目前源代码审计主流AST(Abstract Syntax Tree(抽象语法树))工具分为:SAST,DAST,IAST。

DAST:动态应用程序安全测试(Dynamic Application Security Testing)技术在测试或运行阶段分析应用程序的动态运行状态。它模拟黑客行为对应用程序进行动态攻击,分析应用程序的反应,从而确定该Web应用是否易受攻击。

SAST:静态应用程序安全测试(Static Application Security Testing)技术通常在编码阶段分析应用程序的源代码或二进制文件的语法、结构、过程、接口等来发现程序代码存在的安全漏洞。

IAST:交互式应用程序安全测试(Interactive Application Security Testing)是2012年Gartner公司提出的一种新的应用程序安全测试方案,通过代理、VPN或者在服务端部署Agent程序,收集、监控Web应用程序运行时函数执行、数据传输,并与扫描器端进行实时交互,高效、准确的识别安全缺陷及漏洞,同时可准确确定漏洞所在的代码文件、行数、函数及参数。IAST相当于是DAST和SAST结合的一种互相关联运行时安全检测技术。

目前SAST平台较多,常见的有sonarqube、fortify、checkmarx等等,DAST\IAST平台较少,目前只有少数几个厂商发布过类似产品,产品性能有待商榷。

安全扫描平台

web,app,主机,容器等场景下远程漏洞扫描与评估,主要安全厂商都有,开源产品也不错,这个不过多介绍。

威胁建模

威胁建模是从攻击者的角度出发,通过对软件自身内部的数据流分析来识别威胁是否存在,并对威胁进行一定程度上的评价。对于高风险的威胁,我们给出对应的消减措施以便指导开发人员。通过采用相应技术、增加相关功能软件在开发过程中即可有效的规避风险,提高应用系统开发中软件代码的安全性、降低软件维护和升级的成本。
威胁建模的优点:

  • 通过威胁建模进行安全的设计

  • 威胁建模有利于更好地理解应用程序

  • 威胁建模可以帮助查找bug

  • 通过威胁建模可以发现以其他任何方式都不太可能发现的复杂的设计bug

  • 威胁建模可以帮助新的小组成员理解应用程序的细节

  • 威胁建模应该能让基于产品的其他开发小组用到

  • 威胁建模对测试人员非常有用

常用的威胁工具有:Microsoft的Threat Modeling Tool 和 owasp的owasp-threat-dragon。

自动化安全需求分析

基于企业专家级知识库及行业最佳实践等,通过AI智能匹配、模型算法、功能场景匹配等,自动化分析业务需求,进而推导出安全需求。通过这种方式可以减少安全人员重复性工作,降低安全需求分析人员门槛。目前该方向国内主流厂商都积极发力,均有类似安全产品,截止博客发稿,博主尚未找可替代的开源产品。

应用防护RASP

随着Web应用攻击手段变得复杂,基于请求特征的防护手段,已经不能满足企业安全防护需求。在2012年的时候,Gartner引入了“Runtime application self-protection”一词,简称为RASP,属于一种新型应用安全保护技术,它将防护功能“ 注入”到应用程序中,与应用程序融为一体,使应用程序具备自我防护能力,当应用程序遭受到实际攻击伤害时,能实时检测和阻断安全攻击,而不需要进行人工干预。

图片

目前RASP产品国内有百度,默安,悬镜,腾讯等多家厂商研发,百度已将自家研发的openrasp进行开源,有兴趣的小伙伴可以尝试一下。

总结

对于供应链安全,目前主要的思路是基于软件开发生命周期进行防护,通过咨询体系建设和工具链结合的形式进行落地,目前在工具链的构建过程当中,尤其是devsecops工具链构建,由于需要跨越软件开发的多个阶段并且工具链覆盖多家平台,这样的情况造成数据无法通用的弊端,检测标准无法在工具链上做到统一,安全运营人员无法通过检测数据来回溯或者考核相关参与人员,个人感觉后续数据拉通是各家厂商需要发力的方向。

参考

  • https://www.secrss.com/articles/25216【建立软件物料清单 (SBOM) 标准的必要性分析】

  • https://paper.seebug.org/330/【Rasp 技术介绍与实现】

  • https://security.tencent.com/index.php/blog/msg/166【RASP攻防 —— RASP安全应用与局限性浅析】

  • https://en.wikipedia.org/wiki/Supply_chain_attack【Supply chain attack】

  • https://www.cisa.gov/sites/default/files/publications/defending_against_software_supply_chain_attacks_508_1.pdf【Defending Against Software Supply Chain Attacks】

  • https://www.csoonline.com/article/3191947/supply-chain-attacks-show-why-you-should-be-wary-of-third-party-providers.html【Supply chain attacks show why you should be wary of third-party providers】

注:本文系本站转载,转载目的在于传递更多信息,并不代表本站赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题,请与本站联系,我们将在第一时间删除内容!本文版权归原作者所有 内容为作者个人观点 本站只提供参考并不构成任何投资及应用建议。

关注我们

关注我们