张文凯-研发体系下开源安全风险发现与治理

研发体系下开源安全风险发现与治理 张文凯腾讯安全 张文凯 腾讯安全开发安全产品负责人 ⚫腾讯科恩实验室开发安全产品负责人。有多年基于黑白盒代码安全测试与研究经验，目前着力于开发安全产品研发与核心能力研究，聚焦于以大数据驱动下的安全算法研究与安全产品工程化落地，专注解决来源于开源组件的软件供应链安全问题。 目录 来自软件供应链的安全挑战1软件供应链安全与软件成分分析2软件成分分析工具引入思路3 01 来自软件供应链安全的挑战 软件供应链安全能力建设的趋势、必要性和监管要求 软件供应链安全指软件供应链上软件设计与开发的各个阶段中来自本身的编码过程、工具、设备或供应链上游的代码、模块和服务的安全，以及软件交付渠道和使用安全的总和。——《软件供应链安全发展洞察报告》，云计算开源产业联盟 有没有从根本上解决安全潜在风险？ 软件供应链安全趋势 行业监管与政策 建设必要性及价值 •国家级攻防演练2022-2023防守单位失陷案例60%+与软件供应链安全相关；•国家级攻防演练Top5攻击技战法；•两年持续供应链安全专项持续加大力度，是国家关注的重点； •建立体系规范，以标准、合规、安全的组件提供给各个业务方；•安全左移，更早的发现和修复安全漏洞；•准入管理，从源头把控安全，从源头摸清楚供需、安全和管理现状； 《关键信息基础设施安全保护条例》《关于供应链安全风险提示》《关于规范金融业开源技术应用与发展的意见》《银行保险机构信息科技外包风险监督办法》《金融业开源软件应用管理指南》 软件供应链安全如何定义？ •供应商提供的制品成分未知，解不开包、不知道其中有什么成分•开发的代码中软件成分未知，有意无意的引入未知组件•…… •开源组件漏洞风险未知•开源组件投毒风险未知•开源组件许可证风险未知•如何发现开发中的敏感信息•…… 信创替换的软件是否是安全的是否能对供应商软件进行检测是否做到全天候监测企业资产威胁情报信息…… 软件供应链安全：开源组件风险案例 开源组件漏洞风险案例： “太阳风暴”攻击 Spring框架漏洞 2020年12月，美国企业和政府网络突遭“太阳风暴”攻击。黑客 利用太阳 风公司（SolarWinds）的网 管软 件漏洞，攻陷 了多 个美国 联邦机 构及 财富500强企业网络。2020年12月13日，美国政府 确认 国务院、五角 大楼、国土 安全 部、商务部、财政 部、国家 核安 全委员 会等多 个政 府部门遭 入 侵。该 事 件 波 及 全 球 多 个 国 家 和 地 区 的18000多个用 户，被认为 是“史上最 严重”的供应链攻击。 2022年3月30日，国家信息安全漏洞共享平台（CNVD）收录Spring框架 远程命 令执 行漏洞（CNVD-2022-23942）。攻击 者利 用该 漏洞，可在 未授权 的情况下 远程执 行命令，该漏 洞被称为“核弹级”漏洞。使用JDK9及以上版 本皆有可能受到影响。 Apache Log4j2漏洞 XZ后门事件 2021年12月，开源 组件Log4j被发 现两个 相关漏洞，分别 为任 意代码 执行漏 洞和 拒绝服 务攻 击漏洞，攻击 者可 以通过 构造特 殊的 请求进 行任 意代码执 行，以达 到控 制服务 器、影响 服务 器执行 的目的。该漏洞已影 响超6万个开源软 件，涉及相关版本软件包32万余个,被认为是“2021年最重要的安全威胁之一” 2024年3月29日，软件开 发者Andres Freund报告 称，liblzma库 在2024年2月 发 布 的5.6.0和5.6.1版本 中，包含 的Linux实用 程序xz含有 一个恶意 引入的 后门。虽然 大多数Linux发行 版都安装 有xz，但 后 门 仅 针 对 基 于Debian和RPM的x86-64架构系 统。在发现 时，后门版 本尚未被广泛部署。 开源组件许可证风险案例： 2021年4月30日，罗盒公司状告风灵公司侵权获赔50万元，同时要求风灵公司停止侵权行为。在该案件中原告罗盒公司，独立开发“罗盒(Virtual App)插件化框架虚拟引擎系统V1.0”（简称VirtualApp V1.0），在2016年引入GPL3.0许可证，于2017年取得计算机软件著作权登记证书，且声明用于商业用途请购买商业授权。2018年原告发现名为“点心桌面”的软件使用了VirtualApp V1.0的代码，经过源码分析对比，发现两者之间高度相似，遂起诉被告福建风灵公司。经法院审判被告赔偿原告为制止侵权行为而支出的合理费用50万元。此次判决是中国首个明确GPL3.0许可证具有法律效力的案例。 ••2021年12月，抖音海外版TikTok上线了一款名为TikTok Live Studio的APP，但不久其下载页面就被删除。TikTok官方对此事做出回应，原因是该APP违反GPL许可证，其使用GPL许可证下的开源软件源码，却没有按照GPL许可证要求开源。 《软件成分分析系统安全技术要求与测试评价方法》 开源组件挑战 自主可控要求 企业在开源组件治理上存在的痛点 01缺乏SCA能力体系建设 02缺乏开源风险预警能力 03缺乏制品准入能力建设 •缺乏对第三方制品风险发现能力•缺乏制品入库前的风险监测•信创替换软件是否真的安全•组件黑白名单/质量红线建立 •源码SCA能力建设•制品SCA能力建设•DevOps上缺乏安全左移能力•DevOps安全能力建设尚在规划 •核弹级开源组件漏洞风险预警•日常扫描中的开源风险发现•缺乏对风险处置给出专业意见•缺乏实时的开源组件知识库 03难在SBOM台账风险运营 01难在SCA能力未全覆盖 02难在组件/漏洞修复复杂 •源码SCA能力接入•制品SCA能力接入•分析能力受限，漏报多•无法满足对特定扫描项的需求 •组件升级不知哪个版本更好•漏洞修复缺少详细的推荐方案•漏洞修复的优先级怎么制定•缺少业内成熟实践过的修复经验 •如何建立企业级的SBOM•如何基于SBOM进行台账运营•新发现风险如何快速定位•SBOM数据的长期运营和维护 企业在开源组件治理上存在能力建设缺乏、检测覆盖度不足、风险修复困难以及SBOM难运营等痛点。 02 软件供应链安全与软件成分分析 研发角度看软件供应链安全问题 •开源组件问题突出：SCA工具的引入是首要优先级 软件成分分析核心挑战 组件检出能力覆盖 组件检出准确度保证组件版本检出准确度保证组件识别能力组合： •制品扫描–包管理器识别•制品扫描–二进制SCA•静态包管理器识别•动态包管理器识别•代码片段级识别 漏洞知识库修正（NVD等数据源数据错误）多数据源数据汇聚（NVD、CNVD、GHSA等）开源组件许可证监控（真实代码仓库监控） 03 软件成分分析工具引入思路 软件成分分析工具在软件供应链准入场景下应用 •基于实战经验的分析平台：包归档、元信息提取•充分发挥二进制SCA：解包能力强、二进制分析对象兼容性高•系统采集能力：完整采集运行时数据，综合SCA分析 供应商制品包 包解析与归档 自动化检测分析 人工验证分析 供应链包准入 •制品包验证机制•服务器系统级采集机制 •可信SCA成分分析•恶意样本特征检测 •复杂包格式解析•数据归档，常态化回扫 •业务包拆分 软件成分分析工具在开源组件治理场景下的流程 THANKS！