为AWS CodeBuild管道实施深度防御安全策略

最近的安全研究强调了CI/CD管道配置的重要性，如AWS安全公告AWS-2025-016中所述。本文将现有指南和建议整合到一个指南中。

持续集成和持续部署（CI/CD）实践帮助开发团队高效可靠地交付软件。AWS CodeBuild提供与GitHub、GitLab和其他源代码管理（SCM）系统集成的托管构建服务。虽然本指南使用GitHub示例，但安全原则和webhook配置方法适用于其他支持的源代码控制系统。

然而，某些配置需要仔细关注。我们强烈建议在没有适当安全控制和对威胁模型的清晰理解的情况下，不要使用来自不受信任存储库贡献者的自动拉取请求构建。此配置允许不受信任的代码在具有存储库凭据和环境变量访问权限的构建环境中执行。Webhook配置决定了哪些存储库事件触发构建以及在构建过程中执行什么代码。理解这些配置对于维护适当的安全边界同时保留使CI/CD有价值的自动化优势至关重要。

安全团队和DevOps工程师可以使用这些实用方法来配置AWS CodeBuild，以满足其安全目标，同时保持开发速度。我们将探讨webhook配置、信任边界和实施策略，强调威胁模型评估、最小权限访问和管道配置的主动监控。

管道安全的影响

在共享责任模型下，虽然AWS管理底层AWS CodeBuild基础设施的安全，但客户负责保护其管道配置、访问控制以及在其构建环境中运行的代码。在考虑管道本身的安全性时，这种共享责任至关重要。

当AWS CodeBuild自动处理拉取请求时，它会在具有存储库凭据、环境变量和潜在敏感信息访问权限的环境中构建代码。这产生了特定的管道安全考虑：

存储库访问：AWS CodeBuild项目需要存储库凭据来读取源代码和创建webhook。这些凭据根据您的配置提供特定的权限。
构建执行：构建过程运行检索到的源代码，其中可能包括来自拉取请求的构建脚本、依赖项定义或测试文件。
构建环境：AWS CodeBuild环境可能具有对构建过程所需的环境变量、AWS凭据或其他配置数据的访问权限。

建立信任边界

有效的管道安全始于明确定义不同类型代码贡献的信任边界：

内部贡献者：具有存储库写入权限并通过组织访问管理流程验证的团队成员。
外部贡献者：从分叉存储库提交拉取请求的组织外部贡献者。
自动化处理：作为构建过程一部分在没有手动审查的情况下运行的代码。

这些信任边界构成了对特定环境进行威胁建模的基础。内部和受信任的环境通常可以更多地依赖自动化，包括贡献者过滤和最小权限控制。公共和开源项目由于处理不受信任贡献的固有风险而需要更严格的控制——这些环境受益于更严格的webhook过滤、全面的批准门控或后面讨论的自托管GitHub Actions运行器方法。

关键原则是根据您的特定风险状况和贡献者信任级别，在安全控制和开发速度之间找到适当的平衡。考虑到这些因素，让我们检查如何评估和配置当前的AWS CodeBuild webhook设置。

配置安全webhook

Webhook代表外部事件触发AWS CodeBuild过程的首选机制。当正确配置时，webhook提供了一种强大而高效的方法，以响应存储库更改来自动化构建过程。然而，不正确的webhook配置可能通过允许不受信任的代码在特权环境中执行来创建安全漏洞。您的webhook配置的安全性取决于准确理解哪些事件触发构建、这些构建具有什么级别的访问权限以及在构建过程中执行什么代码。本节提供了一种全面的方法来编写、评估、配置和维护安全的webhook配置。

评估当前webhook配置

首先查看您现有的AWS CodeBuild项目以了解其当前的webhook配置。以下AWS CLI命令提供了一种系统的方法来收集此信息：

1
2
3
4
5
6
7


# 列出您区域中的所有CodeBuild项目
aws codebuild list-projects --region us-west-2

# 检索详细配置进行分析
aws codebuild batch-get-projects --region us-west-2 \
  --names $(aws codebuild list-projects --region us-west-2 \
  --query 'projects[*]' --output text | tr '\n' ' ')

运行这些命令时，请特别注意输出中的webhook部分。此部分包含filterGroups配置，它决定了哪些存储库事件触发构建。

现在您了解了如何查看当前设置，让我们检查常见的配置模式及其安全影响。

Webhook配置模式

理解常见的webhook配置模式有助于您快速识别潜在的安全问题并实施适当的改进。以下模式代表了不同的webhook配置方法，每种方法都有特定的安全影响。

注意： 这些模式不推荐使用，此处显示是为了帮助您识别可能需要关注的配置。

需要审查的配置 – 自动拉取请求处理

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


{
  "webhook": {
    "payloadUrl": "https://codebuild.us-west-2.amazonaws.com/webhooks",
    "filterGroups": [
      [
        {
          "type": "EVENT",
          "pattern": "PULL_REQUEST_CREATED,PULL_REQUEST_UPDATED,PULL_REQUEST_REOPENED",
          "excludeMatchedPattern": false
        }
      ]
    ]
  }
}

此配置允许可以创建拉取请求的贡献者触发代码在您的构建环境中执行。我们强烈建议不要使用来自不受信任存储库贡献者的自动拉取请求构建。

需要立即审查的配置 – 无事件过滤

1
2
3
4
5
6


{
  "webhook": {
    "payloadUrl": "https://codebuild.us-west-2.amazonaws.com/webhooks",
    "filterGroups": []
  }
}

没有过滤，此配置可以触发各种存储库事件的构建。

Webhook配置实施步骤

在实施下面的webhook安全措施时，请考虑这些更广泛的实践：

威胁建模：在选择方法之前评估您的特定风险状况。
基础设施即代码：使用基础设施即代码（IaC）工具进行生产实施。
逐步实施：通过观察期逐步实施更改。
测试和回滚：首先在非生产环境中验证更改。

以下实施方法从最严格的方法转向更自动化的配置。选择最适合您组织的风险承受能力和操作要求的方法。这个三步过程从最严格的方法转向更自动化的配置，同时保持安全控制。每一步都建立在前一步的基础上，创建协同工作以保护您的管道的安全层。

注意： 以下示例使用AWS CLI进行演示。可以使用AWS管理控制台通过AWS CodeBuild项目设置执行类似的配置步骤。

步骤1：配置仅推送构建

基于推送的构建有助于确保只有经过验证的贡献者才能触发构建。这种方法更安全，因为贡献者必须已经通过您的存储库的访问控制机制进行审查，然后才能推送代码。配置您的webhook仅在推送事件时触发：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


aws codebuild update-webhook \
  --project-name your-project-name \
  --filter-groups '[
    [
      {
        "type": "EVENT",
        "pattern": "PUSH",
        "excludeMatchedPattern": false
      }
    ]
  ]'

步骤2：实施基于分支的过滤

基于分支的过滤通过确保仅对特定分支的更改触发构建来增加额外的安全层。这种方法认识到并非存储库中的所有分支都具有相同的安全要求或风险状况。

例如，对main或生产分支的更改通常需要比功能或开发分支的更改更严格的安全控制。通过实施基于分支的过滤，您可以根据不同分支的关键性和暴露程度应用适当的安全措施。

配置特定分支的过滤：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


aws codebuild update-webhook \
  --project-name your-project-name \
  --filter-groups '[
    [
      {
        "type": "EVENT",
        "pattern": "PUSH"
      },
      {
        "type": "HEAD_REF",
        "pattern": "^refs/heads/(main|develop|release/.*)$"
      }
    ]
  ]'

步骤3：配置贡献者过滤

贡献者过滤可用于管理拉取请求构建，允许为受信任的贡献者自动化，同时要求对其他贡献者进行手动审查。这种方法认识到不同的贡献者代表不同的风险状况，应相应对待。

实施贡献者过滤的第一步是识别您的受信任贡献者的GitHub用户ID。

检索受信任贡献者的GitHub用户ID：

1
2


curl -H "Authorization: token YOUR_GITHUB_TOKEN" \
https://api.github.com/users/trusted-username

一旦您有了受信任贡献者的用户ID，您可以配置webhook过滤以仅允许这些贡献者的自动化构建：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


aws codebuild update-webhook \
  --project-name your-project-name \
  --filter-groups '[
    [
      {
        "type": "EVENT",
        "pattern": "PULL_REQUEST_CREATED,PULL_REQUEST_UPDATED"
      },
      {
        "type": "GITHUB_ACTOR_ACCOUNT_ID",
        "pattern": "^(1234567|2345678|3456789)$"
      }
    ]
  ]'

重要： 贡献者允许列表需要随着团队成员的变化进行持续维护。考虑使用基础设施即代码模板（如Cloudformation示例）来管理版本控制中的webhook配置和贡献者列表。

Webhook过滤通过控制哪些事件触发构建来提供第一层安全。然而，全面的管道安全需要围绕这些构建一旦执行后可用权限和凭据的额外控制。以下部分介绍了如何通过适当的访问控制和凭据管理来实施深度防御安全。

访问控制和凭据管理

本节介绍了限制构建过程可用权限、适当范围存储库访问令牌以及创建有助于包含潜在安全问题的隔离环境的具体方法。这些实践共同工作，以实施深度防御安全，同时保持自动化CI/CD工作流的操作优势。

实施最小权限访问

AWS CodeBuild项目需要IAM服务角色来在构建过程中访问AWS资源。最小权限原则规定每个角色应仅具有执行其预期功能所需的最低权限。通过为不同类型的构建创建单独的、专门构建的IAM角色，您可以帮助减少对构建环境的未经授权访问的潜在影响。

以下示例演示了如何为不同的构建场景构建最小的IAM角色。这些示例作为起点，您应根据您的特定要求进行自定义，仅添加您的构建实际需要的权限。

服务角色配置

创建仅提供特定构建类型所需权限的最小IAM角色：

测试/验证构建角色

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


{
	"Version": "2012-10-17",
	"Statement": [
	{
		"Effect": "Allow",
		"Action": [
			"logs:CreateLogGroup",
			"logs:CreateLogStream",
			"logs:PutLogEvents"
		],
		"Resource": "arn:aws:logs:*:*:log-group:/aws/codebuild/test-*"
	},
	{
	"Effect": "Allow",
	"Action": [
		"s3:GetObject"
	],
	"Resource": "arn:aws:s3:::your-test-artifacts-bucket/*"
  }
 ]
}

发布构建角色（与测试分开）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


{
	"Version": "2012-10-17",
	"Statement": [
	  {
		"Effect": "Allow",
		"Action": [
			"s3:PutObject",
			"s3:GetObject"
		],
		"Resource": "arn:aws:s3:::your-production-artifacts-bucket/*"
	  },
	  {
		"Effect": "Allow",
		"Action": [
			"ecr:BatchCheckLayerAvailability",
			"ecr:GetDownloadUrlForLayer",
			"ecr:BatchGetImage",
			"ecr:PutImage"
		],
		"Resource": "arn:aws:ecr:*:*:repository/your-production-repo"
	  }
	]
}

利用IAM访问分析器进行CodeBuild安全

AWS IAM访问分析器可以根据您的构建执行的实际CloudTrail活动为您的AWS CodeBuild服务角色生成最小权限策略。这通过分析您的构建进行的特定AWS API调用来消除猜测，而不是要求您预测可能需要什么权限。

在运行您的CodeBuild项目代表一段时间后，使用访问分析器的策略生成功能来创建精细的策略。这种方法对于构建过程复杂且所需权限可能不立即明显的情况特别有价值。

有关详细实施步骤，请参阅IAM访问分析器文档。

凭据范围和源身份验证

在处理外部贡献时，最小权限原则对于存储库访问令牌变得至关重要。如果未经授权的用户通过不受信任的构建获得对令牌的访问权限，适当范围的令牌将潜在影响限制为仅构建过程所需的权限。

配置具有最小权限的细粒度GitHub个人访问令牌有助于降低此风险。即使被不当访问，适当范围的令牌也只能读取源代码（已经通过PR可访问）和写入状态消息——它不能推送代码、修改存储库设置或访问其他存储库。

以下权限代表了处理外部拉取请求所需的最低访问权限，演示了如何将令牌范围限制为仅基本操作：

contents:read – 对存储库源代码的只读访问（已经通过PR可访问）
statuses:write – 仅写入提交状态消息（不能修改代码或设置）
metadata:read – 访问基本存储库信息（名称、描述、公共状态）

重要： 使用仅限于目标存储库的细粒度个人访问令牌。否则，这可能允许访问超出构建过程所需的其他存储库。

这种范围方法确保即使令牌被不当访问，潜在影响也仅限于读取已经可访问的信息和写入状态消息。令牌不能推送代码、修改存储库设置、创建webhook或访问其他存储库。

凭据存储和轮换

以下示例演示了如何使用AWS Secrets Manager安全地存储和引用这些令牌。AWS Secrets Manager提供自动轮换功能、静态和传输中的加密以及细粒度的访问控制，有助于防止令牌在构建日志或配置文件中暴露。这种方法还支持跨多个CodeBuild项目的集中令牌管理，同时保持令牌访问的审计跟踪。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


# 将细粒度令牌存储在AWS Secrets Manager中
aws secretsmanager create-secret \
--name "codebuild/github-pat-limited" \
--description "Limited GitHub PAT for external PR processing" \
--secret-string '{"token":"ghp_your_limited_token_here"}'

# 创建具有范围凭据的CodeBuild项目
aws codebuild create-project \
--name external-pr-processor \
--source '{
"type": "GITHUB",
"location": "https://github.com/your-org/your-repo.git",
"sourceCredentialsOverride": {
"serverType": "GITHUB",
"authType": "PERSONAL_ACCESS_TOKEN",
"token": "{{resolve:secretsmanager:codebuild/github-pat-limited:SecretString:token}}"
},
"reportBuildStatus": false
}' \
--service-role arn:aws:iam::account:role/minimal-test-build-role

集中存储支持凭据轮换功能，有助于最小化暴露窗口，与需要基础设施更新才能轮换的硬编码令牌相比。

构建环境隔离

建立适当的构建环境安全控制有助于维护管道完整性。这种方法的基础涉及实施测试和发布构建之间的分离，这有助于防止凭据升级并限制潜在未经授权访问的范围。

网络隔离代表了另一层保护。通过创建具有仔细限制的出站访问权限的专用安全组，专门为处理外部代码的构建配置VPC设置。这些安全组应仅允许必要的连接，例如用于下载合法依赖项的HTTPS流量，同时阻止可能被不受信任代码利用的不必要的网络访问。

通过适当的VPC配置（包括指定的子网和您已建立的受限安全组）更新您的AWS CodeBuild项目以利用此网络隔离。

具有人工审查门控的多阶段管道安全

跨多个管道阶段实施安全控制有助于提供适当的验证和批准过程，特别是在处理外部贡献时。这种方法将自动扫描与人工监督相结合，以在问题到达生产环境之前识别问题。

代码检查集成

配置您的构建规范以在构建过程中自动运行安全工具，如Automated Security Helper。这些工具扫描代码安全问题和依赖项问题，生成详细的报告以供审查。

构建结构以在发现问题时继续执行，允许所有扫描完成，同时自动失败包含需要关注的安全问题的构建。存储所有扫描工件以为安全团队提供批准决策的详细信息。

手动批准门控

在代码通过自动安全扫描后，配置手动批准门控以让人类审查员参与最终验证。这有助于在进入敏感环境之前提供适当的人工审查。

本节中概述的访问控制和凭据管理实践为AWS CodeBuild