01 摘要

可复用的软件库、框架和组件（如开源生态系统和第三方供应商提供的）加速了数字创新。但近年来，攻击者利用这些软件制品发起软件供应链攻击的数量呈指数增长，比如 **SolarWinds、log4j 和 xz utils **等知名攻击事件。

软件供应链攻击主要有三个途径：利用开源和第三方依赖组件漏洞注入恶意内容；在构建和部署过程中渗透构建基础架构；通过社会工程学等手段针对软件开发人员。若软件行业减少对开源和第三方组件的使用来降低风险，会减缓数字创新，损害软件供应链的信任。本文从研究者与从业者交流了解到的实际挑战，以及大量研究成果出发，概述了当前保障软件供应链安全的研究工作，并提出未来研究方向以应对软件供应链攻击。

02 研究背景

软件供应链的重要性与安全隐患

现代社会高度依赖数字创新，可复用软件制品加速了这一进程，但软件供应链却成为攻击目标。软件开发行业未料到其会被蓄意攻击，近年攻击事件频发，如 SolarWinds 等，造成了巨大影响。美国和欧洲也出台相关法规，强调提升开源制品透明度和完整性的紧迫性。

软件供应链的攻击向量

存在三个主要攻击途径：一是利用开源和第三方代码依赖中的漏洞或恶意注入，攻击者可借此执行任意代码、窃取数据；二是渗透构建基础架构，在软件构建和部署过程中注入恶意代码；三是通过社会工程学手段针对软件开发人员，利用人的因素发起攻击。

安全问题的影响

软件供应链信任度降低，若企业减少对开源和第三方制品的使用，会阻碍数字创新。本文旨在阐述研究方法，概述针对三大攻击向量的研究挑战和成果，提出未来研究方向以增强软件供应链安全，后续内容依次介绍研究方法、各攻击向量的挑战与研究、其他方向的研究成果，总结对软件供应链安全研究方向的看法。

03 行业和政府对挑战的投入

S3C2 通过举办年度安全软件供应链峰会、社区日活动，以及安排研究人员和学生到工业与政府机构演讲交流，收集软件供应链安全的实践问题。

挑战反馈

行业和政府从业者反馈，软件供应链安全是亟待解决的实际问题。在依赖选择上，缺乏有效指标辅助决策，政府从业者还关注国外开发的软件依赖风险。依赖更新时，漏洞数量多且工具无法提供足够信息，更新可能带来兼容性问题。恶意提交检测困难，缺乏可靠方法。在构建基础架构方面，企业寻求安全构建和部署指导，认为可重复性构建不实用。此外，软件供应链安全框架的广泛实施面临挑战，需行业共同努力，且自动化漏洞修复和构建安全文化至关重要。

04 攻击向量：代码依赖

开发者在代码依赖方面面临的实际挑战

依赖项选择困难

开发者在挑选开源和第三方代码依赖项时，难以在安全性和功能性之间找到平衡。他们缺乏全面且实用的指标，来帮助判断依赖项是否存在安全漏洞或潜在风险，也难以确定依赖项是否符合项目的功能需求。

依赖更新困难

保持依赖项更新对修复安全漏洞至关重要，开发者更新时会遇到麻烦。他们担心新版本依赖会引入与现有代码的兼容性问题，进而破坏软件的正常功能。而且，在更新过程中，开发者难以预估可能出现的新安全漏洞，这使得依赖更新的决策变得异常复杂。

恶意提交难以及时发现

开源生态系统中，代码依赖项的维护者提交恶意代码的情况时有发生，开发者却很难快速察觉。因为他们缺乏有效的监测机制和工具，无法及时识别这些恶意提交，从而使软件面临安全风险。

针对代码依赖安全的现有研究成果

依赖选择工具与指标

为辅助开发者进行依赖项选择，研究人员开发了如 OpenSSF Scorecard 等工具，通过评估开源项目的安全性指标，为开发者提供参考。但目前依赖选择指标体系仍不完善，无法全面覆盖所有与安全和功能相关的因素，难以满足开发者多样化的需求。

依赖更新策略

研究提出了基于风险的依赖更新策略，旨在综合考虑依赖项的安全风险、更新的影响范围等因素，制定更合理的更新计划。然而，这些策略在实际应用中缺乏足够的自动化支持，需要开发者手动进行大量的分析和决策，增加了操作成本和复杂性。

恶意提交检测方法

在检测开源依赖项中的恶意提交方面，研究采用机器学习技术，对代码的历史提交记录、开发者行为模式等数据进行分析建模。但该方法面临训练数据库信息不完整的问题，难以涵盖所有类型的恶意行为模式，导致检测的准确性和全面性受到限制。

代码依赖安全研究面临的挑战

依赖选择指标与数据问题

当前依赖选择指标不够全面和精准，无法充分反映依赖项的真实安全状况。同时，用于评估依赖项的数据库存在信息缺失、更新不及时等问题，难以提供完整可靠的参考依据。

理论与实践脱节

虽然在依赖管理的理论研究上取得了一定进展，但在将这些理论转化为实际可用的工具和方法时，存在较大差距。开发出的工具往往难以集成到现有的软件开发流程中，导致开发者在实际应用中面临诸多困难。

跨平台研究不足

随着软件开发环境的日益复杂，跨平台的代码依赖越来越常见。然而，目前针对跨平台依赖安全的研究相对较少，缺乏有效的方法和工具来保障不同平台间依赖项的安全性和兼容性 。

05 攻击向量：构建基础架构

从业者对构建基础架构安全的认知

• 安全担忧倾向：相较于软件部署过程，从业者更担忧构建过程中的安全问题，认为构建环境存在更多潜在风险，容易被攻击者利用来篡改软件。
• 可重复性构建的看法：尽管可重复性构建有助于确保软件在不同环境下的一致性，但从业者对其实际效用存在疑虑。他们觉得在实际操作中，实现可重复性构建面临诸多困难，并且其对保障软件安全的直接价值不明确。

构建基础架构安全的现有研究成果

• 透明度研究进展：研究致力于提高构建过程的透明度，通过记录和审计构建过程中的每一个步骤和操作，使得开发者和安全人员能够追溯和验证软件的构建历史，及时发现潜在的篡改行为。
• 完整性保障措施：为确保构建输出的完整性，研究引入了如软件物料清单（SBOM）、代码签名等技术和方法，以验证软件在构建和分发过程中未被篡改。
• 信任模型探索：构建了信任模型来评估构建基础架构中各个组件和参与者的可信度，帮助识别潜在的不可信来源，从而降低安全风险。
• CI/CD 漏洞检测：针对持续集成 / 持续交付（CI/CD）流程中的漏洞，开发了相应的检测工具和技术，能够及时发现并修复流程中可能存在的安全隐患。

构建基础架构安全研究面临的未来挑战

• 透明度实现难题：虽然提高构建透明度是目标，但在实际应用中，如何在不增加过多成本和复杂性的前提下，实现全面、实时的构建过程透明化，仍是亟待解决的问题。
• 代码签名推广困境：尽管代码签名技术有助于保障软件完整性，但目前在行业内的广泛应用和接受度仍不理想，需要解决技术标准统一、证书管理等一系列问题，以推动其普及。
• 可重复性构建普及问题：要使可重复性构建在实际项目中得到广泛应用，需要克服技术、流程和人员等多方面的障碍，建立更加完善的支持体系和最佳实践指南。
• CI/CD 漏洞评估挑战：随着 CI/CD 技术的不断发展和应用场景的日益复杂，如何持续有效地评估和应对其中的安全漏洞，需要进一步研究和探索新的方法和工具 。

06 攻击向量：人为因素

实际挑战

软件供应链安全依赖行业集体行动与人员参与，相关框架需广泛采用和信息共享才有效。企业虽有安全措施，但面临文化适应问题，如 SolarWinds 事件后需调整安全文化。“guardrails, not gates” 方式平衡开发速度与安全，但仍有风险。此外，自动化漏洞修复可减轻开发者负担，构建安全文化需全员参与。

研究成果

• 支持开发者：实施软件供应链安全复杂，开发者需应对第三方组件信任、代码漏洞等问题。研究发现多数公司有外部代码管理政策，但开发者需更多资源审计和保障组件安全。同时，研究建议开发者主动预见工具的负面影响。
• 开源生态系统：开源软件在软件供应链占比大，但面临开发分散、资源有限等问题。研究表明开源项目安全措施差异大，小项目资源不足，且存在秘密管理难题，如 API 密钥易泄露。
• 学术界：软件供应链安全研究人员面临伦理困境，如披露漏洞可能帮助或伤害用户，研究数据涉及隐私保护和使用许可问题。相关工作影响了计算机安全领域的伦理准则，促使研究人员讨论决策的伦理维度。

未来挑战

软件供应链安全方法的广泛采用至关重要，需确保其用户友好以推动行业接受。未来，高级网络钓鱼攻击将构成更大威胁，需通过改进培训、限制环境或利用 LLMs 防御等措施应对。此外，随着技术防御加强，内部威胁可能持续存在，需要更先进的行为监测和自适应安全协议。

07 软件供应链安全的其他研究方向

软件物料清单（SBOM）

• 概述与作用：SBOM 用于识别和跟踪软件系统中的第三方组件，能提高透明度、助力企业掌握软件风险，美国政府要求关键软件提供 SBOM。
• 面临的挑战：从业者虽认可其安全价值，但在实施中面临诸多问题。生成方面，工具生成的 SBOM 质量参差不齐，缺乏通用性，标准不统一且存在隐私问题。应用环节，当前流程混乱易错，SBOM 质量低且数据缺失，动态组件缺失和安全流程集成不足限制其应用。共享时，企业担心隐私泄露，且格式转换操作复杂。VEX 虽能提升 SBOM 安全性，但手动创建限制其价值，自动化生产 VEX 需解决信息识别等问题。

从业者挑战：自我认证和出处

美国行政命令要求政府承包商 CEO 对软件符合开发实践、开源软件完整性和出处进行自我认证。工业参与者担心要求不明确，部分企业因负担问题将产品开源以豁免认证，但多数人认为相关认证对安全更具基础性作用。

LLM 与软件供应链

• LLM 在软件供应链中的应用与风险：LLMs 在软件开发各阶段广泛应用，成为软件供应链一部分，但带来信任问题，如幻觉现象和不安全编码影响。在代码生成方面，能提高效率但可能生成不安全代码，且其供应链存在组件漏洞风险。
• LLM 在漏洞检测中的表现与问题：LLMs 在漏洞检测上比部分传统方法更有效，但存在误报、幻觉等问题。研究通过改进方法和框架提升其检测能力，但仍需克服性能和可靠性挑战。
• LLM 作为攻击向量的威胁：LLMs 可被用作攻击向量，如通过提示注入和第三方 API 集成引入新漏洞，研究展示了其被攻击的方式及潜在风险。
• LLM 性能与可扩展性研究方向：未来研究需全面提升 LLM 性能，降低成本，解决处理大文件时的局限性，提高效率和可扩展性，减少模型崩溃和幻觉现象。

从业者挑战：供应链标准、指南和框架

众多软件安全标准、指南和框架涌现，如 SSDF、SLSA 等，旨在降低供应链风险。但从业者在众多标准中难以抉择，Proactive Software Supply Chain Risk Management（PSSCRM）试图整合多个框架来提供统一指导。

软件供应链安全度量

美国将软件安全度量列为研究重点，但软件系统的特性使有效度量困难重重。提供支持需进行指标策划、数据发布和定期审查，以帮助开发者在复杂情况下做出决策，研究正朝着更实用的方向努力，如提供单个依赖及其生态系统的实时数据和指标。

08 结论

研究总结

软件供应链安全至关重要，近年来受 SolarWinds、log4j 等事件影响备受关注。行业和学术界针对代码依赖、构建基础架构、人员这三个主要攻击向量展开了大量研究。例如，行业中采用 SCA 工具、SBOMs 和 OpenSSF Scorecard 应对代码依赖问题，利用 SLSA、in - toto 和 TUF 保障构建过程安全；学术界则开发了新分析工具，对现有工具和生态系统进行实证研究，并与从业者沟通以了解实际挑战。

现存挑战

尽管取得了一定进展，但软件供应链安全仍面临诸多难题。在代码依赖方面，管理漏洞困难，开发者难以选择安全可靠的依赖项；构建基础架构方面，遗留环境难以改变，缺乏有效的分析工具，构建过程的可重复性难以实现；人员因素方面，需持续关注人为因素带来的风险；同时，LLMs 在软件供应链中的应用也带来了新的安全风险。

未来展望

未来需要持续深入研究软件供应链安全，具体包括改进依赖管理，加强构建环境安全，关注人员因素对软件供应链安全的影响，以及应对 LLMs 带来的新风险等。还计划开发 “软件供应链安全仪表板” 并发布年度报告，以满足从业者的数据需求并进行定期审查，从而更好地推动软件供应链安全的发展。