security-audit

安全审计

此技能可让 Agent 对 Web 应用、API、云基础设施和后端服务开展全面的安全审计。Agent 会系统地检查身份验证机制、授权控制、输入验证、加密实践、日志记录配置和部署设置。审计发现会映射到 OWASP Top 10、CWE 标识符以及 SOC 2 和 PCI-DSS 等合规标准。

工作流

1. 收集系统信息 — 收集目标环境的详细信息，包括技术栈、架构图、网络拓扑、部署模型和第三方集成。检查配置文件、环境变量和基础设施即代码模板，以全面了解攻击面。

2. 定义审计范围和合规目标 — 通过确定纳入审计的组件、环境和数据流，明确审计边界。将审计目标映射到相关合规框架，例如 SOC 2 Type II、PCI-DSS、HIPAA 或内部安全策略。根据 OWASP Top 10 和 CWE/SANS Top 25 制定检查清单，确保系统地覆盖各项内容。

3. 执行自动化漏洞扫描 — 使用自动化扫描器扫描目标，以识别已知漏洞。使用 OWASP ZAP 扫描 Web 应用，使用 Trivy 或 Grype 扫描容器镜像，使用 ScoutSuite 或 Prowler 扫描云基础设施。汇总原始发现，供人工审查。

4. 开展人工安全审查 — 人工检查身份验证流程、会话管理、基于角色的访问控制、输入清理例程、密码学实现、错误处理和日志记录实践。检查源代码中的硬编码密钥、不安全反序列化和自动化工具经常遗漏的业务逻辑缺陷。

5. 分析并分类审计发现 — 使用 CVSS 评分评估每项发现的严重程度（严重、高、中、低、信息性）。分配 CWE 标识符，并将发现映射到相关的 OWASP Top 10 类别。评估可利用性、影响范围和业务影响，以确定风险优先级。

6. 生成包含修复计划的审计报告 — 生成结构化报告，包含执行摘要、附有证据和复现步骤的详细发现、风险评级，以及具体的修复建议和预估工作量。通过合规差距分析，展示目标框架各项控制措施的通过/未通过状态。

支持的技术

• Web 框架：Express.js、Django、Flask、Spring Boot、Rails、ASP.NET
• 云平台：AWS（IAM、S3、EC2、RDS、Lambda）、GCP、Azure
• 容器与编排：Docker、Kubernetes、ECS
• 扫描工具：OWASP ZAP、Prowler、ScoutSuite、Trivy、Grype、Checkov
• 合规框架：OWASP Top 10、CWE/SANS Top 25、SOC 2、PCI-DSS、HIPAA、NIST 800-53

用法

向 Agent 提供应用源代码、基础设施配置或目标 URL 的访问权限，并说明所需的合规范围。Agent 将执行完整的审计工作流，并提交按优先级排列的发现报告。

提示词示例：

Perform a security audit of the Node.js Express application in /app. Focus on OWASP Top 10 coverage and SOC 2 compliance. Include CWE IDs and remediation steps for every finding.

示例

示例 1：审计 Node.js Express 应用

目标：使用 Express.js、Sequelize ORM 和 JWT 身份验证构建的电商 API。

发现报告（摘录）：

#	严重程度	标题	CWE	OWASP 类别
1	严重	商品搜索端点存在 SQL 注入	CWE-89	A03:2021 注入
2	高	JWT 密钥以明文形式存储在已提交到代码库的 .env 文件中	CWE-798	A07:2021 身份识别和身份验证失败
3	高	/api/login 未设置速率限制	CWE-307	A07:2021 身份识别和身份验证失败
4	中	详细的错误消息在生产环境中暴露堆栈跟踪	CWE-209	A04:2021 不安全设计
5	中	CORS 策略允许使用通配符源并携带凭据	CWE-942	A05:2021 安全配置错误
6	低	缺少 HTTP 安全标头（X-Content-Type-Options、CSP）	CWE-693	A05:2021 安全配置错误

发现 #1 的修复措施：

// BEFORE — vulnerable to SQL injection
app.get('/api/products', async (req, res) => {
  const results = await sequelize.query(
    `SELECT * FROM products WHERE name LIKE '%${req.query.search}%'`
  );
  res.json(results);
});

// AFTER — parameterized query
app.get('/api/products', async (req, res) => {
  const results = await sequelize.query(
    'SELECT * FROM products WHERE name LIKE :search',
    { replacements: { search: `%${req.query.search}%` }, type: QueryTypes.SELECT }
  );
  res.json(results);
});

示例 2：审计 AWS 基础设施

目标：运行三层 Web 应用的生产 AWS 账户。

Prowler 扫描命令：

prowler aws --compliance soc2 pci_dss --output-formats json html --output-directory ./audit-report

发现报告（摘录）：

#	严重程度	发现	AWS 服务	合规控制项
1	严重	S3 存储桶 prod-user-uploads 已启用公共读取访问	S3	PCI-DSS 7.1，SOC 2 CC6.1
2	高	IAM 用户 deploy-bot 拥有内联 AdministratorAccess 策略	IAM	SOC 2 CC6.3
3	高	RDS 实例 prod-db 未启用静态加密	RDS	PCI-DSS 3.4，SOC 2 CC6.1
4	中	并非所有区域都启用了 CloudTrail 日志记录	CloudTrail	SOC 2 CC7.2
5	中	安全组 sg-0abc123 允许来自 0.0.0.0/0 的 SSH（端口 22）访问	EC2	PCI-DSS 1.3

发现 #2 的修复措施：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["ecr:GetAuthorizationToken", "ecs:UpdateService", "ecs:DescribeServices"],
      "Resource": "arn:aws:ecs:us-east-1:123456789012:service/prod-cluster/web-service"
    }
  ]
}

最佳实践

• 按计划定期审计 — 至少每季度执行一次审计，并在每次重大版本发布或基础设施变更后执行，而不应只在每年审计一次。
• 结合自动化测试和人工测试 — 自动化扫描器可以发现已知的漏洞模式，但对于业务逻辑缺陷、授权绕过和组合攻击场景，人工审查必不可少。
• 统一使用 CWE 和 CVSS — 为每项发现分配 CWE 标识符和 CVSS 评分，以便利益相关方比较不同审计的严重程度并跟踪修复趋势。
• 通过重新测试验证修复效果 — 部署修复后，重新运行相关审计检查，以确认漏洞已解决且未引入回归问题。
• 保留审计跟踪记录 — 将所有审计报告、证据和修复记录存储在集中式代码库中，以支持合规性审查和事件调查。
• 将第三方集成纳入审计范围 — 支付网关、OAuth 提供商和 SaaS API 都会带来风险；如果只审计自有代码，这些风险很容易被忽略。

安全边界

• 仅对用户拥有或明确授权评估的系统开展工作，并在测试前记录获批范围。
• 从被动或只读检查开始。进行主动扫描、利用漏洞、生成负载或实施会造成干扰的修复之前，必须获得明确批准。
• 切勿暴露机密、提取无关数据、削弱生产控制措施，或超出获批目标范围。
• 保留证据、尽量减少影响、在系统不稳定时停止操作，并为每项重大变更提供回滚或遏制步骤。

边缘情况

• 安全态势不一致的微服务 — 一个服务可能强制要求身份验证，而另一个内部服务则信任所有流量。审计服务间通信，并确认即使在专用网络内也遵循零信任原则。
• 无法访问源代码的遗留系统 — 如果无法获取源代码，请依靠黑盒测试、流量分析和配置审查。务必在审计报告中明确记录覆盖范围有所缩减。
• 无服务器和事件驱动架构 — Lambda 函数、Step Functions 和事件触发器具有短暂的执行上下文。审计 IAM 执行角色和事件源权限，并确保不会以明文形式将敏感数据记录到 CloudWatch。
• 多租户应用程序 — 验证租户隔离是否在数据层、API 层和基础设施层得到强制实施。测试不同租户账户之间是否存在水平权限提升。
• 位于 WAF 或 CDN 后的应用程序 — 自动化扫描器可能只会测试经过 WAF 过滤的攻击面。在条件允许时，也应直接测试源站，以发现被 WAF 掩盖而非修复的漏洞。