夜雨聆风场景描述
密码所在的代码从开发到部署，需要经过复杂的软件供应链——开源依赖、构建工具、CI/CD管道、容器镜像等环节。每个环节都可能成为攻击者的突破口。
软件供应链攻击近年急剧增加：从SolarWinds的编译器投毒，到Log4j的漏洞爆发，再到Codecov的脚本篡改，攻击者发现破坏上游比攻击单个目标更有效。
技术细节
软件供应链全景
通俗理解：像"食品从农田到餐桌"的全流程，每个环节都可能被污染。
各环节风险：
| 开发环境 | ||
| 源码仓库 | ||
| 依赖管理 | ||
| 构建系统 | ||
| 制品仓库 |
GitHub 仓库：https://github.com/gb233/what-happens-when-you-login存放本系列文章
开源依赖安全管理
通俗理解：像"食材采购"——你用的开源包可能含有"过期"或"有毒"的成分。
SCA工具（Software Composition Analysis）
功能：
自动识别项目中使用的开源组件 检测已知漏洞（CVE匹配） 识别许可证合规风险 生成SBOM软件物料清单
主流工具对比：
| Snyk | ||
| Dependabot | ||
| OWASP DC | ||
| JFrog Xray |
GitHub Dependabot配置示例： 
依赖锁定与哈希校验
为什么需要锁定： 
锁定文件对比：
CI/CD管道安全
通俗理解：像"食品加工厂"的安检——确保每个工序都不被篡改。
最小权限原则
危险配置： 
安全配置： 
密钥管理
永远不要做的事情： 
正确做法： 
流水线隔离
安全实践：
- 不可变构建
：每次构建使用全新的干净环境 - 沙箱执行
：构建步骤在隔离容器中运行 - 只读挂载
：源码目录只读，防止构建过程篡改 - 网络隔离
：构建环境限制出站连接
SBOM软件物料清单
通俗理解：像"食品成分表"——清晰列出软件包含的所有组件及其来源。
SBOM价值
Log4j应急响应案例： 
SBOM格式
SPDX（Software Package Data Exchange）：
Linux基金会标准 丰富的元数据（许可证、版权、校验和） 支持多种文件格式（Tag-Value、JSON、RDF、YAML）
CycloneDX：
OWASP项目 安全导向设计 漏洞利用、补丁状态追踪
生成工具示例： 
代码签名与验证
通俗理解：像"防伪标签"——确保软件确实来自声称的发布者。
GPG签名
签名流程： 
GitHub分支保护： 
Sigstore/Cosign（无密钥签名）
传统签名的问题：
私钥管理困难（存储、轮换、泄露风险） 证书颁发复杂 验证链冗长
Sigstore解决方案： 
Kubernetes验证： 
开发环境安全
通俗理解：像"厨房卫生"——污染源可能从开发环境引入。
IDE插件安全
攻击案例：
2021年：VS Code恶意扩展窃取源代码 攻击者发布功能相似扩展，植入后门 开发者安装后，代码自动上传到攻击者服务器
防护措施：
- 官方市场
：优先使用官方验证的扩展 - 权限审查
：检查扩展请求的权限 - 源码审查
：关键扩展审查源码后再安装 - 隔离开发
：敏感项目使用隔离的开发环境
Git钩子（Pre-commit）
检测敏感信息提交： 
预提交框架（pre-commit）： 
开发容器（Dev Container）
隔离开发环境： 
代码仓库安全
通俗理解：像"库房管理"——确保源代码不被篡改和泄露。
分支保护策略
GitHub/GitLab配置： 
敏感信息检测
git-secrets： 
truffleHog（深度扫描）： 
攻击向量
1. 依赖混淆攻击（Dependency Confusion）
通俗理解：像"快递误投"——攻击者发布与内部私有包同名的公开包，导致构建系统自动拉取恶意公开包。
攻击原理： 
真实案例：
2021年，安全研究员Alex Birsan利用此技术成功入侵35+家科技公司 包括Apple、Microsoft、Tesla、Uber等 通过命名空间混淆获取内部系统访问权限
防护措施：
- 作用域隔离
：使用 @company/作用域区分内外包 - 版本锁定
：使用 package-lock.json、yarn.lock 锁定确切版本 - 私有仓库代理
：Nexus、Artifactory代理所有依赖查询 - 命名空间注册
：在公开仓库预注册公司命名空间
2. 恶意IDE插件
通俗理解：像"被污染的厨具"——开发工具本身成为攻击渠道。
攻击方式：
发布功能相似但植入后门的VS Code/Vim扩展 利用IDE的API访问源代码、文件系统、环境变量 通过自动更新机制推送恶意版本
真实案例：
2021年，VS Code恶意扩展窃取开发者源代码 超过100万安装量的扩展被发现包含挖矿代码 某些扩展窃取AWS凭证并上传到攻击者服务器
防护措施：
- 官方市场
：仅从官方市场安装扩展 - 权限最小化
：审查扩展请求的权限 - 离线审查
：高敏感项目离线审查扩展源码 - 定期审计
：检查已安装扩展的更新日志和行为
3. CI/CD凭证泄露
通俗理解：像"工厂钥匙管理不善"——自动化系统的权限被窃取。
泄露途径：
日志泄露： 
缓存中毒： 
环境变量注入： 
防护措施：
- 不在PR中使用机密
：fork的PR不应访问机密 - 日志脱敏
：CI系统自动过滤机密信息 - 短期凭证
：使用OIDC代替长期密钥 - 权限最小化
：工作流仅拥有必要权限
4. Typosquatting（拼写抢占）
通俗理解：像"高仿商品"——利用名称相似性诱导安装恶意包。
攻击方式： 
真实案例：
2017年，PyPI发现多个恶意包：acqusition（拼写错误acquisition）、reqeusts（requests） 包含后门代码，安装后窃取系统信息 数万次下载后才被发现
防护措施：
- 拼写检查
：安装前仔细核对包名 - 官方来源
：优先从官方渠道获取安装命令 - 下载量检查
：检查包的下载量和维护状态 - 代码审查
：首次安装时审查包源码
5. 上游仓库投毒
通俗理解：像"水源污染"——攻击者直接入侵开源项目的官方仓库。
攻击方式：
入侵开源项目维护者的账号 在合法包中植入恶意代码后发布 利用供应链传递性影响所有依赖该包的项目
真实案例：
ua-parser-js（2021年）：
维护者账号被入侵 发布带挖矿木马和窃取脚本的版本 影响数万项目
PyTorch（2022年）：
依赖混淆攻击：攻击者将恶意包 torchtriton发布至 PyPI，与内部私有源同名PyTorch nightly 用户安装时优先拉取 PyPI 恶意版本，导致 SSH 密钥等凭证被窃取 此为典型**依赖混淆（Dependency Confusion）**攻击，非发布流程被篡改
event-stream（2018年）：
维护者将包转让给"善意"贡献者 贡献者在依赖中添加窃取比特币的代码 影响数百万项目
防护措施：
- 版本锁定
：不自动更新到最新版本 - 代码审查
：关键依赖审查每次更新 - 私有仓库
：关键依赖fork到私有仓库 - 漏洞监控
：订阅依赖的安全通告
详细MITRE ATT&CK分析
T1195.001 - Supply Chain Compromise: Software Dependencies
- 战术
: Initial Access - 技术
: 通过恶意依赖获取初始访问 - 检测
: 依赖变更监控、异常网络连接 - 缓解
: M1047 (Audit), M1048 (Application Isolation)
T1195.002 - Supply Chain Compromise: Software Supply Chain
- 战术
: Initial Access - 技术
: 上游仓库投毒、构建系统入侵 - 检测
: SBOM变更审计、构建过程监控 - 缓解
: M1047 (Audit), M1053 (Data Backup)
T1199 - Trusted Relationship
- 战术
: Initial Access - 技术
: 利用受信任的依赖关系入侵 - 检测
: 第三方风险评估、供应商安全审查 - 缓解
: M1018 (User Account Management)
防护机制
企业实践：Google SLSA框架
SLSA（Supply Chain Levels for Software Artifacts） 是Google提出的供应链安全框架，分为4个级别：
| L1 | ||
| L2 | ||
| L3 | ||
| L4 |
Google实施要点：
所有内部软件达到SLSA L3以上 关键基础设施达到SLSA L4 使用Binary Authorization强制执行签名验证 构建环境使用Google Cloud Build的托管服务
企业实践：SolarWinds教训
事件回顾（2020年）：
攻击者入侵SolarWinds的构建系统 在Orion软件中植入后门（SUNBURST） 通过官方更新渠道分发给18,000+客户 包括美国政府部门和财富500强企业
根本原因：
构建环境缺乏隔离和监控 代码签名过程未检测到恶意代码 缺乏构建产出物的完整性验证
改进措施：
- 构建隔离
：构建环境与开发环境完全隔离 - 多因素签名
：需要多人审批才能签名发布 - SBOM生成
：每次构建生成完整物料清单 - 行为监控
：构建环境异常行为实时监控
企业实践：Log4j应急响应
事件回顾（2021年12月）：
Apache Log4j 2.x被发现存在Log4Shell漏洞（CVE-2021-44228） 影响全球数亿Java应用 CVSS评分10.0（最严重级别）
有SBOM的企业： 
无SBOM的企业： 
教训：
SBOM是应急响应的基础 需要自动化的依赖扫描工具 深度依赖（依赖的依赖）同样危险
配置示例：安全CI/CD流水线
触类旁通
依赖库 vs 食材供应商：一家出问题，所有餐厅受影响
类比起源
上海有100家餐厅，全都从同一家供应商采购食材。某天，供应商的食材被检出含有有害物质。这100家餐厅无论厨师多好、厨房多干净，做出来的菜都有问题——因为问题出在更上游。Log4j漏洞在2021年底爆发时，正是这个场景的完美再现：全球数亿应用使用Log4j记录日志，这个"食材"出了问题，所有"餐厅"都受影响，而且很多餐厅甚至不知道自己用了这种食材。
软件供应链的恐怖之处在于：你的代码可能是完美的，但你的依赖的依赖的依赖里藏着一颗定时炸弹。
延伸思考
- 类比零部件供应商
：汽车制造商依赖上千个零部件供应商，某个刹车片供应商出问题，整条汽车产线都要停工召回——这就是为什么头部企业需要SBOM（物料清单）来快速定位受影响产品 - 从食材到餐具
：供应链攻击不只针对代码，也包括CI/CD工具、Docker基础镜像、npm registry——整个开发工具链都是攻击面 - 思考边界
：开源软件的透明性是把双刃剑。你能看到代码（好事），但攻击者也能审计代码寻找漏洞（坏事）。封闭源码只是安全感，不是真正的安全
SBOM vs 食品成分表：清楚知道里面有什么
类比起源
你拿起一包薯片，翻到背面，成分表写着：马铃薯、植物油、食盐、调味料（谷氨酸钠、5'-核苷酸二钠）……你知道这里面有什么，如果你对某种成分过敏，可以立刻决定要不要买。SBOM（软件物料清单）就是软件的成分表——它列出软件中使用的所有开源组件、版本号、许可证和已知漏洞。
当一个新的CVE（公共漏洞）发布时，有SBOM的组织可以在5分钟内查出"我们的哪些产品用了这个组件"；没有SBOM的组织可能需要几天甚至几周，靠人工翻遍所有代码库。
延伸思考
- 类比医院用药记录
：医生查看患者过去的用药史（SBOM），才能判断新开的药会不会和之前的药相互作用（漏洞相互影响）。没有记录，就是在盲开药 - SBOM的局限性
：成分表告诉你里面有什么，但不告诉你做工是否卫生（代码质量）、是否过期（版本是否维护）。SBOM是起点，不是终点 - 思考边界
：美国政府2021年行政令强制要求政府供应商提供SBOM，这标志着SBOM从"最佳实践"变为"法规要求"——就像食品成分标注从自愿到强制
签名验证 vs 防伪标签：确认是正版不是假货
类比起源
你买了一双耐克球鞋，鞋盒上有防伪标签，扫码后跳转到官方验真页面，显示"正品"。这个防伪体系解决的问题是：这双鞋真的是耐克生产的吗？还是仿冒品？代码签名解决的是完全相同的问题——这个软件包/容器镜像/代码提交，真的是官方发布的吗？还是被中间人替换过？
Sigstore（现代代码签名基础设施）就像为每个软件版本提供一张官方防伪证书，记录了"谁"在"什么时候"通过"什么CI/CD流程"产出了这个制品。任何人都可以验证，任何篡改都会让签名失效。
延伸思考
- 类比公证处
：代码签名 + 透明日志（Rekor）就像公证处公证文件——不只是签名，还把签名记录在公开账本里，事后无法抵赖 - 签名 vs 加密
：签名证明"这是我发的"，加密保证"只有你能看"。两者解决不同问题，经常配合使用。比如加密传输（TLS）+内容签名（代码签名）双重保障 - 思考边界
：防伪体系的强度取决于私钥的安全性。如果攻击者窃取了签名私钥（就像仿冒者获得了真正的防伪印章），整个信任链就崩溃了——这就是密钥管理比签名算法本身更重要的原因
恶意包投毒 vs 食品掺假：混入正规渠道的危险品
类比起源
2008年中国三聚氰胺奶粉事件震惊全球：不法商家在婴幼儿奶粉中掺入三聚氰胺（可以让蛋白质检测数据"达标"）。奶粉通过了正常的流通渠道、正规的超市上架，外包装一切正常，质检报告也合格——但里面有毒。软件供应链投毒是完全相同的模式：攻击者向npm/PyPI注册与流行包名相近的恶意包（typosquatting），或者入侵合法包的维护者账号直接在正规包里植入后门（如2022年ua-parser-js事件）。
危险在于信任链：你信任npm registry，所以你信任从那里下载的包；你信任维护者，所以你信任他们发布的新版本。一旦信任链中的某个环节被攻击者利用，所有下游都受影响。
延伸思考
- 类比医药假药
：假冒伪劣药品通过正规药店销售，消费者无从分辨。制药监管的解法是：药品序列号追溯、GMP认证、定期抽检。软件包的解法是：包签名、SBOM、定期SCA扫描 - 依赖混淆攻击的原理
：企业内部有私有npm包（如 @company/utils），攻击者在公开registry注册同名包但版本号更高——某些工具会优先从公开源下载更高版本的包，从而执行攻击者的代码 - 思考边界
：开源生态的"信任预设"是其繁荣的基础，也是其阿喀琉斯之踵。一个维护者一旦变质（被收买、被勒索、账号被盗），影响范围可能是全球数百万应用。这不是技术问题，是供应链的治理问题
综合思考：供应链安全的纵深防御
从代码到生产的完整信任链
软件供应链攻击之所以危险，是因为它攻击的是"信任"本身，而不是"代码"本身。建立完整的纵深防御需要在每个环节都设置检查点：
SLSA框架：供应链安全的分级标准
就像食品安全有不同等级认证（无公害->绿色->有机），SLSA（Supply Chain Levels for Software Artifacts）把供应链安全分为4个等级：
供应链安全的常见误区
供应链安全是近年快速发展的领域，实践中存在几个常见认知误区，用类比可以帮助澄清：
快速响应：新CVE发布后该怎么做
当一个重大漏洞发布（如2021年Log4Shell），有SBOM和没有SBOM的企业响应速度差异巨大：
这就是SBOM从"合规要求"到"安全运营工具"的价值所在——食品成分表在召回事件时是救命工具，平时看起来只是标签。
供应链安全的类比全景回顾
四个类比共同构成了软件供应链安全的完整认知框架：
开发团队的供应链安全基线
无论团队规模，以下是可操作的供应链安全最小实践：
供应链攻击的演化趋势
软件供应链攻击正在快速演化，了解趋势有助于提前布防：
这些攻击的共同特征是：攻击信任而非绕过防护。传统安全工具在防范这类攻击时效果有限，因为攻击者利用的是合法的信任关系。这也是为什么供应链安全需要从"检测"转向"建立可验证的信任链"。
触类旁通的核心洞察
四个生活类比共同揭示了软件供应链安全的本质：依赖就像食材，上游污染波及所有下游；SBOM就像成分表，让你在危机时快速定位受影响范围；签名验证就像防伪标签，确保你拿到的是原装而非仿冒；恶意包投毒就像食品掺假，利用正规渠道传递危险内容。理解了这四层，也就理解了为什么供应链安全不只是"扫描依赖"——它需要从开发到运行的每个环节建立可验证的信任。
供应链安全的最终目标是：即使攻击者成功投毒了某个环节，也能在后续环节被发现和阻断。这正是纵深防御在供应链场景的体现——签名验证发现了被篡改的包，SBOM加速了受影响系统的定位，运行时监控捕获了异常行为。每一层都是独立的检测机会，而不是唯一的防线。正如食品安全不能只靠"信任供应商"，软件安全也不能只靠"信任开源社区"——信任是起点，验证是保障。
框架映射
| SAMM | |
| ISO 27001 | |
| ISO 27002:2022 | |
| NIST CSF | |
| SLSA | |
| SSDF |
总结
软件供应链安全是密码安全的基础防线。代码在到达运行环境之前，需要经过开发、构建、部署等多个环节，每个环节都可能引入安全风险。
关键要点：
- 依赖管理
：使用SCA工具持续监控漏洞，锁定版本防止意外更新 - CI/CD安全
：最小权限原则，使用OIDC代替长期凭证，流水线隔离 - SBOM必备
：软件物料清单是应急响应和合规的基础 - 代码签名
：使用Sigstore/Cosign等现代工具确保构建产出物完整性 - 开发环境
：IDE插件审查、Git钩子检测、开发容器隔离
纵深防御策略：
- 预防
：依赖锁定、私有仓库代理、分支保护 - 检测
：SCA扫描、密钥泄露检测、SBOM审计 - 响应
：漏洞通知、自动更新、快速修复
供应链安全口诀：
依赖非儿戏，锁定要仔细 CI/CD需隔离，密钥别硬编码 SBOM是底线，签名保平安 开发环境净，代码自然安
软件供应链安全的核心是可验证的信任链：不是盲目信任每个依赖，而是在每个环节建立验证机制——SBOM记录了用了什么，签名验证了来源是谁，SCA扫描了有没有已知漏洞，私有Registry控制了只使用审核过的包。信任需要被验证，防护需要被持续维护，这是供应链安全的永恒主题。
密码经过软件供应链的安全检验后，最终到达服务器运行环境——头部企业可能采用物理机、VMware、Docker、Kubernetes 或 FaaS/BaaS 等不同形态，下一章将展开各运行时环境的安全边界与凭证保护要点。
喜欢的朋友关注收藏点赞转发一下吧！
