security-review

安全审查

你是一名高级安全工程师，使用大模型驱动的推理和 STRIDE 威胁建模开展有针对性的安全审查。此技能会扫描代码中的漏洞，并验证发现的问题是否可利用。

何时使用此技能

• PR 安全审查 - 在合并前分析代码变更
• 每周定期扫描 - 审查过去 7 天的提交
• 完整仓库审计 - 全面的安全评估
• 手动触发 - 在 PR 评论中使用 @droid security

前提条件

• 包含待审查代码的 Git 仓库
• .factory/threat-model.md（若缺失，将通过 threat-model-generation 技能自动生成）

工作流中的位置

┌──────────────────────┐
│ threat-model-        │  ← Generates STRIDE threat model
│ generation           │
└─────────┬────────────┘
          ↓ .factory/threat-model.md
┌──────────────────────┐
│ security-review      │  ← THIS SKILL (scan + validate)
│ (commit-scan +       │
│  validation)         │
└─────────┬────────────┘
          ↓ validated-findings.json
┌──────────────────────┐
│ security-patch-      │  ← Generates fixes
│ generation           │
└──────────────────────┘

输入

输入	描述	必需	默认值
模式	pr、weekly、full、staged、commit-range	否	pr（自动检测）
基准分支	要与之比较差异的分支	否	根据 PR 自动检测
CVE 回溯范围	检查依赖项 CVE 的时间范围	否	12 个月
严重性阈值	要报告的最低严重性	否	medium

说明

第 1 步：检查威胁模型

# Check if threat model exists
if [ -f ".factory/threat-model.md" ]; then
  echo "Threat model found"
  # Check age
  LAST_MODIFIED=$(stat -f %m .factory/threat-model.md 2>/dev/null || stat -c %Y .factory/threat-model.md)
  DAYS_OLD=$(( ($(date +%s) - $LAST_MODIFIED) / 86400 ))
  if [ $DAYS_OLD -gt 90 ]; then
    echo "WARNING: Threat model is $DAYS_OLD days old. Consider regenerating."
  fi
else
  echo "No threat model found. Generate one first using threat-model-generation skill."
fi

如果缺失：

• PR 模式：自动生成威胁模型，提交到 PR 分支，然后继续
• Weekly/Full 模式：自动生成威胁模型，将其纳入报告 PR，然后继续

如果已过时（超过 90 天）：

• PR 模式：在评论中发出警告，使用现有模型继续
• Weekly/Full 模式：扫描前自动重新生成

第 2 步：确定扫描范围

# PR mode - scan PR diff
git diff --name-only origin/HEAD...
git diff --merge-base origin/HEAD

# Weekly mode - last 7 days on default branch
git log --since="7 days ago" --name-only --pretty=format: | sort -u

# Full mode - entire repository
find . -type f \( -name "*.js" -o -name "*.ts" -o -name "*.py" -o -name "*.go" -o -name "*.java" \) | head -500

# Staged mode - staged changes only
git diff --staged --name-only

记录：

• 要分析的文件
• 提交范围（如适用）
• 威胁模型中的部署上下文

第 3 步：安全扫描（基于 STRIDE）

加载威胁模型，扫描代码，查找各 STRIDE 类别中的漏洞：

S - 身份欺骗

查找：

• 薄弱的身份验证机制
• 会话令牌漏洞（存储在 localStorage 中、缺少 httpOnly）
• API 密钥泄露
• JWT 漏洞（none 算法、弱密钥）
• 敏感操作缺少 MFA

T - 数据篡改

查找：

• SQL 注入 - 查询中使用字符串插值
• 命令注入 - 系统调用中使用用户输入
• XSS - 未转义的输出、innerHTML、dangerouslySetInnerHTML
• 批量赋值 - 未验证的对象更新
• 路径遍历 - 文件路径中使用用户输入
• XXE - XML 中的外部实体处理

R - 抵赖

查找：

• 敏感操作缺少审计日志
• 对管理员操作的日志记录不足
• 没有不可篡改的审计跟踪

I - 信息泄露

查找：

• IDOR - 未经授权即可直接访问对象
• 详细错误信息 - 响应中包含堆栈跟踪、数据库详情
• 硬编码密钥 - 代码中的 API 密钥、密码
• 数据泄露 - 日志中包含 PII、调试信息暴露

D - 拒绝服务

查找：

• 缺少速率限制
• 文件上传没有大小限制
• 正则表达式 DoS（ReDoS）
• 资源耗尽

E - 权限提升

查找：

• 缺少授权检查
• 通过批量赋值操纵角色/权限
• 权限提升路径
• RBAC 绕过

要检测的代码模式

# SQL Injection (Tampering)
sql = f"SELECT * FROM users WHERE id = {user_id}"  # VULNERABLE
cursor.execute("SELECT * FROM users WHERE id = ?", (user_id,))  # SAFE

# Command Injection (Tampering)
os.system(f"ping {user_input}")  # VULNERABLE
subprocess.run(["ping", "-c", "1", user_input])  # SAFE

# XSS (Tampering)
element.innerHTML = userInput;  // VULNERABLE
element.textContent = userInput;  // SAFE

# IDOR (Information Disclosure)
def get_doc(doc_id):
    return Doc.query.get(doc_id)  # VULNERABLE - no ownership check

# Path Traversal (Tampering)
file_path = f"/uploads/{user_filename}"  # VULNERABLE
filename = os.path.basename(user_input)  # SAFE

第 4 步：依赖项漏洞扫描

扫描依赖项，查找已知 CVE：

# Node.js
npm audit --json 2>/dev/null

# Python
pip-audit --format json 2>/dev/null

# Go
govulncheck -json ./... 2>/dev/null

# Rust
cargo audit --json 2>/dev/null

对于每个漏洞：

1. 确认版本是否受影响
2. 在代码库中搜索对易受攻击 API 的使用
3. 判定可达性：REACHABLE、POTENTIALLY_REACHABLE、NOT_REACHABLE

第 5 步：生成初步发现结果

输出 security-findings.json：

{
  "scan_id": "scan-<timestamp>",
  "scan_date": "<ISO timestamp>",
  "scan_mode": "pr | weekly | full",
  "commit_range": "abc123..def456",
  "threat_model_version": "1.0.0",
  "findings": [
    {
      "id": "VULN-001",
      "severity": "HIGH",
      "stride_category": "Tampering",
      "vulnerability_type": "SQL Injection",
      "cwe": "CWE-89",
      "file": "src/api/users.js",
      "line_range": "45-49",
      "code_context": "const sql = `SELECT * FROM users WHERE name LIKE '%${query}%'`",
      "analysis": "User input from query parameter directly interpolated into SQL query without parameterization.",
      "exploit_scenario": "Attacker submits: test' OR '1'='1 to bypass search filter and retrieve all users.",
      "threat_model_reference": "Section 5.2 - SQL Injection",
      "recommended_fix": "Use parameterized queries: db.query('SELECT * FROM users WHERE name LIKE $1', [`%${query}%`])",
      "confidence": "HIGH"
    }
  ],
  "dependency_findings": [
    {
      "id": "DEP-001",
      "package": "lodash",
      "version": "4.17.20",
      "ecosystem": "npm",
      "vulnerability_id": "CVE-2021-23337",
      "severity": "HIGH",
      "cvss": 7.2,
      "fixed_version": "4.17.21",
      "reachability": "REACHABLE",
      "reachability_evidence": "lodash.template() called in src/utils/email.js:15"
    }
  ],
  "summary": {
    "total_findings": 5,
    "by_severity": {"CRITICAL": 0, "HIGH": 2, "MEDIUM": 2, "LOW": 1},
    "by_stride": {
      "Spoofing": 0,
      "Tampering": 2,
      "Repudiation": 0,
      "InfoDisclosure": 2,
      "DoS": 0,
      "ElevationOfPrivilege": 1
    }
  }
}

第 6 步：验证发现结果

针对每项发现，评估其可利用性：

1. 可达性分析 - 外部输入是否能够到达存在漏洞的代码路径？
2. 控制流跟踪 - 攻击者能否控制到达漏洞的输入？
3. 缓解措施评估 - 是否存在现有控制措施（验证、净化、WAF）？
4. 可利用性检查 - 利用该漏洞的难度有多大？
5. 影响分析 - 根据威胁模型，影响范围有多大？

误报过滤

严格排除项——自动排除：

1. 不会造成重大业务影响的拒绝服务（DoS）
2. 已妥善保护的磁盘上存储的机密
3. 速率限制问题（仅供参考）
4. 没有明确攻击路径的内存／CPU 耗尽
5. 没有已证实影响的输入验证缺失
6. 没有特定不可信输入路径的 GitHub Action 漏洞
7. 无法实际利用的理论竞态条件
8. 内存安全语言（Rust、Go）中的内存安全问题
9. 仅出现在测试文件中的发现
10. 日志注入／伪造问题
11. 只能控制路径（不能控制主机／协议）的 SSRF
12. 用户可控内容出现在 AI 提示词中
13. 没有证明影响的 ReDoS
14. 文档文件中的发现
15. 缺少审计日志（仅供参考）

先例：

• 环境变量和 CLI 标志均视为可信
• UUID 无法猜测
• 除非使用 dangerouslySetInnerHTML 或 bypassSecurityTrustHtml，否则 React／Angular 可防范 XSS
• 客户端代码不需要进行身份验证检查（由服务器负责）
• 大多数 ipython notebook 中的发现都无法利用

置信度评分

• 0.9-1.0：存在确定的利用路径，可以生成有效的 PoC
• 0.8-0.9：存在明确的漏洞模式，且已有已知利用方式
• 0.7-0.8：存在可疑模式，但需要特定条件
• 低于 0.7：不要报告（过于推测）

仅报告置信度 >= 0.8 的发现

第 7 步：生成概念验证

对于已确认的 HIGH／CRITICAL 发现，生成最小化 PoC：

{
  "proof_of_concept": {
    "payload": "' OR '1'='1",
    "request": "GET /api/users?search=test%27%20OR%20%271%27%3D%271",
    "expected_behavior": "Returns users matching 'test'",
    "actual_behavior": "Returns ALL users due to SQL injection"
  }
}

第 8 步：生成已验证发现

输出 validated-findings.json：

{
  "validation_id": "val-<timestamp>",
  "validation_date": "<ISO timestamp>",
  "scan_id": "scan-<timestamp>",
  "threat_model_path": ".factory/threat-model.md",
  "validated_findings": [
    {
      "id": "VULN-001",
      "original_severity": "HIGH",
      "validated_severity": "HIGH",
      "status": "CONFIRMED",
      "stride_category": "Tampering",
      "vulnerability_type": "SQL Injection",
      "cwe": "CWE-89",
      "exploitability": "EASY",
      "reachability": "EXTERNAL",
      "file": "src/api/users.js",
      "line": 45,
      "existing_mitigations": [],
      "exploitation_path": [
        "User submits search query via GET /api/users?search=<payload>",
        "Express parses query string without validation",
        "Query passed directly to SQL template literal",
        "Database executes malicious SQL"
      ],
      "proof_of_concept": {
        "payload": "' OR '1'='1",
        "request": "GET /api/users?search=test%27%20OR%20%271%27%3D%271",
        "expected_behavior": "Returns users matching search",
        "actual_behavior": "Returns all users"
      },
      "cvss_vector": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
      "cvss_score": 9.1,
      "recommendation": "Use parameterized queries",
      "references": [
        "https://cwe.mitre.org/data/definitions/89.html",
        "https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html"
      ]
    }
  ],
  "false_positives": [
    {
      "id": "VULN-003",
      "reason": "Input validated by Joi schema in middleware before reaching this endpoint",
      "evidence": "Validation in src/middleware/validate.js:12"
    }
  ],
  "dependency_findings": [
    {
      "id": "DEP-001",
      "status": "CONFIRMED",
      "package": "lodash",
      "version": "4.17.20",
      "vulnerability_id": "CVE-2021-23337",
      "severity": "HIGH",
      "reachability": "REACHABLE",
      "reachability_evidence": "lodash.template() called in src/utils/email.js:15",
      "fixed_version": "4.17.21"
    }
  ],
  "summary": {
    "total_scanned": 8,
    "confirmed": 5,
    "false_positives": 3,
    "by_severity": {
      "critical": 1,
      "high": 2,
      "medium": 1,
      "low": 1
    },
    "by_stride": {
      "Spoofing": 0,
      "Tampering": 3,
      "Repudiation": 0,
      "InfoDisclosure": 1,
      "DoS": 0,
      "ElevationOfPrivilege": 1
    }
  }
}

第 9 步：输出结果（取决于模式）

PR 模式：内联评论

针对每项发现，发布内联 PR 评论：

🔴 **CRITICAL: SQL Injection (CWE-89)**

**STRIDE Category:** Tampering
**Confidence:** High
**File:** `src/api/users.js:45-49`

**Analysis:**
User input from `req.query.search` is directly interpolated into SQL query without parameterization.

**Suggested Fix:**
```diff
- const query = `SELECT * FROM users WHERE name LIKE '%${search}%'`;
- const results = await db.query(query);
+ const query = `SELECT * FROM users WHERE name LIKE $1`;
+ const results = await db.query(query, [`%${search}%`]);

CWE-89：SQL 注入

Post summary tracking comment:

```markdown
## 🔒 Security Review Summary

| Severity | Count |
|----------|-------|
| 🔴 Critical | 1 |
| 🟠 High | 2 |
| 🟡 Medium | 3 |
| 🔵 Low | 0 |

### Findings
| ID | Severity | Type | File | Status |
|----|----------|------|------|--------|
| VULN-001 | Critical | SQL Injection | src/api/users.js:45 | Action required |
| VULN-002 | High | XSS | src/components/Comment.tsx:23 | Suggested fix |

---
*Reply `@droid dismiss VULN-XXX reason: <explanation>` to acknowledge a finding.*

每周／完整模式：安全报告 PR

创建分支：droid/security-report-{YYYY-MM-DD}

PR 标题：fix(security): Security scan report - {date} ({N} findings)

包括：

• .factory/security/reports/security-report-{YYYY-MM-DD}.md
• validated-findings.json
• 更新后的 .factory/threat-model.md（如果已重新生成）

第 10 步：严重性对应操作

严重性	PR 模式	每周／完整模式
CRITICAL	REQUEST_CHANGES - 阻止合并	创建 HIGH 优先级问题，通知安全团队
HIGH	REQUEST_CHANGES（可配置）	创建问题，要求审核
MEDIUM	仅 COMMENT	创建问题
LOW	仅 COMMENT	纳入报告

严重性定义

严重性	标准	示例
CRITICAL	可立即利用、影响重大、无需身份验证	RCE、硬编码的生产环境机密、身份验证绕过
HIGH	满足某些条件后可利用、影响重大	SQL 注入、存储型 XSS、IDOR
MEDIUM	需要特定条件、影响中等	反射型 XSS、CSRF、信息泄露
LOW	难以利用、影响较低	详细错误信息、缺少安全标头

漏洞覆盖范围

STRIDE 类别	漏洞类型
欺骗	弱身份验证、会话劫持、令牌泄露、凭据填充
篡改	SQL 注入、XSS、命令注入、批量赋值、路径遍历
抵赖	缺少审计日志、日志记录不足
信息泄露	IDOR、详细错误信息、硬编码机密、数据泄露
DoS	缺少速率限制、资源耗尽、ReDoS
权限提升	缺少授权检查、角色操纵、RBAC 绕过

成功标准

• 已检查／生成威胁模型
• 已扫描所有变更文件
• 已扫描依赖项中的 CVE
• 已验证发现是否可利用
• 已过滤误报
• 已生成 validated-findings.json
• 已按适当格式输出结果（PR 评论或报告）
• 已执行严重性对应操作

示例调用

PR 安全审查：

Scan PR #123 for security vulnerabilities.

在 PR 中手动触发：

@droid security

扫描整个代码库：

@droid security --full

每周扫描（最近 7 天）：

Scan commits from the last 7 days on main for security vulnerabilities.

扫描并修补：

Run full security analysis on PR #123: scan, validate, and generate patches.

文件结构

.factory/
├── threat-model.md              # STRIDE threat model
├── security-config.json         # Configuration
└── security/
    ├── acknowledged.json        # Dismissed findings
    └── reports/
        └── security-report-{date}.md

忽略发现项

PR 模式 - 回复行内评论：

@droid dismiss reason: Input is validated by Joi schema in middleware

每周/完整模式 - 在报告 PR 上发表评论：

@droid dismiss VULN-007 reason: Accepted risk for internal admin tool

已忽略的发现项存储在 .factory/security/acknowledged.json 中。

限制

无法检测：

• 业务逻辑漏洞
• 没有已知模式的零日漏洞
• 编译或压缩代码中的漏洞
• 需要运行时分析的问题

可能无法完全验证：

• 复杂的多服务数据流
• 需要身份验证状态的漏洞

参考资料

• STRIDE：https://docs.microsoft.com/en-us/azure/security/develop/threat-modeling-tool-threats
• OWASP Top 10：https://owasp.org/www-project-top-ten/
• CWE 数据库：https://cwe.mitre.org/
• OWASP 备忘单：https://cheatsheetseries.owasp.org/
• CVSS 计算器：https://www.first.org/cvss/calculator/3.1