黑客，现在正在盯上开发者机器里的“钥匙”。
近期已经发生了多起供应链安全事件：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
声明：本文来自玄月调查小组，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
