PeteAndrews1289/aws-devsecops-pipeline
GitHub: PeteAndrews1289/aws-devsecops-pipeline
该项目通过对比一个故意保留漏洞的 Flask 应用与一个经过安全加固的修复版本，在 GitHub Actions 中演示 Bandit、Trivy 等安全闸门如何与 Terraform 和 EKS 配置协同工作。
Stars: 0 | Forks: 0
# AWS DevSecOps：漏洞验证靶标 vs. 修复闸门
[](https://github.com/PeteAndrews1289/aws-devsecops-pipeline/actions/workflows/trivy-scan.yml)
本仓库对比了两个刻意设计为不同的应用程序目标：
- `app/backend/` 是一个**故意保留漏洞的验证靶标**。它包含命令注入、过时的依赖项、调试模式以及 root 容器，以便扫描器和运行时检测能够发现实质性的问题。
- `app/remediated/` 是一个**可供审查的修复目标**。它拒绝 shell 负载，避免 shell 执行，验证请求类型和 IP 地址，校验 TLS，以非 root 容器用户身份运行，并包含回归测试。
CI 会报告来自漏洞镜像的扫描结果，但不会将预期内的发现视为发布失败。已修复的应用程序是阻断路径：测试、Bandit、仓库规范性检查以及 HIGH/CRITICAL 级别的 Trivy 扫描结果可能会导致 pull request 失败。
## 本仓库展示的内容
```
flowchart LR
Push[Pull request or push] --> Vuln[Build vulnerable image]
Vuln --> Advisory[Trivy evidence scan
advisory] Push --> Fixed[Build remediated image] Fixed --> Tests[Regression tests + Bandit] Fixed --> Blocking[Trivy HIGH/CRITICAL gate
blocking] Push --> IaC[Terraform fmt + validate] Historical[Controlled, historical runtime lab] --> K8s[Kubernetes] K8s --> Event[Structured rejection / attack event] Event --> Splunk[Splunk HEC] ``` GitHub Actions 工作流会对仓库构件进行验证和扫描。它**不会**进行 AWS 身份验证、推送到 ECR、应用 Terraform、部署到 EKS，也不会证明当前存在正在运行的环境。 ## 安全性对比 | 控制措施 | 漏洞验证靶标 | 修复目标 | |---|---|---| | 用户输入 | 被拼接进 shell 命令中 | 要求 JSON 对象和字面量 IPv4/IPv6 地址 | | 命令执行 | 设计上采用 `shell=True` | 无 shell 或操作系统命令执行 | | 依赖项 | 故意使用过时版本 | 完全锁定的最新依赖集 | | 运行时模式 | Flask 调试服务器 | Gunicorn，禁用调试 | | 容器身份 | Root | 专属 UID/GID 10001 | | 遥测传输 | 启用 TLS 验证，但漏洞应用行为依然存在 | 仅限 HTTPS 的 HEC URL 验证和标准证书校验 | | CI 策略 | 建议性的扫描器证据 | 测试和安全检查具有阻断性 | 详细的映射关系请见 [`docs/findings-comparison.md`](docs/findings-comparison.md)。 ## 证据与局限性 此前的实验环境产生了三种证据： 1. Trivy 在故意使用旧版本的镜像中发现了 OS 和 Python 包漏洞。 2. 一次受控的命令注入请求到达了存在漏洞的 endpoint。 3. Splunk 从该次演练中接收到了一个结构化的 `command_injection_attempt` 事件。   这些截图是特定时间点的证据，并非当前的基准。扫描器数据库会发生变化，因此当前的 Actions 运行结果才是当前发现问题的权威依据。包含已弃用公共 endpoint、账户特定注册表路径或原始 shell 输出的截图已从当前分支中移除；它们仍然可以在 Git 历史记录中找回。 关于证据清单和明确的局限性，请参阅 [`docs/evidence-summary.md`](docs/evidence-summary.md)。 ## 仓库结构 ``` app/backend/ intentionally vulnerable Flask target app/remediated/ hardened comparison target and tests k8s/base/ remediated, private-by-default Kubernetes example terraform/ VPC, ECR, and EKS infrastructure example scripts/validate_repository.py hygiene and configuration assertions docs/ findings, lifecycle notes, and historical evidence .github/workflows/ pinned, least-privilege validation pipeline ``` ## 在本地运行修复目标 ``` python -m venv .venv source .venv/bin/activate python -m pip install -r app/remediated/requirements-dev.txt python -m pytest -q app/remediated/tests bandit -q -r app/remediated -x app/remediated/tests python scripts/validate_repository.py gunicorn --chdir app/remediated --bind 127.0.0.1:5000 app:app ``` 验证请求示例： ``` curl -sS -X POST http://127.0.0.1:5000/api/ping \ -H 'Content-Type: application/json' \ -d '{"target":"8.8.8.8"}' ``` 像 `8.8.8.8; cat /etc/passwd` 这样的输入会收到 HTTP 400 响应，并且永远不会被执行。 ## 验证基础设施示例 ``` terraform -chdir=terraform fmt -check -recursive terraform -chdir=terraform init -backend=false terraform -chdir=terraform validate ``` Terraform 配置在规划（planning）或应用（applying）之前需要一个明确的 `kubernetes_version` 值，这样仓库就不会在无声无息中推荐过时的 EKS 版本。其默认姿态使用私有的 EKS API 访问、控制平面日志、不可变的 ECR 标签、镜像扫描以及加密的 ECR 存储。 Kubernetes 基础是修复后的目标，它使用 `ClusterIP`，舍弃 Linux capabilities，禁用特权提升，启用默认的 seccomp 配置文件，并从 ConfigMap 和 Secret 读取可选的 Splunk 配置。Git 中不存储任何 HEC token 或账户特定的镜像仓库。 ## 安全的实验环境使用 不要将 `app/backend/` 暴露到互联网或为其提供真实的凭证。仅使用隔离的、用后即弃的基础设施和合成数据。保留漏洞代码仅仅是为了进行扫描器验证和受控的演示。 在配置任何内容之前，请查阅 [`docs/lab-lifecycle.md`](docs/lab-lifecycle.md)，估算 AWS 成本，选择当前受支持的 EKS 版本，并定义销毁检查点。原始的演练环境在完成后已被拆除。 ## 坦诚的后续计划 - 在将工作流描述为部署自动化之前，添加经过测试的 AWS OIDC 角色和 ECR 推送阶段。 - 将经过脱敏处理的 Splunk 搜索/仪表板导出为代码，而不是依赖截图。 - 添加一个临时的集成环境，以证明修复后的镜像可以在 Kubernetes 安全上下文中运行。 - 如果需要长期的漏洞趋势分析，请生成带有版本控制的扫描结果构件。
advisory] Push --> Fixed[Build remediated image] Fixed --> Tests[Regression tests + Bandit] Fixed --> Blocking[Trivy HIGH/CRITICAL gate
blocking] Push --> IaC[Terraform fmt + validate] Historical[Controlled, historical runtime lab] --> K8s[Kubernetes] K8s --> Event[Structured rejection / attack event] Event --> Splunk[Splunk HEC] ``` GitHub Actions 工作流会对仓库构件进行验证和扫描。它**不会**进行 AWS 身份验证、推送到 ECR、应用 Terraform、部署到 EKS，也不会证明当前存在正在运行的环境。 ## 安全性对比 | 控制措施 | 漏洞验证靶标 | 修复目标 | |---|---|---| | 用户输入 | 被拼接进 shell 命令中 | 要求 JSON 对象和字面量 IPv4/IPv6 地址 | | 命令执行 | 设计上采用 `shell=True` | 无 shell 或操作系统命令执行 | | 依赖项 | 故意使用过时版本 | 完全锁定的最新依赖集 | | 运行时模式 | Flask 调试服务器 | Gunicorn，禁用调试 | | 容器身份 | Root | 专属 UID/GID 10001 | | 遥测传输 | 启用 TLS 验证，但漏洞应用行为依然存在 | 仅限 HTTPS 的 HEC URL 验证和标准证书校验 | | CI 策略 | 建议性的扫描器证据 | 测试和安全检查具有阻断性 | 详细的映射关系请见 [`docs/findings-comparison.md`](docs/findings-comparison.md)。 ## 证据与局限性 此前的实验环境产生了三种证据： 1. Trivy 在故意使用旧版本的镜像中发现了 OS 和 Python 包漏洞。 2. 一次受控的命令注入请求到达了存在漏洞的 endpoint。 3. Splunk 从该次演练中接收到了一个结构化的 `command_injection_attempt` 事件。   这些截图是特定时间点的证据，并非当前的基准。扫描器数据库会发生变化，因此当前的 Actions 运行结果才是当前发现问题的权威依据。包含已弃用公共 endpoint、账户特定注册表路径或原始 shell 输出的截图已从当前分支中移除；它们仍然可以在 Git 历史记录中找回。 关于证据清单和明确的局限性，请参阅 [`docs/evidence-summary.md`](docs/evidence-summary.md)。 ## 仓库结构 ``` app/backend/ intentionally vulnerable Flask target app/remediated/ hardened comparison target and tests k8s/base/ remediated, private-by-default Kubernetes example terraform/ VPC, ECR, and EKS infrastructure example scripts/validate_repository.py hygiene and configuration assertions docs/ findings, lifecycle notes, and historical evidence .github/workflows/ pinned, least-privilege validation pipeline ``` ## 在本地运行修复目标 ``` python -m venv .venv source .venv/bin/activate python -m pip install -r app/remediated/requirements-dev.txt python -m pytest -q app/remediated/tests bandit -q -r app/remediated -x app/remediated/tests python scripts/validate_repository.py gunicorn --chdir app/remediated --bind 127.0.0.1:5000 app:app ``` 验证请求示例： ``` curl -sS -X POST http://127.0.0.1:5000/api/ping \ -H 'Content-Type: application/json' \ -d '{"target":"8.8.8.8"}' ``` 像 `8.8.8.8; cat /etc/passwd` 这样的输入会收到 HTTP 400 响应，并且永远不会被执行。 ## 验证基础设施示例 ``` terraform -chdir=terraform fmt -check -recursive terraform -chdir=terraform init -backend=false terraform -chdir=terraform validate ``` Terraform 配置在规划（planning）或应用（applying）之前需要一个明确的 `kubernetes_version` 值，这样仓库就不会在无声无息中推荐过时的 EKS 版本。其默认姿态使用私有的 EKS API 访问、控制平面日志、不可变的 ECR 标签、镜像扫描以及加密的 ECR 存储。 Kubernetes 基础是修复后的目标，它使用 `ClusterIP`，舍弃 Linux capabilities，禁用特权提升，启用默认的 seccomp 配置文件，并从 ConfigMap 和 Secret 读取可选的 Splunk 配置。Git 中不存储任何 HEC token 或账户特定的镜像仓库。 ## 安全的实验环境使用 不要将 `app/backend/` 暴露到互联网或为其提供真实的凭证。仅使用隔离的、用后即弃的基础设施和合成数据。保留漏洞代码仅仅是为了进行扫描器验证和受控的演示。 在配置任何内容之前，请查阅 [`docs/lab-lifecycle.md`](docs/lab-lifecycle.md)，估算 AWS 成本，选择当前受支持的 EKS 版本，并定义销毁检查点。原始的演练环境在完成后已被拆除。 ## 坦诚的后续计划 - 在将工作流描述为部署自动化之前，添加经过测试的 AWS OIDC 角色和 ECR 推送阶段。 - 将经过脱敏处理的 Splunk 搜索/仪表板导出为代码，而不是依赖截图。 - 添加一个临时的集成环境，以证明修复后的镜像可以在 Kubernetes 安全上下文中运行。 - 如果需要长期的漏洞趋势分析，请生成带有版本控制的扫描结果构件。
标签：DevSecOps, ECS, Terraform, 上游代理, 子域名突变, 安全工程, 请求拦截, 逆向工具