HimanM/devsecops-aws-pipeline-githubactions

# DevSecOps 流水线平台 [](https://github.com/HimanM/devsecops-aws-pipeline-githubactions/actions/workflows/devsecops-pipeline.yml) 一个生产级的 DevSecOps 演示平台，在整个软件交付生命周期中实施了企业级安全标准。本项目展示了在 CI/CD、基础设施即代码、容器管理和策略即代码执行中将**安全性**视为首要公民的最佳实践。 ## 实时部署 | 资源 | 值 | |----------|-------| | **前端 URL** | [http://devsecops-11-pub-alb-1507380937.us-west-2.elb.amazonaws.com](http://devsecops-11-pub-alb-1507380937.us-west-2.elb.amazonaws.com) | | **ECS 集群** | `devsecops-project-11-cluster` | | **AWS 区域** | `us-west-2` | | **最近部署时间** | 2025-12-29 20:33:53 UTC | ## 技术栈

## 目录 - [什么是 DevSecOps？](#what-is-devsecops) - [架构](#architecture) - [CI/CD 流水线工作流](#cicd-pipeline-workflow) - [实施的安全概念](#security-concepts-implemented) - [基础设施截图](#infrastructure-screenshots) - [如何在本地运行](#how-to-run-locally) - [仓库结构](#repository-structure) - [配置](#configuration) - [基础设施销毁](#infrastructure-teardown) - [许可证](#license) ## 什么是 DevSecOps？ **DevSecOps** 是在 DevOps 流程中集成安全实践的做法。该术语结合了 **开发**、**安全** 和 **运维**，旨在强调安全是整个软件交付生命周期中共同承担的责任。 传统的软件开发将安全视为发布前的最后一道关卡——一个导致延误和摩擦的瓶颈。DevSecOps 从根本上改变了这一点： | 传统方法 | DevSecOps 方法 | |---------------------|-------------------| | 将安全放在最后 | 从一开始就考虑安全 | | 手动安全审查 | 自动化安全扫描 | | 安全团队成为瓶颈 | 责任分摊 | | 后期修复成本高昂 | 早期修复成本低廉 | | 合规性被事后考虑 | 合规性即代码 | ## 架构 ### 基础设施图 ``` INTERNET │ ▼ ┌───────────────────┐ │ Public ALB │ │ (HTTP:80) │ └───────────────────┘ │ ┌───────────────┴───────────────┐ │ VPC │ │ ┌───────┐ ┌───────┐ │ │ │Public │ │Public │ │ │ │Subnet │ │Subnet │ │ │ │ AZ-a │ │ AZ-b │ │ │ └───────┘ └───────┘ │ │ │ │ │ │ └───────┬───────┘ │ │ │ │ │ ┌───────────────────────┐ │ │ │ Frontend ECS │ │ │ │ (Fargate:3000) │ │ │ └───────────────────────┘ │ │ │ │ │ ▼ │ │ ┌───────────────────────┐ │ │ │ Internal ALB │ │ │ │ (HTTP:3001) │ │ │ └───────────────────────┘ │ │ │ │ │ ┌───────────────────────┐ │ │ │ Backend ECS │ │ │ │ (Fargate:3001) │ │ │ │ PRIVATE ONLY │ │ │ └───────────────────────┘ │ │ ┌───────┐ ┌───────┐ │ │ │Private│ │Private│ │ │ │Subnet │ │Subnet │ │ │ │ AZ-a │ │ AZ-b │ │ │ └───────┘ └───────┘ │ └───────────────────────────────┘ ``` ### 安全架构 | 层级 | 安全控制 | 实施方式 | |-------|-----------------|----------------| | 网络 | 分段 | 公有/私有子网，NAT 网关 | | 网络 | 访问控制 | 遵循最小权限原则的安全组 | | 网络 | 内部路由 | 后端仅通过内部 ALB 访问 | | 计算 | 隔离 | Fargate（无需管理 EC2） | | 计算 | 非 root 用户 | 容器以 UID 1001 运行 | | 计算 | 只读文件系统 | 根文件系统为只读 | | 应用 | 请求头 | Helmet.js 安全请求头 | | IAM | 最小权限 | 每个角色仅授予最低权限 | | CI/CD | OIDC | 无长期有效的凭证 | ## CI/CD 流水线工作流 该流水线通过 **14 个独立的作业** 在每个阶段实施安全防护。每个作业都充当一个安全门禁，必须通过后才能继续执行。 ``` ┌─────────────────────────────────────────────────────────────────────────────┐ │ SECURITY GATES │ ├─────────────────────────────────────────────────────────────────────────────┤ │ │ │ [1. Secret Scan] ──► [2. Change Detection] ──┬──► [3. Frontend Build] │ │ │ │ │ └──► [4. Backend Build] │ │ │ │ │ ▼ │ │ [5. Container Build & Push] │ │ │ │ │ ▼ │ │ [6. Container Security Scan] │ │ │ ├─────────────────────────────────────────────────────────────────────────────┤ │ INFRASTRUCTURE VALIDATION │ ├─────────────────────────────────────────────────────────────────────────────┤ │ │ │ [7. Terraform Validate] ──► [8. Checkov Scan] ──► [9. OPA Policy Check] │ │ │ │ │ ▼ │ │ [10. Terraform Plan] │ │ │ │ │ ▼ │ │ [11. Manual Approval] │ │ │ │ │ ▼ │ │ [12. Terraform Apply] │ │ │ │ │ ▼ │ │ [13. Drift Detection] │ │ │ │ │ ▼ │ │ [14. Update README/Tags] │ │ │ └─────────────────────────────────────────────────────────────────────────────┘ ``` ### 详细的作业说明 #### 作业 1：密钥扫描 **目的**：防止敏感数据（API 密钥、密码、token）被提交到源代码管理中。 **工作原理**： - Gitleaks 会对每次推送进行硬编码密钥扫描 - 检测模式涵盖 AWS 密钥、GitHub token、私钥等 - 如果检测到密钥，流水线将立即失败 - 防止凭证流入生产环境  #### 作业 2：变更检测 **目的**：通过检测哪些组件发生了变更来优化流水线执行。 **工作原理**： - 分析 git diff 以识别被修改的目录 - 输出 `frontend`、`backend` 和 `infra` 的变更标志 - 下游作业根据这些标志有条件地执行 - 减少未变更组件的构建时间和资源消耗 #### 作业 3：前端 Lint 和构建 **目的**：对前端进行静态应用安全测试 (SAST) 和编译验证。 **工作原理**： - 带有安全规则的 ESLint 分析 TypeScript/JavaScript - 识别可能导致漏洞的代码模式 - npm audit 检查依赖项是否存在已知的 CVE - Next.js 构建验证应用程序能否正确编译  #### 作业 4：后端 Lint 和构建 **目的**：对后端 API 进行静态分析和依赖审计。 **工作原理**： - ESLint 分析 Express.js 代码中的安全问题 - npm audit 识别存在漏洞的依赖项 - 在容器化之前验证代码质量  #### 作业 5：容器构建和推送 **目的**：构建经过安全加固的安全 Docker 镜像。 **工作原理**： - 多阶段构建将最终镜像大小降至最低 - 非 root 用户 (UID 1001) 防止权限提升 - Alpine 基础镜像减少了攻击面 - 镜像使用 Git SHA 进行标记以实现可追溯性 - 推送至 GitHub Container Registry (GHCR) #### 作业 6：容器安全扫描 **目的**：扫描容器镜像是否存在已知漏洞 (CVE)。 **工作原理**： - Trivy 扫描操作系统包和应用程序依赖项 - 检测高危和严重级别的漏洞 - 如果发现严重问题，流水线将失败 - 防止部署带有漏洞的镜像  #### 作业 7：Terraform 格式化和验证 **目的**：确保基础设施代码符合标准并且在语法上正确。 **工作原理**： - `terraform fmt` 检查代码格式 - `terraform validate` 确保配置有效 - 在执行高成本的 plan 操作之前捕获语法错误  #### 作业 8：IaC 安全扫描 **目的**：根据 400 多项安全策略评估 Terraform 代码。 **工作原理**： - 检测诸如公开的 S3 存储桶、开放的安全组等错误配置 - 强制执行加密、日志记录和标签要求 - 如果发现严重的安全问题，则阻止部署 - 为失败项提供修复指导  #### 作业 9：OPA 策略检查 **目的**：使用策略即代码强制执行自定义的组织策略。 **工作原理**： - `/policies` 目录中的 Rego 策略定义了自定义规则 - 根据 Terraform plan JSON 评估策略 - 示例策略："后端必须是内部的"、"所有资源都必须有标签" - 在基础设施变更之前防止策略违规  #### 作业 10：Terraform Plan **目的**：在应用之前预览基础设施变更。 **工作原理**： - 生成详细的执行计划 - 显示将要创建、修改或销毁的资源 - 计划工件被保存以供审查和批准 - 在部署前实现明智的决策  #### 作业 11：手动批准 **目的**：在生产部署之前要求人工审查。 **工作原理**： - 使用带有必需审查者的 GitHub 环境 - 批准前可以看到 Terraform plan - 创建谁在何时批准了什么内容的审计追踪 - 防止自动化但未经授权的部署   #### 作业 12：Terraform Apply **目的**：将基础设施变更部署到 AWS。 **工作原理**： - 应用已批准的 Terraform plan - 使用 OIDC 身份验证（无存储的凭证） - 使用新的容器镜像更新 ECS 服务 - 根据定义创建/修改 AWS 资源  #### 作业 13：漂移检测 **目的**：检测实际基础设施何时与定义的状态不同。 **工作原理**： - 部署后运行 `terraform plan` - 将 AWS 状态与 Terraform 配置进行比较 - 根据当前状态重新评估 OPA 策略 - 对未经授权的手动变更发出警报  #### 作业 14：更新 README 和标签 **目的**：自动化文档和版本管理。 **工作原理**： - 使用新的镜像 SHA 标签更新 `variables.tf` - 使用部署信息更新 README - 使用 `[skip ci]` 提交变更以防止循环 - 确保文档保持同步 ## 实施的安全概念 ### 1. 密钥检测 防止敏感数据被提交到源代码管理中。Gitleaks 扫描以下内容： - AWS 访问密钥和秘密密钥 - GitHub token 和 SSH 私钥 - 数据库连接字符串 - API 密钥和密码 ### 2. 静态应用安全测试 (SAST) 带有安全插件的 ESLint 分析源代码以查找漏洞，而无需执行代码，从而识别可能导致安全问题的模式。 ### 3. 容器安全 - **Trivy 扫描**：检测操作系统包和依赖项的 CVE - **非 root 用户**：容器以非特权用户 (UID 1001) 运行 - **最小基础镜像**：Alpine Linux 减少了攻击面 - **多阶段构建**：最终镜像仅包含运行时依赖项 - **只读根文件系统**：防止运行时修改 ### 4. 基础设施即代码安全 针对 Terraform 配置评估 400 多项安全策略，在部署前检测错误配置。 ### 5. 策略即代码 (OPA/Rego) 在代码中定义可进行版本控制和测试的自定义组织策略。策略强制执行诸如后端隔离和强制标记等规则。 ### 6. OIDC 身份验证 使用身份联合在 GitHub Actions 和 AWS 之间进行无密码身份验证。不会在 secrets 中存储长期有效的凭证。 ### 7. 最小权限 IAM 每个组件仅获得所需的最低权限： - ECS 执行角色：仅限 ECR 拉取和 CloudWatch 日志 - ECS 任务角色：仅限 X-Ray 和 Secrets Manager 访问 - GitHub Actions 角色：范围限定于特定资源 ### 8. 网络分段 组件被隔离到安全区域中： - **公有子网**：只有 ALB 暴露在互联网中 - **私有子网**：后端服务无法直接访问互联网 - **安全组**：每个组件具有严格的入站/出站规则 ### 9. 手动批准门禁 带有必需审查者的 GitHub 环境确保了生产部署前的人工监督。 ### 10. 漂移检测 部署后的验证将实际的基础设施状态与 Terraform 配置进行比较，检测未经授权的变更。 ## 基础设施截图 ### 前端应用  ### 后端连通性  ### ECS 服务 | 前端服务 | 后端服务 | |------------------|-----------------| |  |  | ### 负载均衡器  | 公有 ALB | 内部 ALB | |------------|--------------| |  |  | ### 目标组  | 前端目标组 | 后端目标组 | |-----------------------|----------------------| |  |  | ### ECS 集群  ### IAM OIDC 提供者  ### Terraform 输出  ## 如何在本地运行 ### 前置条件 - Node.js 20+ - Docker 和 Docker Compose - Terraform 1.5+（用于基础设施） - 已配置 AWS CLI（用于部署） ### 初始设置（一次性） 在首次运行流水线或 Terraform 之前： 1. **创建 S3状态存储桶**： aws s3 mb s3://devsecops-project-11-tfstate --region us-west-2 2. **初始容器构建和推送**： # 登录 GHCR echo $GITHUB_TOKEN | docker login ghcr.io -u YOUR_USERNAME --password-stdin # 构建并推送前端 docker build -t ghcr.io/your_username/devops-project-11-frontend:latest ./frontend docker push ghcr.io/your_username/devops-project-11-frontend:latest # 构建并推送后端 docker build -t ghcr.io/your_username/devops-project-11-backend:latest ./backend docker push ghcr.io/your_username/devops-project-11-backend:latest 3. **运行 Terraform Apply**： cd terraform terraform init terraform apply 在完成此初始设置后，CI/CD 流水线将完全自动化。 ### 本地运行 ``` # Clone 仓库 git clone https://github.com/HimanM/devsecops-aws-pipeline-githubactions.git cd devsecops-aws-pipeline-githubactions # 后端 cd backend && npm install && npm run dev # Server 运行于 http://localhost:3001 # 前端 (新 terminal) cd frontend && npm install && npm run dev # Application 运行于 http://localhost:3000 ``` ### 本地测试安全工具 ``` # Secret 扫描 docker run -v $(pwd):/path zricethezav/gitleaks detect --source /path # Container 扫描 trivy image devsecops-frontend:latest # IaC 扫描 cd terraform && checkov -d . # OPA 策略 conftest test tfplan.json --policy ../policies/ ``` ## 仓库结构 ``` devops-project-11/ │ ├── frontend/ # Next.js frontend application │ ├── src/ │ │ ├── app/ # App Router pages │ │ └── components/ # React components │ ├── Dockerfile # Multi-stage build (non-root) │ └── .dockerignore │ ├── backend/ # Express backend API │ ├── src/ │ │ └── index.js # Server with Helmet security │ ├── Dockerfile # Multi-stage build (non-root) │ └── .dockerignore │ ├── terraform/ # Infrastructure as Code │ ├── providers.tf # AWS provider config │ ├── variables.tf # Input variables │ ├── vpc.tf # Network infrastructure │ ├── security-groups.tf # Least privilege network rules │ ├── iam.tf # Least privilege IAM roles │ ├── alb.tf # Load balancers (public + internal) │ ├── ecs.tf # ECS cluster and services │ └── outputs.tf # Output values │ ├── policies/ # OPA/Rego policies │ ├── no_public_backend.rego # Backend isolation enforcement │ ├── no_open_security_groups.rego │ └── mandatory_tags.rego # Tagging requirements │ ├── docs/ # Documentation and screenshots │ ├── .github/ │ └── workflows/ │ └── devsecops-pipeline.yml # 14-job security pipeline │ └── README.md # This file ``` ## 配置 ### 所需的 GitHub Secrets | Secret | 描述 | |--------|-------------| | `AWS_ROLE_ARN` | 用于 OIDC 身份验证的 IAM 角色 ARN | | `GITLEAKS_LICENSE` | （可选）Gitleaks 企业版许可证 | ### 设置 OIDC 身份验证 1. 在本地引导基础设施： cd terraform terraform init terraform apply 2. 复制 `github_actions_role_arn` 输出 3. 添加到 GitHub Secrets： - 仓库设置 → Secrets and variables → Actions - 使用角色 ARN 值添加 `AWS_ROLE_ARN` ### 配置手动批准 1. 前往仓库设置 → 环境 2. 创建名为 `production` 的环境 3. 启用“Required reviewers”并添加你自己 ## 基础设施销毁 ``` # 销毁所有资源 cd terraform terraform destroy -auto-approve # 删除 S3 state bucket aws s3 rm s3://devsecops-project-11-tfstate --recursive aws s3 rb s3://devsecops-project-11-tfstate # 清理本地文件 rm -rf .terraform/ terraform.tfstate* ``` ## 许可证 **MIT 许可证** - 版权所有 (c) 2025 [HimanM](https://github.com/HimanM) 本项目可免费用于**教育目的**。 如果您将本项目作为学习资源或模板，请通过链接回原始仓库的方式保留署名。

为安全而构建
_{由 HimanM 提供的企业级 DevSecOps 实践演示}

标签：AWS, CI/CD流水线, CISA项目, DevSecOps, DPI, ECS, Express, GitHub Actions, GNU通用公共许可证, IaC安全, MITM代理, Node.js, React, StruQ, Syscalls, Tailwind CSS, Terraform, TypeScript, 上游代理, 人工审批门禁, 企业级安全, 安全合规, 安全插件, 容器化服务, 开源框架, 持续部署, 持续集成, 机密扫描, 特权提升, 策略即代码, 网络代理, 聊天机器人安全, 自动化攻击, 自动化部署, 自动笔记, 请求拦截, 软件交付生命周期