InfoQ近期组织的全球软件供应链发展报告解读直播,通过新鲜的案例和纯粹的技术讨论,展现了软件供应链安全领域的转变。
从被动防御到主动管理,从单点工具到全面平台,从简单扫描到深度分析，安全行业正在向更加主动、全面和适应性强的方向脚踏实地发展,同时也面临着新技术带来的诸多挑战。
金句摘抄
1. 持续的安全建模与评估
"安全永远在建模！"这句话突出了安全管理是一个持续过程。企业需要不断评估和调整安全策略。
2. 从被动扫描到主动制品管理
"你不拥有它，你就没法保证它的安全",说明从传统的被动扫描向主动制品管理转变的重要性。企业正在建立内部公共仓库，以更好地管理软件供应链安全。
3. 先进厂商的技术架构与产品设计值得借鉴
"目前市面上没有一款工具能解决所有问题，每个工具都有其特定的功能和局限性。"
"高级扫描套件，支持源代码扫描，基于上下文分析, 左移到IDE，形成从开源包组件隔离到安全可信发布的完整平台...…我们的用户非常的喜欢。"
市场正在从单一的安全扫描工具向全方位的软件供应链安全平台发展
“数据显示开源语言包呈现快速增长趋势，特别是docker hub、npm和golang”。这不仅反映了开发者的技术偏好、不同语言和平台的发展步伐。
*我是制品库、安全工具的深度用户，也常线下请教老师，回看整理笔记后，继续践行知识搬运工角色，分享学习笔记，大家共同学习、讨论和进步。以下内容根据会议笔记整理，错误疏漏难免，请以InfoQ直播回放内容为准，部分口头内容由LLM总结要点，有2个部分标注为LLM增补。
目录
- 1. 软件供应链安全管理策略与最佳实践
- "安全永远在建模！"
- 中美政策
- 未来发展趋势
- 漏洞风险评估与管理
- 2024全球软件供应链发展报告
- 2. 软件供应链安全技术创新与应用
- 技术：二进制和镜像扫描
- 技术：隔离仓库管理第三方依赖
- 技术：高级扫描套件：精准识别可利用漏洞
- 技术：构建软件依赖关系树
- 技术：从传统被动扫描到制品主动管理
- 3. 软件供应链安全厂商的发展策略与市场趋势
- 核心观点：安全扫描工具不是软件供应链工具
- 从制品库到全方位软件供应链安全平台
- 从包管理起家到软件供应链安全的领军者
- 并购安全公司的核心逻辑
- 4. 软件供应链安全威胁与典型案例分析
- 案例：核弹级Apache log4j漏洞
- 数据：DockerHub恶意镜像比例30%
- 案例：利用搜索引擎欺骗用户下载恶意Docker
- 案例：电子书钓鱼陷阱Docker
- 案例：开源代码仓库中的敏感信息泄露问题
- 案例：AI模型Hugging Face暗藏攻击
- 数据：安全漏洞修复需要投入25%的事件
- 数据：开源语言包增长趋势
1. 软件供应链安全管理策略与最佳实践
"安全永远在建模！"
"软件供应链安全是一个持续的过程"
- 安全永远处于建模过程中，需要持续评估和调整
- 安全投入需要根据资产价值、潜在损失等因素进行建模评估
- 在开发早期解决安全问题可让团队更专注创新
- 平衡安全投入与业务发展，根据企业特点制定策略
突出了安全管理中持续的建模过程，从数据收集、模型构建、模型验证、模型应用再到模型更新，形成一个不断循环的过程。它强调了安全不是一个静态的概念，而是需要通过持续的建模来适应不断变化的安全环境和威胁格局。
中美政策
- 美国NIST制定通信产业供应链安全标准，推动SBOM概念
- 中国信通院推动软件供应链安全能力评估模型，央行对金融企业开源技术应用提出指导意见
未来发展趋势
"企业需综合考虑漏洞、开发者安全意识不足、license和运维风险，通过平台工具赋能团队。"
- 供应链攻击特点：低成本、高收益、影响广泛
- 国际安全标准（如SLSA）可能引入国内,用于评估企业软件供应链管理水平
- 持续关注并适应日益严格的软件供应链安全要求
漏洞风险评估与管理
"74%的docker hub镜像漏洞实际上是不可被利用的漏洞。"
- 漏洞利用需要特定条件，并非所有漏洞都会被成功攻击
- 评估方法：专业工具扫描、分析CVE描述、结合实际使用情况判断
- 风险测试手段：组件扫描、软件成分分析、源代码扫描等
- 防御策略：了解攻击原理、有选择性地修复漏洞、使用专门工具检查
2024全球软件供应链发展报告
https://www.jfrogchina.com/software-supply-chain-state-of-union/
2. 软件供应链安全技术创新与应用
技术：二进制和镜像扫描
"目前市面上没有一款工具能解决所有问题，每个工具都有其特定的功能和局限性。"
扫描就是撞库！
1. 扫描对象：主要针对二进制文件,如Docker镜像等。
2. 扫描过程:
- 逐层解压镜像文件,生成文件树结构
- 识别特定文件类型(如.jar、.war、.tar包等)
- 对识别的文件进行扫描
3. 扫描原理:
- 使用"撞库"方法,将文件的校验和(checksum)与已知漏洞库进行匹配
- 如果匹配成功,则标记存在相应漏洞
4. 性能特点:
- 扫描速度快,主要消耗CPU资源
- 相比源码扫描,二进制扫描更快
5. 上下文分析:
- 在单独的容器中进行
- 包括反编译、分析类路径等步骤
- 耗时相对较长
6. 效率:对于100MB左右的Docker镜像,可在1分钟内完成扫描
总的来说,这项技术通过快速的二进制扫描和匹配来检测软件中的已知漏洞,同时结合上下文分析提供更深入的安全评估。虽然不能解决所有问题,但在软件安全检测方面提供了高效的解决方案
技术：隔离仓库管理第三方依赖
1. 创建了一个大型云数据库（Catalog），记录了互联网上所有开源软件的版本和漏洞信息。
2. 研发人员可以在不下载包的情况下，通过查询Catalog来了解特定版本是否存在漏洞。
3. 在外网和内网之间，提供了一个隔离区curation，可以阻止恶意包进入公司内网。
4. 允许用户通过配置策略来限制，如特定版本的软件包或Docker镜像的使用，如阻止下载旧版本的操作系统（例如Ubuntu 20.04以下版本或CentOS 7）。
5. 这种方法可以阻挡禁用的CVE包和许可证引入产品。
6. 这些功能有助于企业降低运维风险，并可能带来显著的研发成本收益。
技术：高级扫描套件：精准识别可利用漏洞
1. “当前漏洞扫描工具存在大量误报，导致开发人员对漏洞警告麻木和无助”
2. "高级扫描套件，支持源代码扫描，基于上下文分析，确认漏洞是否可被利用，支持秘钥泄露检查，精准弹窗高级。"
3. "我们把安全扫描移到最左侧，就是在IDE的工具里面进行扫描，这个功能我们的用户非常的喜欢。"
4. "Docker Hub社区里面，100个最常见的CVE漏洞里面，有74%的漏洞实际上是不可被利用的。"
5. "对一个2,800人的团队来说，每年能节省80万美金。"
技术：构建软件依赖关系树
“实际上我们最终做的事情一定是要从解决某个问题开始！" （问题组件溯源、影响分析、召回），那怎么做这个溯源你又不想所有的用户都去通知一遍，对吧？，构建依赖关系树，让安全漏洞无处遁形，实现从组件到用户的全链条追溯。"
1. 企业需要从实际需求和痛点出发，解决软件供应链安全问题。
2. 以手机和汽车为例，镜像文件中的APK或ECU软件可能存在安全漏洞，需要有效管理。
3. 构建镜像（手机镜像、非docker）依赖关系树，可以帮助企业追踪和管理软件供应链中的安全问题。
4. 依赖关系树能够在漏洞爆发时快速定位受影响的用户，实现精准溯源和通知。
5. 投入建立软件供应链追踪系统是值得的，能够帮助企业更好地应对未来可能出现的安全漏洞。
6. 平衡软件供应链安全和创新需要企业建立有效的管理机制，既保证安全性，又不影响创新进程。
{llm增补}构建依赖关系树的基本方法
1. 识别组件：
- 对于手机，识别镜像文件中包含的所有APK。
- 对于汽车，识别所有的ECU（电子控制单元）和相关软件。
2. 建立关系：
- 分析每个APK或软件组件之间的依赖关系。
- 确定哪些组件依赖于其他组件，形成一个层级结构。
3. 记录版本信息：
- 为每个组件记录详细的版本信息，以便追踪特定版本的问题。
4. 链接到最终产品：
- 将依赖关系树与最终产品（如特定型号的手机或汽车）关联起来。
5. 实现追溯机制：
- 建立一个系统，能够从任何一个组件快速追溯到受影响的最终产品。
6. 持续更新：
- 随着软件更新或新版本发布，不断更新依赖关系树。
7. 集成安全检测：
- 在依赖关系树中集成安全漏洞检测机制，以便及时发现和标记问题组件。
8. 建立通知系统：
- 基于依赖关系树，建立一个能够精确定位受影响用户的通知系统。
9. 版本控制：
- 实现版本控制机制，确保问题组件不会在未经修复的情况下流转到下一个阶段。
10. 数据分析：
- 利用依赖关系树的数据进行分析，帮助优化软件供应链管理。
构建这样的依赖关系树需要专业的工具和系统支持，可能涉及到复杂的软件工程实践。企业可能需要开发专门的工具或使用现有的供应链管理解决方案来实现这一目标。
技术：从传统被动扫描到制品主动管理
1. "你不拥有它，你就没法保证它的安全" 【数据要素】
2. "你给我什么东西我就扫，那反过来说你没有给我的东西我就不扫" 【传统限制】
核心观点概述：
1. 传统安全工具的局限性在于不管理制品，可能忽视隐藏风险。
2. 建议从存量制品管理开始建立安全基线，首先控制源头。
3. 建立公共仓库，设置准入门槛：
- 存量包可直接放入
- 新增包需要审批和扫描
4. 实施自动扫描门禁和人工审批机制：
- 通过扫描的包可自动进入
- 未通过扫描但需要使用的包需人工申请和安全评估
5. 建立基准仓库的准入机制后，可更好地管理版本溯源和漏洞更新。
6. 这种方法类似徽派建筑的码头墙，通过分层过滤和基线建设，将风险控制在小范围内，减少对整体业务运转的影响。
3. 软件供应链安全厂商的发展策略与市场趋势
"好的的解决方案实际上不仅是制品库，而是一个从开源包组件隔离到安全可信发布的完整平台。"
安全扫描工具不是软件供应链工具
从制品库到全方位软件供应链安全平台
1. 软件供应链管理的基础是制品库和远程仓库控制，用于统一管理所有依赖库。【google还包括源码库】
2. 目前市场上很少有定位为软件供应链平台的公司。
3. 传统安全扫描工具（如qqiiaaxx、Black Duck等）不具备软件版本管理能力，因此无法实现完整的软件供应链管理。
4. 要实现软件供应链管理，首先需要具备软件管理能力，而制品库是这一能力的基础。
5. 统一管理软件供应链的能力，这是其区别于其他安全厂商的关键特点。
从包管理起家到软件供应链安全的领军者
杰蛙案例分析：
1. 制品库的核心技术优势在于二进制包管理，特别是供应链的包管理。
2. 制品库起家，通过收购一家专门从事安全分析的公司，扩展了其在软件供应链安全方面的能力。
3. 明确定位于软件供应链安全和制品管理领域，这是其在市场上的专业方向。
4. 虽然公司也提供安全扫描服务，但这并非其核心竞争力，市场上已有许多成熟的扫描工具。
5. 发展路径是从包管理起家，逐步扩展到全面的软件供应链安全服务。
并购安全公司的核心逻辑
{llm增补}
1. 整合开发和安全:将安全技术整合到制品库平台,为开发和安全团队提供统一的解决方案。
2. 实现"液体软件"愿景:确保软件能够无缝且安全地从任何来源流向任何设备。
3. 全面的安全分析:提供上下文扫描、智能修复、嵌入式软件安全等能力。
4. 减少"噪音":通过智能推荐,帮助团队专注于最重要的安全问题,减少误报。
5. 扩展到设备安全:增强在嵌入式软件和设备安全方面的能力。
6. 零日漏洞检测:自动检测新的漏洞、恶意软件、后门等威胁。
4. 软件供应链安全威胁与典型案例分析
案例：核弹级Apache log4j漏洞
2021年的Log4j漏洞确实对软件供应链安全产生了深远的影响。这个漏洞的重要性和持续影响主要体现在以下几个方面:
1. 广泛性：Log4j是一个被广泛使用的Java日志库，几乎存在于所有Java应用中。这意味着漏洞的影响范围极其广泛。
2. 严重性：该漏洞允许远程代码执行，被评为最高危险级别(CVSS 10.0)。攻击者可以轻易地利用它来接管系统。
3. 供应链复杂性：由于Log4j深度嵌入在许多软件和系统中，修复过程变得异常复杂。许多组织甚至不知道他们的系统中哪里使用了Log4j。
4. 安全意识提升：这个事件大大提高了人们对软件供应链安全的认识，促使更多组织开始关注和管理其软件依赖。
5. 政策影响：各国政府和监管机构开始更加重视软件供应链安全，出台了相关政策和指南。
至于为什么三年后这个问题仍未完全解决，主要有以下原因：
1. 遗留系统：许多老旧系统难以更新或者更新成本很高。
2. 依赖关系复杂：某些系统可能依赖于使用旧版Log4j的其他组件。
3. 认知gap：一些组织可能仍然没有意识到他们的系统中存在这个问题。
4. 资源限制：完全修复需要大量的时间和资源投入。
5. 新的挑战：随着时间推移，新的漏洞和威胁不断出现，分散了注意力和资源。
这个事件凸显了软件供应链安全的重要性和复杂性，也表明我们在这方面还有很长的路要走。要解决这类问题，需要技术、政策和组织文化等多方面的持续努力。
数据：DockerHub恶意镜像比例30%
1. Docker Hub中存在大量恶意镜像：在约1000-1500万个Docker镜像中，发现了约300万个恶意镜像。
2. Jfrog与Docker Hub合作：Docker Hub开放了镜像库遍历接口，允许Jfrog进行全面扫描。
3. Jfrog的扫描能力优势：Jfrog的扫描工具能力优于Docker Hub自身的工具。
4. 安全问题的处理：在公开报告之前，Docker公司已经清除了这300万个恶意镜像。
5. 用户认知与实际情况的差异：传统观念认为Docker Hub主要存储官方仓库，但实际情况显示存在大量潜在安全风险。
6. 合作共赢：这次合作既帮助Docker Hub提高了安全性，也让Jfrog获得了宝贵的研究数据。
这个发现颠覆了开发者对Docker Hub的传统认知，突显了容器镜像安全的重要性，以及行业合作在提高整体安全性方面的价值。
案例：利用搜索引擎欺骗用户下载恶意Docker
1. 攻击者利用谷歌搜索引擎的SEO机制,将恶意Docker镜像排在搜索结果前列。
2. 用户在搜索Android APK模拟器时,可能误点击看似合法的Docker Hub链接。
3. 实际下载的是伪装成正常应用的恶意软件包。
4. 这种攻击方式难以被普通开发者察觉,容易造成无意识的安全漏洞。
abaflaper/truck-simulator-apk-para攻击原理解释：
1. 攻击者创建一个恶意Docker镜像,并使用包含常见搜索词的名称(如"simulator APK")。
2. 将该镜像上传到Docker Hub,使其能被搜索引擎收录。
3. 利用SEO技术提高该Docker Hub页面在相关搜索结果中的排名。
4. 当用户搜索Android APK模拟器时,这个恶意镜像的链接可能出现在搜索结果的靠前位置。
5. 用户误以为这是合法的APK下载链接,点击后实际下载的是伪装的恶意软件包。
6. 恶意软件包被下载到用户本地设备后,可能对系统造成安全威胁。
这种攻击利用了用户对搜索结果的信任,以及对Docker Hub等平台认知的不足,从而实现了恶意软件的分发。
案例：电子书钓鱼陷阱Docker
naiflicengroup1985/read-download-pdf-citadel-of：
1. 诈骗者利用 DockerHub 平台创建伪装成电子书的项目，实际上并不包含真正的 Docker 镜像。
2. 这些项目通过 SEO 优化在搜索结果中出现，诱导用户点击链接。
3. 点击后会弹出信用卡付费窗口，诱导用户付款，但实际上不会提供任何电子书内容。
4. 这种手法是互联网钓鱼诈骗的新变种，利用了人们对电子书下载的需求。
5. 文章提醒读者警惕这类新型诈骗手法，避免落入陷阱。
6. 作者对诈骗者的"创新"表示无奈，同时指出这些问题项目已被修复。
案例：开源代码仓库中的敏感信息泄露问题
1. 开源软件平台如GitHub、GitLab和DocHub等存在安全隐患。
2. 最常见的泄露信息是AWS访问token，可能由于开发者在上传代码时未删除包含敏感信息的脚本造成。
3. 其他常见泄露的敏感信息包括Telegram、GitHub和OpenAI的token。
4. 这种无意识的代码泄露成为许多企业面临的重要安全挑战。
5. 开发者需要提高安全意识，在上传代码时注意检查和清理敏感信息。
案例：AI模型Hugging Face暗藏攻击
"所有的问题能够在修复以及包括的成本最低的还是在开发阶段，而不是在最终的这个运行阶段。"
1. AI和机器学习在安全领域应用广泛，但也带来新的安全隐患。
2. 大语言模型的部署和使用可能存在多方面风险：
- 第三方执行工具可能存在CVE问题
- 模型参数可能被篡改
- Docker镜像形式的部署增加了不确定性
3. AI模型本身可能存在安全风险，如恶意代码可能被嵌入模型中。
4. Hugging Face案例警示：
- 在Hugging Face上发现名为"GPT-2-light"的恶意模型镜像
- 该模型被下载并在本地执行时，会调用计算器，潜在地攻破本地机器
- 证明恶意代码可以被嵌入到模型中，造成安全威胁
5. 从官方仓库下载的包并不一定都是安全可用的，需要提高安全防范意识。
6. 在生产环境中部署AI模型需要格外谨慎，因为涉及计算资源和私有数据。
7. 建议在开发阶段就做好安全防范，这比在运行阶段修复问题的成本更低。
8. 需要开发相应工具来及早发现和防范AI应用中的安全问题。
数据：安全漏洞修复需要投入25%的事件
1. 企业安全工具使用情况：30%的企业使用10种以上的安全审核工具，数量之多令人惊讶。
2. 漏洞修复时间投入：25%的团队研发时间用于修复漏洞，60%的团队每月花费4天（约20%工作时间）处理应用程序漏洞。
3. 国内外企业对比：
- 国外企业对安全修复的重视程度高于国内企业。
- 国外企业多使用持续提供安全修复的企业版操作系统。
- 国内部分企业仍在使用老旧版本系统（如CentOS 7）。
4. 国内行业差异：金融、制造业、智能制造和高科技企业对安全修复较为重视，其他行业相对不那么紧迫。
5. 漏洞修复的复杂性：涉及版本替换、重新打包、测试、上线，以及影响范围定位等多个环节，特别是生产环境中的漏洞修复难度更大。
6. 未来方向：研究如何防止高危漏洞版本进入生产环境，这是供应链管理需要解决的核心问题。
数据：开源语言包增长趋势
1. 软件供应链安全意识提升：
- 89%的团队使用SLSA框架评估软件供应链成熟度
- 92%的团队检测恶意开源软件
- 42%的开发者在引入开源软件时进行扫描
2. 开源社区语言包增长趋势：
- Docker Hub和npm（Node.js）在2023年异常活跃
- Golang的增量包数量超过Maven，显示出较高的活跃度
- 趋势表明开发者越来越倾向于使用Go和Python，而非Java（Maven）
3. 技术栈选择建议：
- 基于语言包增长趋势，建议在选择技术栈时考虑Go和Python等活跃度高的语言
