Back to Details

security

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

/security - Security Audit Workflow

/security - 安全审计工作流

Use this skill to run a security audit workflow on sensitive code, prioritizing findings that can realistically become CRITICAL or HIGH impact.
使用此Skill对敏感代码执行安全审计工作流，优先处理实际可能造成CRITICAL或HIGH影响的问题。

When to Use

使用场景

  • The user asks for a security audit / vulnerability review ("is this secure?", "check for vulns").
  • The code touches authn/authz, payments, secrets, PII, file upload/download, webhooks, admin actions, deserialization, or command execution.
  • The user wants a scan + verification loop (audit findings → fixes → re-check).
  • 用户请求安全审计/漏洞检查（例如询问“这段代码安全吗？”、“检查漏洞”）。
  • 代码涉及authn/authz、支付、密钥、PII、文件上传/下载、Webhook、管理员操作、反序列化或命令执行。
  • 用户需要“扫描+验证”循环（审计发现问题 → 修复 → 重新检查）。

When NOT to Use

非使用场景

  • The user wants a general code review, debugging, refactor, or style improvements.
  • The code is clearly non-sensitive (toy scripts, local-only utilities) and the user isn’t asking about security.
  • 用户需要的是通用代码审查、调试、重构或代码风格优化。
  • 代码明显为非敏感内容（如示例脚本、仅本地使用的工具），且用户未询问安全相关问题。

Defaults / Guardrails

默认规则与约束

  • Report CRITICAL/HIGH only. If none exist, explicitly report none.
  • Treat "possession implies compromise" as non-finding unless you show a feasible token/secret acquisition path.
  • Prefer exploit-chain depth over breadth. Drop noise that can’t reach material impact.
For deeper triage/prerequisite rules and consistent output formats, read:
  • references/triage-and-prereqs.md
  • references/report-templates.md
  • 仅报告CRITICAL/HIGH级别问题。若不存在此类问题，需明确报告无。
  • 除非能展示可行的token/密钥获取路径，否则将“持有即妥协”视为非问题项。
  • 优先关注漏洞利用链的深度而非广度。忽略无法造成实质性影响的无关信息。
如需更详细的分类规则、前置要求以及统一的输出格式，请查阅：
  • references/triage-and-prereqs.md
  • references/report-templates.md

Workflow

工作流

0) Confirm Scope

0) 确认审计范围

Determine one of:
  • Full codebase: 
    /security
  • Area: 
    /security auth
    (or similar)
  • Single file: 
    /security path/to/file
  • Dependencies only: 
    /security --deps
确定以下范围之一：
  • 完整代码库：
    /security
  • 特定领域：
    /security auth
    （或类似指令）
  • 单个文件：
    /security path/to/file
  • 仅依赖项：
    /security --deps

1) Static Audit (Phase 1)

1) 静态审计（第一阶段）

Goal: find and explain only CRITICAL/HIGH issues with clear attacker prerequisites.
Prioritize:
  • Injection: SQL/NoSQL, command/OS, template injection, SSRF, XSS.
  • Authz failures: IDOR, missing checks, privilege escalation.
  • Authn/session: token validation mistakes that increase attacker capability.
  • Secrets: hardcoded credentials, leaked tokens/keys, unsafe secret handling.
  • Insecure deserialization, unsafe file handling (path traversal), dangerous eval.
  • Supply chain: obviously vulnerable deps or unsafe install/build hooks.
Evidence required per finding:
  • Attacker-controlled source → security-sensitive sink (show the path).
  • Concrete exploit narrative and prerequisites.
  • Containment + long-term remediation steps.
目标：仅找出并说明具有明确攻击者前置条件的CRITICAL/HIGH级别问题。
优先检查以下类型：
  • 注入类：SQL/NoSQL, command/OS, template injection, SSRF, XSS.
  • 授权失败：IDOR, 缺失权限检查, 权限提升.
  • 身份验证/会话：会提升攻击者能力的token验证错误。
  • 密钥管理：硬编码凭证、泄露的token/密钥、不安全的密钥处理方式。
  • 不安全的反序列化、不安全的文件处理（路径遍历）、危险的eval使用。
  • 供应链：存在明显漏洞的依赖项或不安全的安装/构建钩子。
每个问题项需提供以下证据：
  • 攻击者可控的输入源 → 安全敏感的输出点（展示完整路径）。
  • 具体的漏洞利用场景描述及前置条件。
  • 临时遏制措施 + 长期修复方案。

2) Runtime Verification (When Runnable)

2) 运行时验证（当代码可运行时）

If there is a runnable target, verify with minimal, safe steps.
Rules:
  • Only test instances you control / are authorized to test (prefer 
    localhost
    ).
  • Avoid DoS-like loops, mass writes, or destructive behavior.
  • Prefer repo-native commands (README, Makefile, Docker, package scripts).
Verification checklist:
  • Find how to run: README, Dockerfile, docker-compose, Makefile, package scripts.
  • Start the service in minimal config.
  • Prove impact with 1–3 deterministic requests/steps.
如果存在可运行的目标，通过最小化、安全的步骤进行验证。
验证规则：
  • 仅测试你有权限控制的实例（优先选择
    localhost
    ）。
  • 避免类似DoS的循环、批量写入或破坏性操作。
  • 优先使用代码库原生的命令（如README、Makefile、Docker、包管理脚本中定义的命令）。
验证检查清单：
  • 查找运行方式：README、Dockerfile、docker-compose、Makefile、包管理脚本。
  • 使用最小化配置启动服务。
  • 通过1-3个确定性的请求/步骤证明漏洞影响。

3) Fix Guidance

3) 修复建议

Recommend changes that eliminate the root cause:
  • Parameterize queries; avoid shell; escape/encode; strong allowlists for URLs/paths.
  • Enforce deny-by-default authorization.
  • Remove secrets from repo; use env/secret store; rotate compromised keys.
建议从根源上解决问题的修改方案：
  • 使用参数化查询；避免直接调用shell；对输入进行转义/编码；为URL/路径设置严格的白名单。
  • 实施默认拒绝的授权策略。
  • 从代码库中移除密钥；使用环境变量/密钥存储服务；轮换已泄露的密钥。

4) Re-Verify (Phase 2)

4) 重新验证（第二阶段）

After fixes, re-run minimal repros and any relevant security checks.
修复完成后，重新运行最小化的漏洞复现步骤及相关安全检查。

Triage Rules (Noise to Skip Unless Chained)

分类规则（除非可链造成影响，否则忽略以下无关项）

Skip by default unless you can chain to data loss/auth bypass/priv-esc with evidence:
  • CORS/OPTIONS “bypass” without protected response body or state change.
  • Missing rate limiting/lockout by itself.
  • Account enumeration without a takeover/privileged action path.
  • Timing side-channels without a feasible remote measurement model.
  • Swagger/UI exposure gated to non-prod.
  • Token-type confusion unless it meaningfully increases capability beyond intended flows.
If a borderline issue is showing up repeatedly, apply the stricter escalation criteria in 
references/triage-and-prereqs.md
.
默认忽略以下项，除非能证明可链造成数据泄露、权限绕过或权限提升：
  • 无法获取受保护响应体或造成状态变更的CORS/OPTIONS“绕过”。
  • 仅缺失速率限制/账户锁定机制。
  • 无法进一步进行账户接管或特权操作的账户枚举。
  • 无可行远程测量模型的时间侧信道。
  • 仅在非生产环境暴露的Swagger/UI。
  • 除非能显著提升超出预期流程的攻击者能力，否则token类型混淆问题可忽略。
若某个边界问题多次出现，请遵循
references/triage-and-prereqs.md
中更严格的升级规则。

Subagent Prompts

子Agent提示词

Phase 1: 
aegis
(Audit)

第一阶段：
aegis
（审计）

text
Security audit: [SCOPE]

Find CRITICAL/HIGH only. For each finding include:
- severity (CRITICAL/HIGH)
- attacker prerequisites
- source → sink evidence (file/function references)
- minimal repro steps (safe)
- remediation (containment first, then long-term)

If no CRITICAL/HIGH exist, explicitly output: NONE.

Deprioritize noise categories unless chained to material impact.
text
Security audit: [SCOPE]

Find CRITICAL/HIGH only. For each finding include:
- severity (CRITICAL/HIGH)
- attacker prerequisites
- source → sink evidence (file/function references)
- minimal repro steps (safe)
- remediation (containment first, then long-term)

If no CRITICAL/HIGH exist, explicitly output: NONE.

Deprioritize noise categories unless chained to material impact.

Phase 2: 
arbiter
(Verify)

第二阶段：
arbiter
（验证）

text
Verify security fixes: [SCOPE]

- Re-run minimal repro steps for each previously reported CRITICAL/HIGH
- Run the repo’s test/build checks relevant to the changed area
- Run dependency audit appropriate to stack (e.g., npm/pip/go)

Output: verification report (fixed/not fixed) and any regressions.
text
Verify security fixes: [SCOPE]

- Re-run minimal repro steps for each previously reported CRITICAL/HIGH
- Run the repo’s test/build checks relevant to the changed area
- Run dependency audit appropriate to stack (e.g., npm/pip/go)

Output: verification report (fixed/not fixed) and any regressions.

Flags

命令行参数

  • --deps
    : dependencies-only audit
  • --verify
    : post-fix verification run
  • --secrets
    : prioritize secret detection and leakage paths
  • --deps
    : 仅审计依赖项
  • --verify
    : 修复后的验证运行
  • --secrets
    : 优先检测密钥及泄露路径