协作头脑风暴
brainstorming
在实现前澄清需求、探索设计选择,并形成清晰的开发方向。
absolute-audit【开发与工程】Vulnerability and security scan (defensive, your own repo): dependency CVEs plus risky code patterns (secrets, injection, weak authz), severity x reachability triaged and remediated without suppressing. Complements the built-in /security-review. Triggers on "absolute audit", "security audit", "are we vulnerable", "scan for CVEs", "check for secrets/i…
独立 GitHub 快照 · 自动分类 · 以原作者文档为准
name: absolute-audit version: 0.5.0 description: > Vulnerability and security scan (defensive, your own repo): dependency CVEs plus risky code patterns (secrets, injection, weak authz), severity x reachability triaged and remediated without suppressing. Complements the built-in /security-review. Triggers on "absolute audit", "security audit", "are we vulnerable", "scan for CVEs", "check for secrets/injection", "harden this". category: workflow tags:
Start your first response with the 🔒 emoji.
Find and triage security problems across the repo — vulnerable dependencies (CVEs) and risky code patterns — then fix the ones worth fixing, safely. Output is a severity-ranked findings table with a remediation per item, not a raw scanner dump.
Runs the shared engine in references/health-engine.md — read it for the
DETECT → SCAN → TRIAGE → FIX → VERIFY → REPORT loop and the safety contract. This file
covers only what's specific to security auditing.
Authorized defensive use. This command audits the user's own repository to find and fix weaknesses. It is for hardening, not for attacking systems or evading detection.
main.Distinct from the built-in /security-review (reviews the pending diff on your
branch) — audit scans the whole committed repo, deps included. They complement.
1. Dependency vulnerabilities (CVEs) — primary:
| Ecosystem | Scanner |
|---|---|
| npm / pnpm / yarn | npm audit --json / pnpm audit --json / yarn npm audit --json |
| Python | pip-audit (preferred) or safety check |
| Go | govulncheck ./... |
| Cross-language | osv-scanner against the lockfile if available |
2. Code-level patterns — read-only grep/static pass for high-signal issues only:
hardcoded secrets/keys/tokens, eval/dynamic exec on input, SQL built by string
concatenation, missing authz checks on sensitive routes, disabled TLS verification, unsafe
deserialization, overly-broad CORS. Prefer the project's existing SAST/linter security
rules (eslint-plugin-security, bandit, gosec) if configured.
Report suspected leaked secrets but never print the secret value — reference
path:line and the kind.
Rank by severity × exploitability × reachability, not raw CVSS:
| Severity | Default |
|---|---|
| Critical / High, reachable, fix available | fix now (wave 1) |
| Moderate, reachable | fix this pass |
| Low / not reachable from app code | report, usually defer |
| Transitive-only, no direct upgrade path | flag, note the blocking parent |
Mark each: is it reachable from the app's actual code paths? A CVE in an unused transitive branch is lower priority than a Moderate one on a hot path. State the fixed version or the mitigation for each.
upgrade flow's per-ecosystem steps). Prefer patched minors;
escalate to a major only when that's the only fix, and gate it./absolute upgrade — does the actual version moves for vulnerable deps./security-review (built-in) — pair with this to also cover your pending diff./absolute work — if remediation is a real refactor (e.g. replacing an auth flow), hand off.