AI Agent威胁下的GitHub Actions安全加固：7大防御策略详解

1. 项目概述：当AI Agent成为CI/CD管道的新威胁

最近在几个安全社区和项目群里，讨论得最凶的话题之一，就是AI Agent开始渗透和攻击自动化构建流水线了。一开始我以为是危言耸听，直到自己团队的一个边缘项目在GitHub Actions的日志里发现了异常调用链——一个本该执行单元测试的Job，竟然试图向一个外部未知API发送项目源码的Base64编码。排查后发现，问题出在一个被“投毒”的第三方Action上，而攻击的初始向量，很可能是一个被恶意引导的AI代码助手生成的“优化建议”。这件事让我惊出一身冷汗，也促使我花了大量时间深入研究。

所谓的“AI Agent攻击GitHub Actions”，并不是指一个具象的、有意识的AI在发动攻击。其核心是，攻击者利用大语言模型（LLM）驱动的自动化代理（Agent）的能力，来规模化地寻找、利用甚至创造CI/CD工作流（Workflow）中的安全漏洞。这些Agent可以自动扫描公开仓库的.github/workflows目录，分析YAML文件，识别出硬编码的密钥、不安全的上下文使用、未经校验的外部Action引用等弱点，然后自动生成恶意负载或进行试探性攻击。传统的安全扫描工具主要针对静态代码，而这种基于AI Agent的攻击是动态的、理解上下文语义的，甚至能进行逻辑推理来绕过简单规则，威胁等级完全不同。

这篇文章，就是把我这段时间的调研、实战分析和内部加固经验整理成一份清单。无论你是个人开发者，还是负责企业级CI/CD安全的工程师，这7条措施都应该立刻排上日程。我们不仅要修复已知漏洞，更要转变思路，应对这种新型的、智能化的自动化威胁。

2. 威胁模型拆解：AI Agent如何“理解”并攻击你的Workflow

在讨论加固之前，我们必须先弄明白对手是怎么工作的。只有理解了攻击链，防御才能有的放矢。AI Agent对GitHub Actions的攻击，可以抽象为一个多阶段的自动化过程，其“智能”体现在对工作流语义的理解和攻击路径的自主决策上。

2.1 攻击链全景：从侦察到利用

一个典型的攻击链可能包含以下步骤，这些步骤可以由一个AI Agent串联执行：

1. 目标侦察与收集：Agent利用GitHub API或直接爬取，批量获取公开仓库的Workflow文件（.yml/.yaml）。它不仅能收集文件，还能通过分析仓库的活跃度、星标数、所用技术栈（通过依赖文件识别）来对目标进行优先级排序，专注于高价值目标。

2. 语义分析与漏洞模式识别：这是核心环节。传统的正则匹配只能找secrets.GITHUB_TOKEN这样的字符串。而AI Agent能“理解”YAML结构。例如，它能识别出：

   • on: push意味着代码推送即触发，可能用于窃取新提交的代码。
   • runs-on: ubuntu-latest或self-hosted标签，后者意味着可能接入更敏感的内网环境。
   • uses: actions/checkout@v2后面没有带with: fetch-depth: 0，它可能推断出这个工作流不会拉取完整历史，从而调整攻击载荷。
   • 一段从steps中提取${{ secrets.XXX }}并echo到日志的代码，会被立刻标记为“密钥泄露漏洞”。
   • 一个引用第三方Action如uses: someuser/some-action@main（指向浮动分支）的行为，被识别为“供应链攻击入口”。

3. 攻击载荷生成与注入：识别到漏洞后，Agent可以生成具体攻击代码。例如，发现一个使用node:16容器且执行npm install的Job，它可能生成一段恶意命令，利用npm的preinstall脚本或污染依赖包进行攻击。更隐蔽的是，它可能生成一个Pull Request，声称“优化CI速度”，其中包含了微小的、恶意的Workflow修改。

4. 持久化与横向移动：一旦在Workflow执行中获得了初始立足点（如通过GITHUB_TOKEN获得了写权限），AI Agent可以规划后续动作，比如自动创建新的恶意Workflow、向仓库注入后门、或者尝试访问其他关联系统（如通过存储的云服务商密钥）。

2.2 AI Agent相较于传统攻击的优势

• 上下文理解：它知道docker build后面跟的--build-arg可能会传递密钥，而不仅仅是搜索password=这样的字符串。
• 逻辑推理：它能推断出“如果这个Job在if: github.ref == 'refs/heads/main'条件下运行，那么攻击它价值更高”。
• 自适应与规避：可以根据执行环境的反馈（如错误日志）调整攻击手法，尝试不同的利用路径。
• 规模化与自动化：7x24小时不间断地扫描、分析、尝试，覆盖范围远超人工黑客。

理解了这个威胁模型，你就会明白，我们之前的很多安全实践，比如简单的密钥扫描，已经不够用了。我们需要建立更深层的、基于权限和信任链的防御体系。

3. 加固清单第一条：最小权限原则与精细化令牌管理

这是所有安全措施的基石，也是对抗AI Agent自动化提权最有效的手段。AI Agent常利用过度宽松的权限来实现初始突破后的横向移动。

3.1 禁用默认GITHUB_TOKEN的写权限

GitHub Actions默认提供的GITHUB_TOKEN令牌，在早期版本拥有对当前仓库的广泛写权限。这太危险了。

你必须做的第一件事：在仓库的Settings > Actions > General页面，找到“Workflow permissions”部分。将默认选项从“Read and write permissions”改为“Read repository contents permission”。

这样，Workflow默认就只有读权限。当某个Job确实需要写操作（如创建Release、推送代码）时，再在具体的Job中通过permissions关键字进行精细化授权。

jobs: build: runs-on: ubuntu-latest # 默认继承仓库设置，即只有读权限 steps: - uses: actions/checkout@v4 publish: runs-on: ubuntu-latest needs: build # 仅为这个Job显式授予所需的写权限 permissions: contents: write # 明确只授予“写入内容”的权限 steps: - uses: actions/checkout@v4 - run: echo "构建发布包..." # 只有这个Job能执行git push等写操作

实操心得：不要觉得麻烦。这能有效遏制一种常见攻击：攻击者通过一个漏洞（如命令注入）获取了Job shell的控制权，然后试图用默认的GITHUB_TOKEN向仓库植入后门。如果令牌只有读权限，这个攻击链就断了。

3.2 为不同场景创建专属的精细权限令牌

对于需要访问其他仓库、包注册表（如npm、Docker Hub）或外部云服务（AWS、GCP、Azure）的场景，绝对不要使用GITHUB_TOKEN，更不要硬编码密码。

正确做法是使用仓库或组织的 Secrets，并配合最小权限的Personal Access Token (PAT) 或更安全的OAuth App、GitHub App。

1. 创建最小权限的PAT：

   • 进入 GitHub Settings > Developer settings > Personal access tokens > Fine-grained tokens。
   • 创建新令牌，只选择当前仓库，在权限列表里，像“挤牙膏”一样，只勾选这个Workflow必须的权限。例如，如果只是需要拉取另一个私有仓库的代码，只给Contents: Read-only就够了。
   • 将生成的令牌存入仓库的Secrets，命名为如READ_ONLY_PAT_FOR_REPO_X。

2. 在Workflow中使用：

   - name: Checkout private dependency uses: actions/checkout@v4 with: repository: my-org/private-repo token: ${{ secrets.READ_ONLY_PAT_FOR_REPO_X }} # 使用专用令牌

3. 对于云服务，使用OpenID Connect (OIDC)： 这是比长期静态密钥安全得多的方式。它允许GitHub Actions直接向云商（AWS等）申请短期访问令牌。

   • 优势：无需在GitHub存储任何云密钥；令牌自动生成，有效期极短（如15分钟）；可绑定到具体的仓库、分支甚至Workflow路径，实现极细粒度的信任策略。
   • 配置示例（AWS）：

     jobs: deploy: runs-on: ubuntu-latest permissions: id-token: write # 这是关键，申请OIDC令牌的权限 contents: read steps: - uses: actions/checkout@v4 - name: Configure AWS credentials uses: aws-actions/configure-aws-credentials@v4 with: role-to-assume: arn:aws:iam::123456789012:role/my-github-role aws-region: us-east-1

     在AWS IAM侧，你需要配置一个角色（my-github-role），并信任来自特定GitHub仓库的OIDC提供商。这样，只有你这个仓库的Workflow才能扮演这个角色，获得相应权限。

注意事项：定期审计（每月一次）仓库和组织中的Secrets，清理掉不再使用的令牌。对于PAT，定期轮换（如每90天）。使用OIDC可以极大减轻密钥管理的负担和风险。

4. 加固清单第二条：严格管控第三方Action的使用

供应链攻击是AI Agent的重点突破口。一个恶意的或被劫持的Action，可以瞬间污染你所有的构建环境。

4.1 强制使用不可变标签（Immutable Tags）

永远不要使用@main、@master或@v1（不带次级版本号）这样的浮动引用。今天你测试时Action是好的，明天维护者向main分支推送一个恶意提交，你的所有Workflow就会自动中招。

必须使用完整的、不可变的版本标识：

• 推荐：使用完整的语义化版本标签，如uses: actions/checkout@v4.1.1。
• 更安全：使用提交SHA，如uses: actions/checkout@8ade135a41bc03...。这是绝对不可变的。

如何方便地做到这一点？在引用Action时，多花几秒钟确认版本。你可以配置Dependabot来帮你自动更新Action版本，它会创建Pull Request，让你有机会在合并前审查变更。

4.2 建立内部Action代理或审核清单

对于企业级环境，最佳实践是不允许直接引用外部的uses:。

1. 搭建内部代理：使用类似 GitHub's Action Runner 的解决方案，或者云厂商提供的托管Runner，并配置防火墙规则，只允许从内部镜像源或经过批准的特定外部地址拉取Action。将常用的、审核过的第三方Action缓存到内部仓库或存储中。
2. 维护“允许列表”：如果代理方案太重，至少建立一个内部文档或自动化检查脚本，列出所有允许使用的第三方Action及其固定版本。任何Workflow新增或修改Action引用，都必须经过审核并更新此列表。
3. 使用actionlint进行静态检查：将actionlint集成到你的CI流程中，它可以检查Workflow语法，并可以配置规则来警告或阻止使用未经验证的Action。

   # 本地安装检查 brew install actionlint actionlint -pyaml .github/workflows/*.yml

4.3 审查Action的源码和依赖

对于将要引入的任何新Action，尤其是来自个人开发者或小团队的，务必执行以下检查：

• 查看仓库的活跃度和维护者：最后一次提交是什么时候？Issue和PR是否被处理？
• 审查action.yml文件：看它需要哪些输入，会产生哪些输出，运行在什么环境（runs-on或using）。
• 仔细看Dockerfile或JavaScript入口文件：对于docker或node类型的Action，检查其构建的镜像或执行的脚本是否有可能的危险操作（如下载执行远程脚本、curl | bash模式）。
• 注意嵌套依赖：一个Action可能会调用另一个Action。你需要递归地检查整个信任链。

踩过的坑：我们曾经引入一个用于Slack通知的Action，它本身很简单，但它内部依赖了一个用于格式化消息的第三方npm包。后来那个npm包被劫持，导致了信息泄露风险。所以，对于关键流程，尽量使用GitHub官方维护的Action（actions/*开头），或者自己编写简单的Shell脚本步骤来替代轻量级第三方Action。

5. 加固清单第三条：隔离构建环境与控制Runner

Workflow的执行环境（Runner）是攻击发生的主要战场。隔离和净化这个环境至关重要。

5.1 优先使用GitHub托管的Runner，并理解其局限性

对于公开仓库或大多数情况，坚持使用runs-on: ubuntu-latest这类GitHub托管的Runner。它的优势在于：

• 临时性：每次执行都是一个全新的、干净的虚拟机实例，执行完毕后立即销毁。这确保了“一次性的干净环境”，恶意软件无法持久化。
• 一致性：环境由GitHub维护，减少了因环境差异导致构建失败的安全风险。

但要注意：托管Runner运行在共享的云基础设施上。虽然虚拟机级别是隔离的，但你需要信任GitHub的安全能力。对于构建需要处理绝密级代码（如国防、金融核心算法）的场景，这可能不够。

5.2 安全地使用自托管Runner

当你需要特殊硬件、软件或处理极度敏感的代码时，自托管Runner是选择，但它将安全责任完全转移给了你。

自托管Runner的安全配置黄金法则：

1. 专用账户与强隔离：永远不要使用个人账号或高权限系统账号来运行Runner服务。创建一个专用的、权限最低的系统用户（如github-runner）。使用Docker容器或轻量级虚拟机来隔离每个Job的执行，避免Job之间相互影响。GitHub Actions Runner本身支持在Docker容器中运行Job。

   jobs: build: runs-on: [self-hosted, linux, x64, docker] # 指定标签 container: image: node:18-alpine # 在指定的Docker镜像中运行所有步骤

2. 网络隔离：将自托管Runner部署在独立的网络段，通过防火墙严格限制其出站和入站连接。只允许访问必要的服务（如GitHub.com、内部包仓库、制品库）。

3. 严格的标签系统：不要所有Job都跑在同一个Runner或Runner组上。使用标签来区分环境。

   runs-on: [self-hosted, production] # 只有打了production标签的Runner才能执行此Job

   这样，你可以将打有production标签的Runner部署在更严格、更隔离的网络中，专门用于部署生产环境，而开发测试的Job则在另一组Runner上运行。

4. 自动缩放与临时性：避免长期运行的静态Runner。使用像 actions-runner-controller （用于Kubernetes）或基于AWS EC2/Azure VMSS的自动缩放方案。每个Job在一个新创建的Runner实例上执行，完成后实例销毁，最大化隔离性。

5. 定期重置与更新：如果使用静态Runner，必须定期重启服务、更新Runner软件和主机操作系统，打上所有安全补丁。

重要警告：绝对不要在自托管Runner上处理来自公共仓库（Public Repository）的Workflow。因为任何人都可以通过提交Pull Request来触发你的Runner执行代码。这等于将你的内网环境暴露给了整个互联网。GitHub官方也强烈反对这样做。应为公共仓库和私有仓库配置完全独立的Runner群组。

6. 加固清单第四条：深度防御——Workflow静态分析与动态监控

除了配置，我们还需要工具来自动化地发现风险和监控异常。这是对抗AI Agent自动化扫描的主动防御。

6.1 集成静态安全扫描工具

将安全检查左移，在代码提交阶段就发现问题。以下工具可以集成到你的开发流程中：

• step-security/harden-runner：这是一个GitHub Action，它本身用于加固Runner环境。但它也提供了一种思路：在Workflow开始时，就启用一系列安全限制（如设置防火墙规则、限制网络出口、设置文件系统监控）。你可以参考它的做法，定制自己的加固步骤。
• actionlint：如前所述，它是Workflow的linter，可以检查语法错误、不安全的模式（如${{ secrets.GITHUB_TOKEN }}被打印的风险）。
• truffleHog/Gitleaks：这些是通用的密钥泄露扫描工具。将它们配置在CI中，每次推送都扫描整个代码库（包括Workflow文件），寻找硬编码的密码、API密钥、私钥等。

  - name: Scan for secrets uses: gitleaks/gitleaks-action@v2 with: config-path: .gitleaks.toml # 自定义规则

• 商业或开源SAST工具：像CodeQL、Snyk、Checkov（针对IaC）等工具，都有针对GitHub Actions的扫描规则包，可以识别复杂的漏洞模式。

建议流程：在仓库的/.github/workflows/目录下，创建一个security-scan.yml的Workflow，在每次推送和拉取请求时，自动运行上述扫描工具组合，并将结果以注释或状态检查的形式反馈。

6.2 实施动态行为监控与审计

静态扫描能解决已知模式，但对付新型的、动态生成的AI Agent攻击，还需要运行时监控。

1. 启用并定期审查GitHub Audit Log：对于组织仓库，务必启用审计日志。关注workflow相关事件，如workflow.run、workflow.job。查看是否有来自异常地理位置、异常时间或陌生用户（如果是组织）的Workflow触发。
2. 精细化日志记录：在你的Workflow中，对于关键步骤（如部署、数据库操作），增加详细的日志输出，记录操作摘要、影响范围。但切记不要记录任何敏感信息。
3. 监控Runner的异常行为（针对自托管Runner）：
   • 网络流量监控：Runner是否在Job执行期间向未知的外部IP或域名发起连接？特别是大量数据上传。
   • 进程监控：是否在Job中启动了预期之外的进程（如挖矿程序、反向shell）？
   • 文件系统监控：是否在Runner上创建或修改了预期之外的关键系统文件？ 你可以使用主机级的监控代理（如Auditd, Osquery）或基于eBPF的监控工具来实现。
4. 设置通知告警：为关键安全事件设置通知。例如，当有新的、高权限的Secret被创建时，当自托管Runner被注册到组织中时，或者当生产环境部署Workflow被从未授权分支触发时，立即通过邮件、Slack或Teams通知安全团队。

实操心得：监控的难点在于区分“正常”和“异常”。建议先建立一个基线：在1-2周内，只记录不告警，观察正常开发活动下的Workflow行为模式。然后基于这个基线，设置相对宽松的告警规则，再逐步收紧。否则，过多的误报会让团队忽略所有告警。

7. 加固清单第五条：代码与依赖的全面安全管控

Workflow的安全也依赖于它所要构建和处理的代码本身。一个被植入后门的项目依赖，可能会在构建过程中“合法”地执行恶意代码。

7.1 依赖锁定与可信源

1. 锁文件是必须的：对于Node.js的package-lock.json、Python的Pipfile.lock或poetry.lock、Rust的Cargo.lock等，确保它们被提交到仓库。这确保每次安装的都是经过验证的、特定版本的依赖，防止因依赖版本浮动引入恶意更新。
2. 使用私有代理或镜像源：将所有依赖下载源指向内部搭建的、经过审计的代理服务器（如Nexus, Artifactory）。这些代理可以缓存公共包，并对上传到内部的私有包进行安全扫描。同时，这可以屏蔽直接对公共仓库的访问，防止因公共仓库被污染而中招。
3. 在CI中运行依赖扫描：使用npm audit、snyk test、OWASP Dependency-Check等工具，在CI流水线中集成依赖漏洞扫描。配置为发现中高危漏洞时，阻塞合并或构建。

7.2 构建过程的安全加固

1. 非特权用户运行：在Dockerfile中，使用非root用户运行应用进程。在构建脚本中，避免使用sudo。

   FROM node:18-alpine RUN addgroup -g 1001 -S appgroup && adduser -u 1001 -S appuser -G appgroup WORKDIR /app COPY --chown=appuser:appgroup . . USER appuser # 关键：切换用户 RUN npm ci --only=production CMD ["node", "server.js"]

2. 多阶段构建与最小化镜像：使用Docker多阶段构建，最终镜像只包含运行所需的二进制文件和依赖，不包含编译器、构建工具等，减少攻击面。
3. 上下文与构建参数安全：谨慎使用Docker的--build-arg传递敏感信息。这些信息可能会保留在镜像历史中。对于构建密钥，考虑使用Docker BuildKit的--secret功能，它不会将密钥留在最终镜像或构建缓存中。

   # 在CI中 echo “MY_SECRET=super-secret” >> $GITHUB_ENV # 在构建步骤中 - name: Build with Secret run: | docker build --secret id=my_secret,env=MY_SECRET -t myapp .

8. 加固清单第六条：分支保护与代码审查流程

防止恶意代码进入主分支是第一道防线。AI Agent可能会尝试提交带有恶意Workflow的Pull Request。

8.1 启用并严格配置分支保护规则

对于你的主分支（如main、master、production），必须启用分支保护规则（Settings > Branches > Branch protection rules）。

核心强制检查项：

• Require a pull request before merging：必须通过PR合并。
• Require approvals：至少需要1个（建议2个）其他成员的审查批准。审查时必须有人工仔细检查.github/workflows/下的所有变更。
• Require status checks to pass：将你的CI流水线（包括前面提到的安全扫描Workflow）和代码质量检查（如lint）设置为必须通过的检查。只有所有检查通过，PR才能合并。
• Require conversation resolution：所有评论必须被解决。
• Include administrators：这条规则也适用于仓库管理员，防止权限滥用。

8.2 实施强制性的代码审查清单

为团队制定一个针对GitHub Actions变更的强制审查清单，在PR模板中体现。审查者必须逐项核对：

• [ ] 新增或修改的Action是否来自官方或可信源？是否使用了固定版本或SHA？
• [ ]GITHUB_TOKEN权限是否被显式设置为最小所需？是否有Job过度授权？
• [ ] 是否有新的Secret被引入？其用途和权限范围是否明确？
• [ ] Workflow中是否有任何echo、cat或日志输出可能暴露Secret？
• [ ]on:触发器（如push、pull_request、schedule）的设置是否合理？是否会过于频繁或在不安全的事件上触发？
• [ ] 对于自托管Runner，Job的runs-on标签是否指向了正确的环境（如productionrunner仅用于生产部署）？
• [ ] 是否有任何curl | bash或从网络下载并执行脚本的步骤？如有，URL是否可信且使用了HTTPS？

8.3 谨慎使用pull_request_target事件

pull_request_target事件是一个非常特殊且危险的事件。它在一个基于目标分支（如main）权限的上下文中运行来自**源分支（可能来自外部贡献者）**的Workflow代码。

这意味着，一个外部贡献者的PR，可以运行拥有你主分支写权限的Workflow！

黄金法则：除非你极度清楚自己在做什么，并且有严格的代码审查和沙箱环境，否则避免使用pull_request_target。对于需要验证外部PR的CI，可以考虑使用pull_request事件，并通过actions/checkout配合一个只读令牌来拉取代码，或者使用更安全的workflow_run事件来触发后续验证。

9. 加固清单第七条：建立安全响应与恢复预案

安全是一个持续的过程，没有一劳永逸的银弹。假设防御被突破，你必须知道如何快速响应和恢复。

9.1 制定事件响应清单

为“疑似GitHub Actions被入侵”准备一个简明的检查清单，贴在团队知识库中：

1. 立即隔离：
   • 撤销所有令牌：立即在GitHub设置中轮换（Revoke）所有可能泄露的Personal Access Tokens、OAuth App tokens、部署密钥。
   • 禁用相关Secrets：在仓库或组织的Secrets设置中，禁用（Disable）所有可能被涉及的Secret，但先别删除（用于后续取证）。
   • 停止或隔离Runner：如果是自托管Runner被入侵，立即停止该Runner服务，并将其从网络中隔离。
2. 取证调查：
   • 下载日志：从GitHub Actions页面下载所有相关Workflow运行的详细日志。
   • 分析触发事件：查看是什么事件触发了恶意Workflow（Push、PR、Schedule、Repository Dispatch）。
   • 追溯代码变更：审查是哪个提交引入了恶意的Workflow或修改了现有Workflow。使用git blame。
   • 检查制品和缓存：查看是否有异常的构建制品（Artifacts）被上传，或者缓存（Cache）被污染。
3. 清除影响：
   • 回滚代码：如果恶意代码已入主分支，立即使用git revert或重置到安全提交。
   • 清理Runner环境：如果使用自托管Runner，在取证后，销毁并重建受污染的虚拟机或容器实例。
   • 通知相关方：如果泄露了云服务密钥，立即登录相应云平台轮换密钥；如果泄露了第三方服务API密钥，立即通知对方撤销。
4. 复盘与加固：
   • 撰写事故报告，分析根本原因（是弱口令、不安全的Action、过度权限还是流程缺失？）。
   • 根据根本原因，更新本文档中的加固策略和团队流程。

9.2 定期进行安全演练

每季度或每半年，进行一次针对CI/CD流水线的“红蓝对抗”演练。可以模拟以下场景：

• 场景A：安全工程师（蓝军）尝试在测试仓库中提交一个包含恶意命令的Workflow，看团队审查流程能否发现。
• 场景B：尝试利用一个已知的、已修复的第三方Action旧版本漏洞，看系统是否因为未及时更新而中招。
• 场景C：模拟一个Secret在日志中泄露，检查监控告警是否能在规定时间内（如5分钟）触发。

通过演练，检验你的防御清单是否有效，团队响应流程是否顺畅。

10. 总结与持续实践

面对AI Agent这类新型的、自动化的威胁，固守传统的安全边界已经不够。GitHub Actions这样的自动化工具在提升效率的同时，也极大地扩展了攻击面。这份清单从权限、供应链、环境、监控、代码、流程、响应七个维度，构建了一个纵深防御体系。

最关键的是，安全不是一次性的配置，而是一种需要融入开发文化和日常习惯的持续实践。这意味着：

• 将安全扫描作为CI的强制门禁，失败则无法合并。
• 将Action版本更新作为常规依赖更新的一部分，使用Dependabot并认真审查变更。
• 在每次代码审查中，都把Workflow文件的变更视为与业务代码同等重要，甚至更重要。
• 定期（如每月）使用gh api等命令行工具或安全工具审计组织内的所有Workflow和权限设置。

AI Agent在攻击自动化，我们的防御也必须自动化、智能化。通过工具链的整合和流程的固化，我们可以让安全成为默认行为，从而在享受CI/CD带来的速度优势时，不必过分担忧背后的阴影。这份清单是一个起点，根据你的具体风险承受能力和技术栈进行调整，并始终保持对新的攻击模式和安全特性的关注。