SaboorRafiq/terraform-secure-pipeline

# Terraform 安全流水线 这是一个 Terraform IaC 流水线，在合并前通过 GitHub Actions 强制执行自动化安全扫描（Checkov）。它的构建旨在展示实际的安全工程闭环——不安全的基线、扫描、修复、强制执行——而不仅仅是一个语法练习。 ## 项目简介 一个最小化的 AWS S3 bucket 部署，起初被故意配置错误，随后根据 Checkov 的策略检查进行了修复，并通过 CI 流水线自动阻止未来的配置回归。 ## 架构 - `main.tf` — S3 bucket + 公共访问阻止、版本控制、KMS 加密、访问日志记录 - `.github/workflows/terraform-security.yml` — 在每次向 `main` 发起 push/PR 时运行： 1. `terraform fmt -check` 2. `terraform init` 3. `terraform validate` 4. Checkov 扫描（阻断性 — 如果出现新的发现，流水线将失败） ## 修复历史 初始提交包含了一个故意不安全的 bucket：启用了公共访问，没有加密，没有版本控制，也没有日志记录。Checkov 标记了 11 项失败的检查（5 项通过 / 11 项失败）。 已修复： - 启用了所有四个 S3 公共访问阻止设置 (CKV_AWS_53, CKV_AWS_54, CKV_AWS_55, CKV_AWS_56, CKV2_AWS_6) - 启用了版本控制 (CKV_AWS_21) - 启用了 KMS 静态加密 (CKV_AWS_145) - 启用了访问日志记录 (CKV_AWS_18) 结果：13 项通过 / 3 项失败。 **故意推迟的项目，带有内联的 `checkov:skip` 注释和理由：** - CKV_AWS_144（跨区域复制）— 需要第二个 bucket + IAM role，超出了此演示的范围 - CKV2_AWS_61（生命周期配置）— 演示数据不需要 - CKV2_AWS_62（事件通知）— 需要配置 SNS/Lambda，超出了范围 这些并不是被遗漏的缺口——它们是记录在案的风险接受决策，与在生产环境漏洞管理程序中对发现的问题进行分类以应对可接受风险时所使用的模式相同。 完整差异：[基线提交](https://github.com/SaboorRafiq/terraform-secure-pipeline/commit/a4e2fff) → [修复提交](https://github.com/SaboorRafiq/terraform-secure-pipeline/commit/ed511d2) ## CI 强制执行 GitHub Actions 还会扫描其自身的工作流文件——CKV2_GHA_1 标记了流水线默认的 `write-all` 权限，并通过明确将其范围限定为 `contents: read` 进行了修复。请参阅 [Actions runs](https://github.com/SaboorRafiq/terraform-secure-pipeline/actions) 获取每次提交的完整扫描历史。 ## 验证强制执行 通过在分支上重新引入公共 ACL 暴露并向 `main` 发起 PR，测试了流水线的阻止行为。分支保护要求 Checkov 检查在合并前必须通过，且绕过仅限于明确的管理员覆盖——而不是默认路径。  在同一个分支上修复了 ACL 设置并推送到远端后，检查自动通过——没有使用绕过——PR 正常合并。 完整流程：[PR #1](https://github.com/SaboorRafiq/terraform-secure-pipeline/pull/1) ## 项目初衷 构建此项目是为了让我在实践中熟悉我在专业工作中使用的确切模式：IaC 安全扫描、策略即代码门控、CI/CD 流水线加固。这不是教程的副本——这里的每一个发现都是实际遇到、阅读并修复的，而不是预先解决的。 这反映了我在 Bentley 评估和修复 CI/CD 流水线风险时的工作——具体来说，就是将流水线配置默认视为不受信任的，并在其运行前通过自动化策略检查进行门控，而不是在事后才去信任它。

标签：DevSecOps, EC2, IaC, 上游代理, 安全合规, 漏洞利用检测, 网络代理