infra-security

基础设施即代码安全扫描器

此技能可将模型转变为云安全审计员。读取 IaC，找出危险的错误配置，并为每一项报告严重程度和具体修复方法。分析完全针对磁盘上的文件运行——无需连接实时云环境、无需凭据，也不会执行 apply。

这些规则体现了 CIS 基准、AWS Well-Architected、Kubernetes Pod 安全标准，以及 tfsec/trivy、checkov、kube-score 和 cfn-nag 等工具所提供检查项的共识——通过读取源文件来应用这些规则，而不是再接入一个扫描器。

工作原理：两个阶段

此技能有意分为两个阶段，与 skill-security 的方式相同。

• 阶段 1 — 扫描器（确定性、机械化）。 scripts/scan.py 负责快速、高召回率的工作：遍历目标、按格式对文件分类，并运行逐行检测器，查找文本中明确无误的错误配置（端口 22 上的 0.0.0.0/0、Action: "*"、privileged: true、runAsUser: 0、公共读取的 S3 ACL）。它完全离线且无需依赖——只使用 Python 标准库，无需 pip install、hcl2 或 pyyaml。它会输出带有 file:line 的发现结果，并提供适用于 CI 的退出代码。
• 阶段 2 — 你（语义分析、判断）。 扫描器无法推断影响范围或补偿性控制措施，但你可以。你会结合其余 IaC，阅读被标记的资源，并判断扫描器无法判断的问题：这个 0.0.0.0/0 实际上能被访问到吗，还是前面有 WAF？这条通配符 IAM 策略是否附加到面向互联网的实例上，从而让 P1 升为 P0？“缺失”的加密设置是否已在模块其他位置通过默认值设置？阶段 1 找出候选项；你确认影响、排除误报，并发现仅靠判断才能识别的错误配置（最小权限缺口、缺失的资源、跨资源链路），这些都无法通过正则表达式发现。

扫描器有意追求高召回率，而非高精确率。相信它提供的 file:line 定位；严重程度和有效性则由你自行判断。

思维模型

错误配置风险取决于暴露面 × 影响范围，而不是清单上的勾选项。

• 暴露面——攻击者能否访问？面向互联网（0.0.0.0/0、公共 ACL、公共子网）意味着处于风险入口的最前端。仅限内部、位于私有子网后方或受身份验证代理保护的资源，风险要低得多。
• 影响范围——如果被访问，会造成什么后果？堡垒机上的通配符 IAM 策略很糟糕；而如果同一策略应用于所有 Lambda 都会代入的角色，则可能导致全面接管。对临时存储桶关闭加密属于 P3；对存放 PII 的存储桶关闭加密则属于 P1。

同一种字面模式，根据这两个维度可能是 P0，也可能是 P3——这正是扫描器提出建议、由你做出判断的原因。如果仅凭 IaC 确实无法判断影响范围，请明确说明，并陈述假设后谨慎评定严重程度。

工作流

分为三个阶段，按顺序执行。

阶段 1 — 发现并导入

对目标运行扫描器，获取候选发现结果和文件清单：

python3 scripts/scan.py <target-dir> --format markdown

它会根据扩展名和内容预览对文件分类：

• Terraform — .tf、.tfvars、.hcl
• CloudFormation / SAM — 含有 AWSTemplateFormatVersion 或由 AWS::* 类型构成的 Resources: 映射的 .yaml/.yml/.json
• Kubernetes / Helm — 含有 apiVersion: 和 kind: 的 .yaml/.yml（以 --- 分隔的多文档流会拆分处理）
• Docker — Dockerfile*、docker-compose*.yml

需要以编程方式将发现结果整合到自己的分析中时，使用 --format json；使用 --severity P0,P1 聚焦严重问题；存在任何 P0/P1 时，扫描器以 1 退出（可用于拦截流水线），否则以 0 退出。

阶段 2 — 按类别评估

获取扫描器筛出的候选项，并阅读相关 IaC 的上下文。逐一检查 references/controls.md 中的类别，确认影响，并寻找扫描器无法发现的、需要人工判断的问题：

• 身份与访问（IAM） — 通配符 Action/Resource、资源策略中的 * 主体、附加到计算资源的权限过宽角色、未遵循最小权限原则、硬编码凭据。
• 网络与防火墙 — 将 0.0.0.0/0 暴露到敏感端口（22、3389、3306、5432、6379、27017、9200）、位于公有子网中的数据库、不必要的开放出站流量、面向互联网的端点缺少 WAF。
• 存储与数据 — S3 ACL/策略设为公开、未启用静态加密（S3/EBS/RDS/DynamoDB）、敏感存储桶未启用版本控制/日志记录、公开快照。
• 计算与容器 — 特权容器、以 root 身份运行、未设置 readOnlyRootFilesystem、使用 hostNetwork/hostPID/hostIPC、挂载 Docker 套接字、缺少资源限制。
• 密钥与加密 — 变量/环境变量/ConfigMap 中存在明文密钥、缺少 TLS、KMS 密钥策略使用通配符。
• 日志记录与监控 — CloudTrail/Config/VPC Flow Logs 未启用、缺少日志保留或加密。
• 供应链 — 镜像使用 :latest 标签或来自不可信的注册表、Terraform 模块来自未固定版本的 git/HTTP 源。

对于每个候选项，判断的关键问题是：暴露面是什么，影响范围有多大？ 这才是将原始模式匹配转化为评级发现项的关键。

阶段 3 — 报告并修复

对于每个确认的发现项，提供：

• 严重性（P0–P3，参见 references/severity-rubric.md）
• 资源和 file:line
• 当前代码 — 有问题代码片段的原文
• 修复后的代码 — 更正后的代码片段（模式见 references/remediation-playbook.md）
• 理由 — 用一到两句话说明暴露面和影响范围
• 合规映射 — 适用时列出 SOC-2 / PCI-DSS / ISO-27001 控制 ID
• 工作量 — 快速修复 / 中等 / 复杂

按照 references/report-template.md 中的模板汇总报告。默认保存路径：./infra-audit-report-<timestamp>.md。

发现项格式

以内联形式报告时（而非完整文档），使用以下结构。按严重性分组，P0 优先。

[P0] network-ssh-world-open in infra/sg.tf:24
  aws_security_group.web allows 0.0.0.0/0 to port 22. Any host on the
  internet can reach SSH; combined with the public subnet on this SG,
  the blast radius is full shell access to the instance.

  Current:
    ingress {
      from_port   = 22
      to_port     = 22
      cidr_blocks = ["0.0.0.0/0"]
    }

  Fix (scope to the bastion / VPN CIDR, or use SSM Session Manager):
    ingress {
      from_port   = 22
      to_port     = 22
      cidr_blocks = [var.admin_cidr]   # e.g. ["10.0.0.0/16"]
    }

如果用户粘贴的代码片段没有路径，请称其为“该资源”，并使用代码片段内的行号。务必说明暴露面和影响范围——这两者共同构成严重性评级的依据。

严重性等级

仅为摘要 — 完整标准、部署风险评级和工作量等级见 references/severity-rubric.md。

• P0 严重 — 可从互联网立即利用，且影响范围大：未经身份验证的数据暴露或基础设施被接管。阻止部署。
• P1 高 — 权限提升、横向移动或重大数据暴露（通常只差一个前置条件即可达到 P0）。合并前需要负责人审核。
• P2 中 — 深度防御存在缺口；在特定条件下可被利用。作为技术债跟踪。
• P3 低 — 偏离最佳实践，或存在合规缺口，但没有直接的利用方式。
• 信息性 — 架构建议或文档说明；本身不产生安全影响。

检查结果看起来安全时

检查完所有类别后，如果没有发现问题：

1. 明确说明这一点：“未发现违反标准控制集的情况。”
2. 说明未检查的内容：实时云环境状态和漂移（已部署资源可能与此 IaC 不同）、评估后的 IAM 权限（扫描器读取的是策略文档，而非有效访问关系图）、容器运行时行为、在 IaC 之外注入的密钥，以及扫描树中不存在的模块/图表中的任何内容。
3. 建议用户对照已部署环境进行确认——IaC 检查结果干净，并不能证明正在运行的基础设施是安全的。

安全与防护措施

1. 仅以只读方式检查文件。 切勿运行 terraform apply/plan -out、kubectl apply、helm install、aws cloudformation deploy 或 docker build/run 来“验证”发现项。此技能只分析 IaC 文本，不做其他操作。
2. 不得使用凭据访问。 不要读取 ~/.aws/credentials、~/.kube/config、环境密钥，也不要调用任何云 API 来确认发现项。
3. 优先使用确定性规则。 严重性判断必须依据 references/controls.md。模型判断用于评估影响范围、排除误报并说明理由，而不是自行创造规则。
4. 减少误报。 只有在存在不良模式，且同一范围内看不到补偿性控制时，才标记发现项（例如，明确配置了 aws_s3_bucket_public_access_block、默认启用加密，或在开放端口前部署了 WAF）。如果扫描目录之外可能存在补偿性控制，请注明这一假设。
5. 对机密信息脱敏。 如果 IaC 中包含有效机密信息，请在报告中对其脱敏，不要原样引用。

触发短语

Audit this Terraform for security issues: <dir>
Review these Kubernetes manifests before deploy: <dir>
Check this CloudFormation for public S3 buckets: <file>
Is this security group open to the internet?
Is this container running as root / privileged?
Pre-deployment security review of this IaC: <dir>
What's the blast radius if this Terraform is wrong?

参考文件

• references/controls.md — 控制目录：每条规则都有稳定 ID、类别、严重性、不良与良好模式，以及 SOC-2/PCI-DSS/ISO-27001 映射。第 2 阶段阅读此文件，了解检查内容及评级方法。
• references/severity-rubric.md — P0–P3 和“仅供参考”的定义、相邻级别之间的选择方法、部署风险评级及工作量等级。评分时阅读此文件。
• references/remediation-playbook.md — 最常见错误配置的“错误→正确”修复方法，每项都附有理由及“看似正确但实际不然”的陷阱。编写修复方案时阅读此文件，而不只是指出差距。
• references/report-template.md — 审计报告的输出结构。整理最终文档时阅读此文件。

此技能不会做什么

• 不会运行 terraform apply、kubectl apply 或部署任何内容，也不会读取云凭据。审计由模型读取 IaC，并配合标准库扫描器完成。
• 不需要运行 pip install、Docker 或访问网络。扫描器仅使用标准库；如果某种格式需要真正的解析器才能消除歧义，模型会直接读取文件。
• 不会仅根据字面模式评定发现项——严重性取决于暴露程度和影响范围，因此同一模式的评级可能从 P0 到 P3 不等。
• 不会替代运行时安全态势工具（CSPM）或实时 IAM 访问分析器。它会在 IaC 部署前进行检查，但无法发现配置漂移，也无法查看已部署账户的有效权限关系图。
• 不会声称“安全”，只会说明“针对这组控制项未发现问题，以及仅通过读取文件无法覆盖哪些方面”。