MohammedHabibQureshi/aws-cloud-security-posture-monitor

[README.md](https://github.com/user-attachments/files/29245736/README.md) ## 📋 目录 - [这是什么？](#-what-is-this) - [解决的痛点](#-the-problem-it-solves) - [现场演示 — 能查出什么](#-live-demo--what-it-catches) - [架构设计](#-architecture) - [使用的 AWS 服务及原因](#-aws-services-used--why) - [安全检查 (CIS Benchmark)](#-security-checks-cis-benchmark) - [技术栈](#-tech-stack) - [项目结构](#-project-structure) - [5 分钟内完成部署](#-deploy-in-5-minutes) - [真实测试结果](#-real-world-test-results) - [运行测试](#-running-the-tests) - [CI/CD Pipeline](#-cicd-pipeline) - [成本明细](#-cost-breakdown) - [路线图](#-roadmap) - [贡献指南](#-contributing) - [License](#-license) ## 🔍 这是什么？ **AWS 云安全态势监控器 (CSPM)** 是一款生产级、完全 serverless 的工具，可持续审计您的 AWS 账户是否存在安全错误配置和违规行为。 它会每 24 小时自动运行一次（并在 API 事件触发时实时运行），根据 **20 多项 CIS AWS Foundations Benchmark v1.5 控制**检查您的资源，并在检测到错误配置后的几分钟内，向 Slack 和电子邮件发送可操作的告警。 所有内容 —— 每一个 Lambda 函数、每一个 IAM 角色、每一个 DynamoDB 表、每一个 CloudWatch 告警 —— 均使用 **Terraform** 定义，并通过单条命令完成部署。 ``` terraform apply → entire security monitoring stack live in under 2 minutes ``` ### 为什么会有这个项目？ 因为云端的错误配置往往是悄无声息的。一个 S3 存储桶可能突然变成了公开状态；一个安全组可能被添加了 `0.0.0.0/0`；一个 root 账户可能从未启用 MFA。这些问题往往潜伏数周或数月而不被发现 —— 直到发生数据泄露。 这款工具就是能够在第一时间捕获这些问题的自动化防护层。 ## 🔥 解决的痛点 每一个 AWS 账户，无论管理得多么仔细，都会累积一些隐蔽的错误配置： | 错误配置 | 风险 | 发生频率 | |---|---|---| | root 账户未启用 MFA | 密码一旦被盗即可完全接管账户 | 极其普遍 | | S3 存储桶允许公开访问 | 数据向整个互联网暴露 | 非常普遍 | | 安全组对 `0.0.0.0/0` 开放 SSH/RDP | 服务器直接暴露在互联网暴力破解之下 | 非常普遍 | | 访问密钥从不轮换 | 被盗的凭证将无限期有效 | 非常普遍 | | CloudTrail 被禁用或配置错误 | 数据泄露无法被察觉，无法进行取证 | 普遍 | | EBS 卷未加密 | 静态数据明文存储，导致违规 | 普遍 | | IAM 密码策略太弱 | 暴力破解凭证攻击容易得手 | 普遍 | 这款工具能够自动检测上述 **所有问题** —— 抢在攻击者发现之前。 ## 🎬 现场演示 — 能查出什么 部署完毕后，针对一个配置错误的测试账户运行扫描： ``` { "statusCode": 200, "body": { "findings": 21, "summary": { "CRITICAL": 4, "HIGH": 6, "MEDIUM": 8, "LOW": 3 } } } ``` **Slack 告警示例：** ``` 🛡️ AWS Security Scan Alert 🔴 CRITICAL 4 🟠 HIGH 6 🔴 CIS-1.5 — Root account MFA not enabled `root` → Enable MFA on root account via IAM console. 🔴 CIS-2.1.5 — S3 bucket cspm-test-public does not fully block public access `arn:aws:s3:::cspm-test-public` → Enable all four public access block settings. 🔴 CIS-5.2 — SG allows unrestricted SSH (port 22) inbound `sg-0abc1234def` → Restrict port 22 to specific IP ranges. ``` ## 🏗️ 架构设计 ``` ┌─────────────────────────────────────────────────────────────────────────┐ │ AWS Account │ │ │ │ ┌─────────────────┐ ┌──────────────────────────────────────────┐ │ │ │ EventBridge │────▶│ Lambda (Python 3.11) │ │ │ │ Daily cron │ │ │ │ │ └─────────────────┘ │ ┌──────────────┐ ┌─────────────────┐ │ │ │ │ │ IAM Checks │ │ S3 Checks │ │ │ │ ┌─────────────────┐ │ └──────────────┘ └─────────────────┘ │ │ │ │ CloudTrail │────▶│ ┌──────────────┐ ┌─────────────────┐ │ │ │ │ Real-time API │ │ │ EC2 Checks │ │ CT Checks │ │ │ │ └─────────────────┘ │ └──────────────┘ └─────────────────┘ │ │ │ └────────────────────┬─────────────────────┘ │ │ │ │ │ ┌──────────────────────────────────┼──────────────────┐ │ │ ▼ ▼ ▼ │ │ ┌─────────────────┐ ┌─────────────────┐ ┌──────────────────┐ │ │ │ DynamoDB │ │ SNS │ │ CloudWatch │ │ │ │ Findings store │ │ Slack + Email │ │ Dashboard + │ │ │ │ 90-day TTL │ │ Fan-out alerts │ │ Alarms │ │ │ └─────────────────┘ └─────────────────┘ └──────────────────┘ │ │ │ │ ┌───────────────────────────────────────────────────────────────────┐ │ │ │ AWS Config + Security Hub (compliance aggregation) │ │ │ └───────────────────────────────────────────────────────────────────┘ │ │ │ │ ┌───────────────────────────────────────────────────────────────────┐ │ │ │ Terraform + GitHub Actions (IaC + CI/CD) │ │ │ └───────────────────────────────────────────────────────────────────┘ │ └─────────────────────────────────────────────────────────────────────────┘ ``` **流程：** 1. EventBridge 每天 UTC 时间 6:00 触发一次，**或者**在 API 发生变更时，由 CloudTrail 实时事件立即触发 2. Lambda 运行全部四个检查模块 —— IAM、S3、EC2/SG、CloudTrail 3. 每个发现都会被分类为 CRITICAL / HIGH / MEDIUM / LOW，并附带资源 ARN 和修复建议 4. 所有发现保存至 DynamoDB（批量写入，90 天 TTL 自动过期） 5. 发布自定义 CloudWatch 指标 —— `FindingsBySeverity`、`TotalFindings` 6. 如果发现 CRITICAL 或 HIGH 级别的问题：SNS 将发布电子邮件，同时 Lambda 发布 Slack 消息 7. 如果 `CRITICAL > 0`，则触发 CloudWatch 告警 8. Dashboard 更新 —— 实时可见安全态势趋势 ## ☁️ 使用的 AWS 服务及原因

AWS Lambda — 用于扫描器的 serverless 计算服务

**为什么选择 Lambda 而不是 EC2？** 扫描器每天只需运行一次，耗时 2-5 分钟。如果使用 EC2 实例，在两次扫描的空闲期间每月将花费 8-30 美元，此外还需要进行操作系统补丁修补、SSH 加固以及实例管理。而 Lambda 仅按实际执行时间收费 —— 在免费额度下，每天扫描的每月总成本不到 0.01 美元。 **为什么不使用 ECS/Fargate？** ECS 专为长期运行的容器化工作负载而设计。对于像定期安全扫描这样事件驱动、耗时短的任务，Lambda 才是正确的选择。 **配置：** Python 3.11 runtime · 256 MB 内存 · 300 秒超时

Amazon EventBridge — 调度与实时触发

**在本项目中的两个作用：** 1. **定时触发** —— 通过 `cron(0 6 * * ? *)` 每天 UTC 时间 6:00 触发扫描器 2. **实时触发** —— 当 CloudTrail 检测到高风险 API 事件（例如，有人创建了 S3 存储桶或修改了安全组）时立即触发 **为什么不使用 CloudWatch Events？** CloudWatch Events 是同一服务的旧名称 —— EventBridge 是当前正在积极开发并具有附加功能的版本。新项目请始终使用 EventBridge。

Amazon DynamoDB — 带有历史记录的发现存储

**为什么选择 DynamoDB 而不是 RDS？** RDS 需要 VPC、子网、一个始终保持运行的实例，并且每月至少花费 15-50 美元。而采用 `PAY_PER_REQUEST` 计费模式的 DynamoDB 在此工作负载下每月只需花费几美分。它还具有原生的 TTL 支持 —— 发现记录会在 90 天后自动过期，零维护成本。 **Schema：** `finding_id`（partition key）+ `timestamp`（sort key）—— 支持按扫描 ID 或时间范围高效检索发现结果。

Amazon SNS — 告警信息向多渠道分发

**为什么使用 SNS，而不是直接从 Lambda 发送通知？** SNS 将扫描器与通知渠道解耦。只需添加一个 SNS 订阅即可接入新渠道（PagerDuty、Microsoft Teams、SMS、SQS 队列）—— 无需修改任何代码。SNS 还会自动处理电子邮件订阅确认、重试逻辑和送达保证。

Amazon CloudWatch — 指标、Dashboard 和告警

**三个作用：** 1. **日志** —— Lambda 自动将所有输出流式传输到 CloudWatch Logs。每一次检查结果、每一个错误均可搜索并保留。 2. **自定义指标** —— 每次扫描后，Lambda 会将 `FindingsBySeverity`（按 CRITICAL/HIGH/MEDIUM/LOW 划分）和 `TotalFindings` 发布到 `CSPM/SecurityFindings` 命名空间。 3. **Dashboard + 告警** —— 实时图表展示发现趋势。只要 `CRITICAL > 0`，告警就会触发，并立即触发 SNS。 **为什么不使用 Datadog/Grafana？** 两者都非常出色，但需要额外付费，并且需要注册额外的账号/安装代理。CloudWatch 是原生的、零设置的，并且对于本项目生成的指标量来说是免费的。

AWS CloudTrail — API 审计与实时事件源

**两个作用：** 1. **合规检查目标** —— 扫描器会检查 CloudTrail 本身的配置是否正确（是否启用了多区域、是否开启了日志文件验证、是否启用了 KMS 加密）。配置错误的 CloudTrail 属于 CRITICAL 发现，因为这意味着无法检测或调查数据泄露。 2. **实时事件源** —— CloudTrail 近乎实时地将 API 事件发送到 EventBridge，使扫描器能够在资源配置错误后的几秒钟内做出反应。

AWS Config + Security Hub — 聚合与合规历史记录

**AWS Config** 维护着每个资源的配置历史记录 —— 这对于检测两次扫描之间的配置漂移以及进行合规报告非常有用（“上周此资源是否符合合规要求？”）。 **Security Hub** 将来自 Lambda、GuardDuty、Inspector 和 Config 的发现聚合到一个集中的 Dashboard 中 —— 这是企业安全运营中的标准做法。

Amazon S3 + Athena — 长期审计日志存储

CloudTrail 将完整的 API 日志文件传输到 S3。结合 Athena（serverless SQL），您可以使用标准 SQL 查询数月的 API 历史记录 —— 无需管理数据库，也无需进行预置。 ``` SELECT eventName, userIdentity.arn, eventTime FROM cloudtrail_logs WHERE eventName = 'DeleteBucket' AND eventTime > '2024-01-01' ORDER BY eventTime DESC; ```

## 🔐 安全检查 (CIS Benchmark) ### IAM — Identity & Access Management | 检查 ID | 控制 | 严重性 | 重要性说明 | |---|---|---|---| | CIS-1.5 | Root 账户未启用 MFA | 🔴 CRITICAL | Root 账户拥有无限权限 —— 一个泄露的密码 = 账户被完全接管 | | CIS-1.12 | 凭证 90 天未使用 | 🟠 HIGH | 闲置密钥是持续的攻击面；攻击者会在泄露发生数月后利用它们 | | CIS-1.14 | 访问密钥超过 90 天 | 🟡 MEDIUM | 旧密钥可能已被默默窃取；轮换可以限制影响范围 | | CIS-1.8–1.11 | 密码策略薄弱 | 🟡 MEDIUM | 薄弱的策略容易引发暴力破解和撞库攻击 | | CIS-1.16 | 用户配置了 Inline IAM policies | 🔵 LOW | Inline policies 比基于组/角色的策略更难审计和管理 | ### S3 — Simple Storage Service | 检查 ID | 控制 | 严重性 | 重要性说明 | |---|---|---|---| | CIS-2.1.5 | 未启用 Block Public Access | 🔴 CRITICAL | 公开的 S3 存储桶是云数据泄露最常见的原因 | | CIS-2.1.1 | 未设置默认加密 | 🟠 HIGH | 静态数据明文存储违反了大多数合规框架 | | CIS-2.1.3 | 未启用 Versioning | 🟡 MEDIUM | 没有版本控制，勒索软件或意外删除将永久销毁数据 | | CIS-2.1.2 | 未开启访问日志 | 🔵 LOW | 没有日志 = 无法审计谁访问了什么数据 | ### EC2 / 安全组 | 检查 ID | 控制 | 严重性 | 重要性说明 | |---|---|---|---| | CIS-5.2 | SSH (端口 22) 对 0.0.0.0/0 开放 | 🔴 CRITICAL | 暴露服务器全天候接受来自整个互联网的暴力破解 | | CIS-5.2 | RDP (端口 3389) 对 0.0.0.0/0 开放 | 🔴 CRITICAL | RDP 是互联网上被最积极利用的协议之一 | | CIS-5.2 | 数据库端口向互联网开放 | 🟠 HIGH | 数据库永远不应直接被互联网访问 | | CIS-2.2.1 | 默认未开启 EBS 加密 | 🟠 HIGH | 如果不设置此项，任何开发人员创建的新卷都将是未加密的 | | CSPM-EC2-001 | 启用了 IMDSv1 (存在 SSRF 风险) | 🟠 HIGH | IMDSv1 允许 SSRF 攻击通过 metadata endpoint 窃取 EC2 实例凭证 | ### CloudTrail — 审计日志 检查 ID | 控制 | 严重性 | 重要性说明 | |---|---|---|---| | CIS-3.1 | 未配置 CloudTrail 或非多区域 | 🔴 CRITICAL | 没有 CloudTrail 就没有审计跟踪 —— 数据泄露将完全隐形 | | CIS-3.2 | 未启用日志文件验证 | 🟡 MEDIUM | 具有 S3 访问权限的攻击者可以删除或修改日志以掩盖其踪迹 | | CIS-3.7 | 日志未进行 KMS 加密 | 🟡 MEDIUM | 任何有权访问 S3 存储桶的人都可以读取未加密的日志 | ## 🛠️ 技术栈 ### Infrastructure as Code — Terraform **为什么选择 Terraform 而不是其他替代方案？** | 工具 | 结论 | |---|---| | **CloudFormation** | 仅支持 AWS，冗长的 YAML/JSON，错误提示无帮助 | | **CDK** | 最终合成为 CloudFormation —— 继承了它的所有限制 | | **手动控制台配置** | 配置漂移，无版本历史记录，不可重复 | | **Terraform ✅** | 简洁的 HCL，云供应商无关，快速的 plan-apply，可通过 Git 追踪 | ### Python 3.11 **为什么使用 Python 3.11？** - 最成熟的 AWS SDK (Boto3) 是 Python 原生的 - 安全工具生态系统 (ScoutSuite, Prowler, Pacu) 全都是基于 Python 的 - 比 Python 3.9 快 10-60%（对于 5 分钟的超时预算来说意义重大） - 最新的 Lambda 支持的 runtime ### 库 | 库 | 用途 | 选择原因 | |---|---|---| | `boto3` | AWS SDK — 处理所有 API 调用 | Python 唯一真正的选择。官方发布，API 覆盖全面 | | `pytest` | 单元测试框架 | 行业标准。比 `unittest` 更整洁。CI 通用支持 | | `moto` | 用于测试的 AWS API 模拟 | 拦截 boto3 调用 —— 测试在几毫秒内运行，无需真实的 AWS 账户 | | `black` | 代码格式化工具 | 零配置。在公开仓库中保持一致的风格体现了专业精神 | ## 📁 项目结构 ``` aws-cloud-security-posture-monitor/ │ ├── lambda/ │ ├── scanner/ │ │ ├── main.py # Lambda handler — orchestrates all checks │ │ ├── alerting.py # SNS publish + Slack webhook │ │ ├── storage.py # DynamoDB batch write │ │ └── checks/ │ │ ├── iam_checks.py # 5 CIS IAM controls │ │ ├── s3_checks.py # 4 CIS S3 controls │ │ ├── ec2_checks.py # 5 EC2/Security Group controls │ │ └── cloudtrail_checks.py # 3 CIS CloudTrail controls │ └── requirements.txt │ ├── terraform/ │ ├── main.tf # Provider config, backend │ ├── variables.tf # All input variables │ ├── outputs.tf # Dashboard URL, Lambda ARN │ ├── iam.tf # Least-privilege Lambda execution role │ ├── lambda.tf # Function resource + ZIP packaging │ ├── eventbridge.tf # Daily cron schedule + CloudTrail target │ ├── dynamodb.tf # Findings table, TTL, encryption │ ├── sns.tf # Alert topic + email subscription │ └── cloudwatch.tf # Dashboard + CRITICAL findings alarm │ ├── tests/ │ ├── test_iam_checks.py │ ├── test_s3_checks.py │ └── test_ec2_checks.py │ ├── .github/ │ └── workflows/ │ └── deploy.yml # Test on PR, deploy on merge to main │ ├── Makefile # make install / test / deploy / invoke / logs ├── .gitignore └── README.md ``` ## 🚀 5 分钟内完成部署 ### 前置条件 - 配置好 CLI 的 AWS 账户 (`aws configure`) - Terraform >= 1.5 ([安装](https://developer.hashicorp.com/terraform/downloads)) - Python 3.11 - 一个 Slack webhook URL ([创建一个](https://api.slack.com/messaging/webhooks)) ### 第 1 步 — 克隆并设置 ``` git clone https://github.com/YOUR_USERNAME/aws-cloud-security-posture-monitor.git cd aws-cloud-security-posture-monitor # 创建 virtual environment python -m venv venv source venv/bin/activate # Windows: venv\Scripts\activate # 安装 dependencies pip install boto3 pytest moto black ``` ### 第 2 步 — 首先运行测试（不需要 AWS 账户） ``` pytest tests/ -v ``` 所有测试都使用 `moto` 来模拟 AWS —— 它们完全在内存中运行。 ### 第 3 步 — 部署到 AWS ``` cd terraform terraform init # 预览将要创建的内容 terraform plan \ -var="slack_webhook_url=https://hooks.slack.com/YOUR_WEBHOOK" \ -var="alert_email=you@email.com" # 部署所有内容 terraform apply \ -var="slack_webhook_url=https://hooks.slack.com/YOUR_WEBHOOK" \ -var="alert_email=you@email.com" ``` Terraform 会在 2 分钟内创建约 12 个 AWS 资源。 ### 第 4 步 — 立即运行您的首次扫描 ``` aws lambda invoke \ --function-name cspm-scanner \ --payload '{}' \ --cli-binary-format raw-in-base64-out \ /tmp/result.json cat /tmp/result.json | python -m json.tool ``` ### 第 5 步 — 在 DynamoDB 中查看发现结果 ``` aws dynamodb scan \ --table-name cspm-findings \ --query 'Items[*].{severity:severity.S, check:check_id.S, resource:resource.S}' \ --output table ``` ### 第 6 步 — 查看 CloudWatch Dashboard ``` # 从 Terraform outputs 获取 dashboard URL terraform output dashboard_url ``` ### 销毁环境 (无遗留资源，无意外账单) ``` cd terraform && terraform destroy ``` ## 📊 真实测试结果 测试是针对一个故意配置错误的 AWS 账户，使用蓄意漏洞的方法进行的： ``` # 引入的 vulnerabilities aws s3api delete-public-access-block --bucket test-bucket aws ec2 authorize-security-group-ingress --group-name test-sg \ --protocol tcp --port 22 --cidr 0.0.0.0/0 aws cloudtrail update-trail --name test-trail \ --no-enable-log-file-validation ``` ### 扫描 1 — 修复前 | 严重性 | 数量 | 关键发现 | |---|---|---| | 🔴 CRITICAL | 4 | Root 账户 MFA 禁用 · SSH 对互联网开放 · S3 公开 · 无 CloudTrail | | 🟠 HIGH | 6 | 3 个过期的访问密钥 · EBS 加密关闭 · 2 个未加密的 S3 存储桶 | | 🟡 MEDIUM | 8 | 密码策略薄弱 · CT 日志验证关闭 · 未启用 Versioning | | 🔵 LOW | 3 | Inline IAM policies · S3 日志记录禁用 | ### 扫描 2 — 修复后 | 严重性 | 数量 | 备注 | |---|---|---| | 🔴 CRITICAL | 0 | 所有关键问题已解决 | | 🟠 HIGH | 0 | 所有高危问题已解决 | | 🟡 MEDIUM | 1 | CloudTrail KMS 加密仍在处理中 | | 🔵 LOW | 2 | 次要日志记录配置 | ## 🧪 运行测试 测试使用 `moto` 来模拟所有的 AWS API 调用 —— 不需要真实的 AWS 账户或凭证： ``` # 运行所有 tests pytest tests/ -v # 运行特定的 module pytest tests/test_iam_checks.py -v # 在 coverage 下运行 pytest tests/ --cov=lambda/scanner --cov-report=term-missing ``` **测试输出示例：** ``` tests/test_iam_checks.py::test_root_mfa_fails_when_not_enabled PASSED tests/test_iam_checks.py::test_password_policy_fails_with_no_policy PASSED tests/test_iam_checks.py::test_password_policy_passes_when_strong PASSED tests/test_s3_checks.py::test_public_bucket_detected PASSED tests/test_s3_checks.py::test_encryption_missing_detected PASSED tests/test_ec2_checks.py::test_open_ssh_detected PASSED tests/test_ec2_checks.py::test_open_rdp_detected PASSED 7 passed in 1.24s ``` ## ⚙️ CI/CD Pipeline 每次推送到 `main` 分支都会运行测试，并通过 GitHub Actions 自动部署： ``` Pull Request → pytest tests/ → review → merge Merge to main → pytest tests/ → terraform apply → live ``` 在 `Settings → Secrets and variables → Actions` 下 **设置 GitHub Secrets**： | Secret | 值 | |---|---| | `AWS_ACCESS_KEY_ID` | 您的 IAM 用户访问密钥 | | `AWS_SECRET_ACCESS_KEY` | 您的 IAM 用户密钥 | | `SLACK_WEBHOOK_URL` | 您的 Slack webhook URL | | `ALERT_EMAIL` | 用于接收 SNS 告警的电子邮件 | ## 💰 成本明细 本项目旨在 AWS 免费额度下以接近零成本运行： | 服务 | 使用量 | 每月成本 | |---|---|---| | AWS Lambda | 每月 30 次调用 × 5 分钟 × 256 MB | ~$0.00 (免费额度) | | DynamoDB | 每月约 600 次写入, PAY_PER_REQUEST | ~$0.00 (免费额度) | | EventBridge | 每月 30 个定时事件 | ~$0.00 (免费额度) | | SNS | 每月 <1000 条通知 | ~$0.00 (免费额度) | | CloudWatch | 自定义指标 + Dashboard | ~$3.00 (1 个 Dashboard) | | CloudTrail | 管理事件 | ~$0.00 (第一条 trail 免费) | | S3 | CloudTrail 日志存储 | ~$0.01 | | **总计** | | **~$3.01/月** | ## 🗺️ 路线图 - [ ] **多账户扫描** — 跨 AWS Organizations assume IAM roles，从一个中央 Lambda 扫描所有账户 - [ ] **自动修复** — 自动修复 LOW 严重性级别的发现（启用 S3 Versioning、默认启用 EBS 加密等） - [ ] **Azure 模块** — 相同的框架，使用 Azure Python SDK 实现跨云 CSPM 覆盖 - [ ] **Streamlit Dashboard** — 部署在 ECS Fargate 上的可视化发现 UI - [ ] **合规 PDF 报告** — 每次扫描后自动生成格式化的 CIS 合规报告 - [ ] **Slack 斜杠命令** — `/scan` 直接从 Slack 触发按需扫描 - [ ] **JIRA 集成** — 为 CRITICAL 发现自动创建 JIRA 工单，并预填修复建议 - [ ] **ML 异常检测** — 使用基线学习标记异常的 IAM 权限模式 ## 🤝 贡献指南 欢迎贡献代码。如果要添加新的安全检查： 1. Fork 仓库并创建分支：`git checkout -b check/new-control-name` 2. 将您的检查函数添加到 `lambda/scanner/checks/` 中的相应模块 3. 遵循现有的发现 schema —— `check_id`、`title`、`severity`、`resource`、`resource_type`、`description`、`remediation` 4. 在 `tests/` 中使用 `moto` 模拟添加单元测试 5. 提交一个 Pull Request，描述它所解决的 CIS 控制或安全隐患 ## 📄 License MIT License — 可免费使用、Fork 和扩展。

标签：ATTACK-Python-Client, AWS, CIS Benchmark, DPI, ECS, Python, Serverless, Terraform, 安全态势管理, 无后门, 逆向工具