北京
18,000家企业部署的签名软件，源头竟被调包。攻击者没碰证书，没破加密，只是在编译那几秒换了行代码。
这是2020年SolarWinds事件最细思极恐的细节。它暴露了一个被长期忽视的真相：数字签名只能证明"谁签了名"，证明不了"签的是什么东西"。
攻击者在SolarWinds的构建服务器上植入名为SUNSPOT的恶意程序。该程序每秒监控构建流程，一旦Orion平台开始编译，立即将InventoryManager.cs源代码替换为植入后门的版本。构建完成后，再换回原代码。源代码仓库中零痕迹。最终生成的二进制文件用SolarWinds的合法证书签名，分发给了超过18,000家机构。
最可怕的是：签名100%有效。代码签名只保证"签名者签了这份文件"，完全不保证"这份二进制文件来自正确的源代码、经由未被篡改的构建流程生成"。
同年发生的Codecov事件结构类似。攻击者用泄露的凭证直接将恶意脚本上传到GCS存储桶，完全绕过构建流程。用户直接下载。一个从未经过构建流程的产物，被当作合法软件分发。
什么能阻止这类攻击？我们需要可验证的证据，记录"这份二进制来自哪个源代码、在什么平台上构建、具体如何生成"。
SLSA（Supply-chain Levels for Software Artifacts，读作"salsa"）正是为此设计的框架。Google于2021年提出，现为OpenSSF项目。v1.1于2025年4月正式获批，v1.2引入Source Track，于2025年11月发布。
本文深入解析SLSA核心规范，说明我们到底在保护什么、如何保护。
软件供应链涵盖从编写代码到在用户机器上运行的每一步。
从git push到npm install或docker pull之间，大量基础设施介入：
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
