据 Google Cloud 介绍，近期多起软件供应链攻击显示，复杂威胁行为者正系统性地针对工程生命周期中的受信任环节发起入侵。攻击手段主要集中在三个方向：利用构建流水线中拥有高权限的安全扫描器、工具库和 AI 开发工具；通过定向社会工程、恶意扩展或拼写相近的本地依赖项渗透开发者工作站与集成开发环境（IDE），直接窃取加密密钥、API 令牌和会话凭证；以及采用 GitHub Actions 缓存投毒、OpenID Connect (OIDC) 令牌提取和篡改可变 Action 标签等高级流水线操纵技术，发布携带合法密码学来源证明的受损包。
为应对这些跨阶段威胁，该指南将防御体系划分为五个核心支柱。
开发者终端与本地环境防护
开发者工作站因能直接访问代码仓库、流水线和云环境而成为高价值目标。组织应在所有本地主机和云端开发环境中建立统一的安全层。在代码提交前，通过 pre-commit 钩子和 IDE 集成扫描工具拦截密钥泄露，并推动从传统个人访问令牌（PAT）迁移至具有严格生存时间（TTL）和最小权限的细粒度 PAT。
端点检测与响应（EDR）需监控 IDE 进程树中的异常文件访问和未经授权的网络连接，并将合规信号与统一端点管理（UEM）系统集成，以便在设备不合规时自动限制其对源代码管理系统的访问。同时，组织应仅批准特定版本的 IDE 和第三方扩展，明确阻止未经验证的插件。
在 AI 辅助开发方面，由于攻击者已开始向开源模型上下文协议（MCP）包中注入恶意代码以欺骗 AI 编码代理，安全团队应仅使用获批的大语言模型进行预合并漏洞分析，并在运行时执行前验证输入以防止上下文投毒。开发者应通过平台配置将本地 .env 文件排除在工作区之外，防止敏感凭证进入模型上下文窗口，且所有 AI 生成的代码在写入仓库前必须经过人工审核。此外，应尽可能要求使用容器化环境或专用虚拟机作为隔离沙箱，防止恶意安装脚本遍历本地文件系统。
代码仓库治理与凭据生命周期
保护代码仓库需要严格控制用户身份。实施公司托管用户（CMU）模式可保留对所有账户的控制权并强制防钓鱼多因素认证（如 FIDO2 物理安全密钥），但对于参与开源发布的团队，结合 SSO 的标准用户模型仍是推荐方案。无论采用何种模式，都应部署条件访问策略，在授权前持续验证设备状态。
分支管理应执行“禁止直接推送到主分支”策略，所有变更须通过独立功能分支并经同行评审和自动化 CI 检查。管理员绕过策略应被禁用，强制推送活动需在文件系统层面受到限制和监控。审计历史应被持续分析，以识别时间线篡改和用于代码外泄的未授权存储库。
凭据管理方面，应弃用易受本地信息窃取恶意软件攻击的静态 PAT，转向基于硬件安全密钥的 SSH 认证。对于自动化 CI/CD 流水线和第三方集成，应强制使用 GitHub Apps 替代服务账户 PAT，以获取一小时后自动过期的短期高范围访问令牌。密钥不应存储在环境变量中，而应利用平台原生功能在运行时注入。
依赖项安全要求禁止使用语义化版本控制（SemVer）中的动态版本范围（如 ^、~ 或 *），强制精确版本锁定并配合加密验证的 lockfile。未经核实的执行方式（如直接 curl 到 bash 的脚本）应被阻止，转而使用通过显式 SHA-256 摘要调用的供应商容器。构建过程应生成软件物料清单（SBOM）并强制执行 SLSA Level 2+ 来源检查。
制品管理与依赖项隔离
单点扫描已不足以防御制品层威胁，外部组件在进入下游前需接受持续检验。指南建议对新发布的公共包版本强制执行至少七天的发布冷却期，利用这段时间让开源社区发现并移除潜在的恶意包，再允许其在内部构建中被安装。
所有外部包和容器镜像应尽可能通过集中式内部代理路由，该代理负责缓存、检查和把关。新到达的组件应处于隔离状态并接受筛查，若安全判定失败则自动阻断构建。内部仓库应与公共注册表保持隔离，以防止依赖混淆攻击。
容器镜像和第三方依赖项需在注册表层和运行时进行自动化扫描，存储的制品应随新漏洞的出现被重新评估。扫描结果可通过可达性分析和 CISA 已知被利用漏洞（KEV）目录确定优先级，并使用漏洞可利用性交换（VEX）声明抑制不适用的发现。
来源验证同样关键。每个内部生成的容器镜像和包都应进行密码学签名，并绑定到特定的构建工作流和源提交。验证必须在准入时强制执行，且针对不可变摘要而非可变标签进行。长期存在的注册表发布令牌是供应链事件的常见根源，应替换为在发布瞬间颁发给特定构建工作流的短期身份绑定发布令牌。容器镜像标签和 Action 引用默认是可变的，固定到不可变的密码学摘要可以防止上游参与者在不更改名称的情况下静默替换内容。
CI/CD 流水线加固
CI/CD 环境因需要广泛访问代码仓库、第三方注册表和云基础设施而成为高价值目标。首要防御目标是消除运行器的持久性，使用临时单次运行器确保每个任务在全新隔离环境中执行并在完成后销毁。自托管环境的出站流量应仅限于预先批准的注册表和仓库 API。
为缓解中毒流水线执行（PPE）攻击，执行引擎应阻止来自拉取请求的未审查代码访问密钥或触发部署级运行器，直至获得管理员手动批准。共享构建缓存需按分支权限严格隔离，拒绝来自未认证 Fork 的缓存写入。
权限控制方面，应禁止工作流中存在持久性自动化密钥，改用 OIDC 将流水线身份交换为短期令牌。运行器身份默认应为只读或无权限，需显式请求最小可行权限。禁止凭证在下游模板或嵌套工作流中自动继承，并限制未经批准的第三方插件和市场 Action。网络与 IAM 边界应分段，使早期验证任务与拥有发布权限的系统完全解耦。基础设施即代码（IaC）需在部署前扫描，以拦截权限过高的密钥和运行器 RBAC 错误配置。
扫描门控应贯穿整个部署流程：
- 密钥扫描：在开发者提交或 PR 阶段，通过 pre-commit 钩子阻止包含硬编码密钥的推送。
- SAST：在 PR 或同行评审阶段，集成到 CI 测试中以标记逻辑漏洞。
- SCA：在构建阶段，针对锁文件扫描已知 CVE。
- 容器/镜像扫描：在注册表或推送阶段，拒绝包含关键操作系统级漏洞的镜像。
- DAST：在暂存或预部署阶段，模拟真实攻击验证运行时防御。
- CSPM：在部署前后扫描 IaC 模板，阻止错误配置的云环境。
SBOM 应作为构建步骤以 CycloneDX 或 SPDX 格式生成并签名，作为防篡改证明绑定到制品摘要，配合 VEX 声明保持其可操作性。
部署与运行时保护
运行时保护作为最后一道质量关卡，直接在运行的应用和容器实例上执行。生产环境入口应设置自动化安全检查，拦截缺乏有效密码学签名、请求不必要 root 权限或源自不受信任公共注册表的容器。工作负载应从加固的基础镜像构建，运行在具有只读根文件系统并移除 SSH 能力的不可变基础设施上。
运行时应用自我保护（RASP）可用于拦截 SQL 注入等执行级漏洞利用尝试。对于 AI 工作负载，可使用运行时护栏防范提示注入和越狱。常驻管理员权限应被消除，替换为仅在需要时于运行时注入的限时任务范围凭证。
在网络与云控制面，边缘防火墙需过滤传入的应用层流量；API 网关和负载均衡器集中处理边缘认证和速率限制；微分段策略通过身份感知的网络规则隔离工作负载，默认阻止横向移动。Policy-as-Code 工具应持续验证实时环境是否与版本控制的 IaC 源保持一致，并自动还原带外修改。CSPM 和 CNAPP 平台用于持续扫描云错误配置和过度宽松的 IAM，同时收集完整的日志、指标和审计事件以维持系统可见性。