供应链攻击频发，AWS给出一套供应链安全最佳实践

原创

玄月调查小组
玄月调查小组

玄月调查小组

2026年6月11日 14:41
上海

在小说阅读器读本章

去阅读

黑客，现在正在盯上开发者机器里的“钥匙”。

近期已经发生了多起供应链安全事件：Shai-Hulud、axios 等。

不管是大厂，还是安全公司，都有中招。

这些攻击的共同点是：恶意包一旦在环境里执行，就会尝试获取凭证。

npm token、GitHub token、AWS IAM access key，都可能成为下一步扩散的入口。

攻击者不一定要一次打穿你的生产环境，他只要让你的开发环境帮他把生产环境钥匙交出来。

长期凭证，正在变成高危资产

Shai-Hulud 的攻击路径很典型。

攻击者通过钓鱼获取维护者凭证，发布恶意包。

用户下载并执行后，恶意代码继续获取其开发机和 CI/CD 环境中的密钥。

如果这些密钥是长期有效凭证，风险会被迅速放大。

因为攻击者拿到后，不只可以访问当前项目，还可能继续访问云资源、代码仓库、包注册表，甚至继续发布恶意版本。

AWS 的建议很直接：能不用长期凭证，就不用。

本地开发：用短期凭证替代Access Key

本地开发场景里，AWS 推荐使用 aws login 或 IAM Identity Center。

它们的核心价值是：开发者不需要把长期 access key 放在本地文件里，而是通过登录获取自动过期的短期凭证。

这并不能让恶意包完全无害，但能显著缩短攻击窗口。

攻击者即使拿到了凭证，也会面对过期时间和权限边界。

CI/CD：优先用 OIDC 替代长期云凭证

CI/CD 是供应链攻击的高价值目标。

很多团队会把云凭证直接放进 GitHub Actions、GitLab CI 或其他流水线密钥里。这样做的结果是：恶意依赖只要在流水线里执行，就有机会读取这些凭证。

AWS 推荐使用 OIDC federation。

做法是让 GitHub Actions 或 GitLab CI 在每个 job 运行时临时向 AWS 换取权限，而不是长期保存静态 token。

这样，每个 job 的权限可以按需发放，用完过期。

生产部署：只信任被签名的产物

除了让 CI/CD 使用短期凭证，AWS 还强调了产物签名。

对包或镜像做签名，可以让生产部署只接受经过可信流水线签名的产物。

这样即使某个开发者凭证被盗，攻击者也不能轻易把未验证的产物推到生产环境。

换句话说，OIDC 负责减少“凭证被偷”的风险。

签名负责减少“恶意产物上线”的风险。

第三方长期凭证怎么办

现实中不是所有服务都支持临时凭证。

AWS 的建议是，如果必须使用长期凭证，至少不要散落在开发者机器本地和流水线配置里。

应放入 AWS Secrets Manager 或 Systems Manager Parameter Store，并配合访问控制、自动轮换和审计日志。

也就是说，长期凭证如果无法消灭，至少要可控制、可追溯、可轮换。

出事后，看CloudTrail和GuardDuty

供应链安全事件发生后，SBOM 可以快速定位哪些应用包含受影响包，帮助评估爆炸半径。

所以要有 SBOM，SPDX 或 CycloneDX 都行。

而凭证一旦疑似泄露，问题就变成：它到底被拿去干了什么？

然后，CloudTrail 可以记录 AWS API 调用轨迹。GuardDuty 可以发现异常 IAM 活动。

AWS 特别建议关注异常 sts:AssumeRole、陌生来源读取 Secrets Manager 或 SSM Parameter Store、开发机绕过 CI/CD 直接推送镜像等行为。

这些都可能是恶意包执行后的横向扩散信号。

别让凭证活太久

供应链安全不是单点防御，而是收紧攻击面。

总体来看，AWS 的方案不是依赖单个检测工具。

而是通过临时凭证、最小权限、签名、集中依赖、持续扫描、SBOM 和监控响应构建多层控制。

减少攻击者利用单个凭证或恶意包横向扩散的机会。

参考资料：Well-architected best practices for software supply chain security https://aws.amazon.com/cn/blogs/security/well-architected-best-practices-for-software-supply-chain-security