[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71JK2TPFJXS136A1XR8VZ95":3,"skill-same:01M71JK2TPFJXS136A1XR8VZ95":120},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":49,"commitSha":50,"skillDirectory":51,"forksCount":52,"repositoryHtmlUrl":53,"repositoryHomepageUrl":54,"ownerHtmlUrl":55,"ownerBlogUrl":56,"ownerDescription":6,"updatedAt":57,"install":58,"resources":71},"01M71JK2TPFJXS136A1XR8VZ95","security-review",null,"AI-powered security analysis of code changes — traces data flow, detects injection, auth bypass, secrets exposure, and unsafe deserialization across files. Use when reviewing pending changes, before release-branch, during verify-work Phase 5, during build-epic Step 0 threat modeling, or when the user says \"security review\" or \"scan for vulns\".","danielvm-git\u002Fbigpowers","danielvm-git","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F1020864?v=4","01M71H1N1CTQ529S0KN7KETVG6","Daniel V M","01M71H1N218Y3S8WHCJ58NPRSW",289,"MIT","https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002F.pi\u002Fskills\u002Fsecurity-review\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"security","review","security review","user","deserialization","build","changes","EPIC","use","scan","for","sonnet","threat modeling","injection","secrets exposure","release","exposure","phase","files","branch","2026-11-10 10:12:30",false,"---\nname: security-review\nmodel: sonnet\ndescription: \"AI-powered security analysis of code changes — traces data flow, detects injection, auth bypass, secrets exposure, and unsafe deserialization across files. Use when reviewing pending changes, before release-branch, during verify-work Phase 5, during build-epic Step 0 threat modeling, or when the user says \\\"security review\\\" or \\\"scan for vulns\\\".\"\n---\n\n\u003C!-- story: e45s41 -->\n\u003C!-- story: e45s18 -->\n\u003C!-- story: e26s01 -->\n\u003C!-- story: e26s02 -->\n\u003C!-- story: e26s03 -->\n\u003C!-- story: e26s04 -->\n\u003C!-- story: e26s05 -->\n\u003C!-- story: e26s06 -->\n\u003C!-- story: e26s07 -->\n\u003C!-- story: e45s26 -->\n\n# Security Review\n\n> **HARD GATE** — Requires git context (branch with merge-base or diff). Never\n> writes files outside `specs\u002Fsecurity\u002F`. Findings below confidence 8\u002F10 are\n> suppressed. Pre-flight: `git rev-parse HEAD >\u002Fdev\u002Fnull 2>&1`\n\n## Parallel worktree mode (e45s18)\n\nWhen running alongside `audit-code`, use isolated worktrees so scans do not race on the same index:\n\n```bash\nbash scripts\u002Flib\u002Fparallel-review-worktrees.sh security-review\n```\n\nEach check gets a detached worktree at `.bigpowers\u002Fworktrees\u002Freview-\u003Cname>\u002F`; reports still write only under `specs\u002Fsecurity\u002F`.\n\n## 5-phase scan\n\n| # | Phase | What |\n|---|-------|------|\n| 1 | **Scope Resolution** | Detect diff via `git diff --merge-base origin\u002FHEAD`; resolve languages\u002Fframeworks from dependency files |\n| 2 | **Context Research** | Identify existing security patterns, sanitization, auth model in the codebase |\n| 3 | **Vulnerability Assessment** | Trace user input → sink; check auth boundaries, crypto, deserialization, path ops |\n| 4 | **False-Positive Filtering** | Cross-check each finding against exclusion rules; reject confidence \u003C 8 |\n| 5 | **Report Generation** | Output structured markdown: file:line, severity, category, exploit scenario, fix |\n\n## Categories\n\nCovered: SQLi, XSS, SSRF, command injection, auth bypass, unsafe deserialization, path traversal, IDOR, crypto flaws, secrets exposure, template injection, NoSQLi\n\n## CWE mapping mandate (e45s26)\n\nEvery **new detection rule** added to this skill MUST:\n\n1. Map to a [CWE](https:\u002F\u002Fcwe.mitre.org\u002F) ID in `REFERENCE-vuln-categories.md` (e.g. SQLi → CWE-89, XSS → CWE-79).\n2. Ship **two fixture pairs** under `skills\u002Fsecurity-review\u002Ffixtures\u002F`:\n   - **Positive** — minimal code the rule MUST flag (vulnerable pattern present).\n   - **Negative** — structurally similar code the rule MUST NOT flag (safe pattern \u002F false-positive guard).\n\n| Rule | CWE | Positive fixture | Negative fixture |\n|------|-----|------------------|------------------|\n| SQL injection | CWE-89 | `fixtures\u002FCWE-89-sqli-positive.py` | `fixtures\u002FCWE-89-sqli-negative.py` |\n| XSS (DOM) | CWE-79 | `fixtures\u002FCWE-79-xss-positive.js` | `fixtures\u002FCWE-79-xss-negative.js` |\n| Missing tenant scoping (IDOR) | CWE-639 | `fixtures\u002FCWE-639-idor-positive.go` | `fixtures\u002FCWE-639-idor-negative.go` |\n| Fail-open verify directive | CWE-754 | `fixtures\u002FCWE-fail-open-verify-positive.sh` | `fixtures\u002FCWE-fail-open-verify-negative.sh` |\n\nBefore merging a new category, run both fixtures through the detection guidance and confirm positive flags \u002F negative passes.\n\n## SQL-safety doctrine (e45s41 — proven authorship)\n\nFormal rule for SQL injection classification:\n\n| SQL source | Attacker-reachable input? | Verdict |\n|------------|---------------------------|---------|\n| Hardcoded \u002F compile-time constant string | N\u002FA | **Safe** — proven authorship |\n| Developer-authored query with bound parameters only | No dynamic fragments from user input | **Safe** |\n| String concatenation \u002F template with user-controlled values | Yes | **Unsafe** — report as SQLi |\n| ORM query builder with user input in WHERE\u002FJOIN | Yes | **Unsafe** unless parameterized |\n| Stored procedure call with bound args | Args from trusted constants only | **Safe** |\n| Stored procedure with dynamic SQL inside | User input reaches EXEC | **Unsafe** |\n\n**Provenance test:** If the agent cannot prove the query string was authored entirely by the developer (no attacker-reachable interpolation), treat as vulnerable. Hardcoded SQL in migrations, seeds, and admin scripts is safe; anything reachable from HTTP\u002FCLI\u002Fuser input is not.\n\n## BCP Plus Integration\n\nThis skill maps to **BCP Plus dimension 12 (Security & Compliance)**. When BCP Plus sizing is active, the threat model categories above correspond to sub-elements within dimension 12. The NFR Gate rule applies: standard-expectation items (e.g., \"use HTTPS\", \"hash passwords\") score 0 with a one-line rationale; only above-standard security requirements contribute to the dimension 12 count. See `docs\u002Freferences\u002Fbcp-plus.md` for the full 13-dimension framework and NFR Gate pattern.\n\n## Integration points\n\n| Skill | Touchpoint |\n|-------|------------|\n| `build-epic` | Step 0 — threat-model epic scope → `specs\u002Fsecurity\u002Fepics\u002F\u003Cid>\u002FTHREAT_MODEL.md` |\n| `plan-work` | `security:` field (none\u002Flow\u002Fmedium\u002Fhigh) on story tasks |\n| `plan-release` | +2 WSJF risk boost for HIGH+ risk epics |\n| `audit-code` | Checklist: \"diff scanned — no unaddressed HIGH findings\" |\n| `request-review` | Inject threat model categories + false-positive rules into reviewer prompt |\n| `investigate-bug` | Security-impact assessment in RCA (NONE→CRITICAL) |\n| `validate-fix` | Recurrence hardening check for security bugs |\n| `verify-work` | Phase 5 — blocks on HIGH findings ≥ 8 confidence |\n| `release-branch` | Hard gate — blocks merge if unresolved HIGH findings |\n\n## Report format\n\nEach finding: **`File:Line` — Severity — Category**\n- Description: how the vulnerability manifests\n- Exploit scenario: concrete attack path\n- Recommendation: fix with code example\n\n## Reference files\n\n- [Vuln categories](..\u002F..\u002F..\u002Fskills\u002Fsecurity-review\u002FREFERENCE-vuln-categories.md) — detection guidance per vuln type\n- [False positives](..\u002F..\u002F..\u002Fskills\u002Fsecurity-review\u002FREFERENCE-false-positives.md) — hard exclusions + precedent\n- [Confidence rubric](..\u002F..\u002F..\u002Fskills\u002Fsecurity-review\u002FREFERENCE-confidence-rubric.md) — scoring methodology (0–10)\n\n## Verify\n\n→ verify: `test -d specs\u002Fsecurity && test -f scripts\u002Flib\u002Fparallel-review-worktrees.sh && bash scripts\u002Fverify-cwe-fixture-sync.sh >\u002Fdev\u002Fnull && git rev-parse HEAD >\u002Fdev\u002Fnull 2>&1`\n\n---\n\n# Confidence Scoring Rubric\n\nEvery finding that survives Phase 4 false-positive filtering receives a confidence\nscore from 1 (speculative) to 10 (certain). Only findings ≥ 8 are reported.\n\n## Score 9–10: Certain Exploit Path\n\n**Criteria:**\n- Concrete, testable exploit with clear reproduction steps\n- No assumptions about uncommon configurations\n- No chain of multiple unlikely conditions\n- Attacker has full control over the input vector\n\n**Examples:**\n- User-supplied SQL in a `SELECT` statement with no parameterization\n- `os.system(f\"rm {user_path}\")` where user controls the path\n- Pickle deserialization of user-supplied data without any wrapping\n\n**Severity:** HIGH\n\n## Score 8: Clear Vulnerability Pattern\n\n**Criteria:**\n- Well-known vulnerability pattern with standard exploitation method\n- Requires specific conditions but conditions are commonly met\n- Exploitability is well-documented in OWASP \u002F CVE databases\n\n**Examples:**\n- JWT without signature verification in authentication middleware\n- SSRF where attacker controls the full URL including host\n- Hardcoded AWS secret key in source code\n\n**Severity:** HIGH or MEDIUM\n\n## Score 7: Suspicious Pattern\n\n**Criteria:**\n- Unusual code that may indicate a vulnerability\n- Requires specific conditions that may not be present\n- Alternative secure interpretation is equally likely\n- Defense-in-depth concern rather than direct exploit\n\n**Examples:**\n- A function accepting user input that passes through multiple layers before reaching a sink (unclear if sanitized)\n- Custom encryption implementation (likely weak, but may not process sensitive data)\n- Path construction that looks safe but has a subtle bypass\n\n**Severity:** LOW or suppress\n\n## Score \u003C 7: Do Not Report\n\n**Criteria:**\n- Theoretical concern without exploit path\n- Requires unrealistic attacker capabilities\n- Violates one or more hard exclusion rules\n- Better handled by separate tooling (dependency scanner, SAST, secret scanner)\n- Purely stylistic or best-practice concern without security impact\n\n**Examples:**\n- \"This function doesn't validate all inputs\" without proving the validated input is the attack surface\n- \"This uses MD5\" where the hash is not used for security (e.g., cache key)\n- \"This function could consume too much memory\" (DOS exclusion)\n\n**Action:** Suppress entirely. Do not include in report.\n\n## Severity Mapping\n\nOnce confidence ≥ 8 is confirmed, map to severity:\n\n| Severity | Impact | Examples |\n|----------|--------|---------|\n| **CRITICAL** | Remote compromise, full data breach | RCE, auth bypass with admin escalation, SQLi with data exfiltration |\n| **HIGH** | Significant security boundary crossed | SSRF to internal services, hardcoded cloud credentials, insecure deserialization |\n| **MEDIUM** | Limited impact or requires conditions | Stored XSS behind auth, IDOR on non-sensitive data, weak but not broken crypto |\n| **LOW** | Defense-in-depth, minimal blast radius | Missing security header, verbose error messages in non-production |\n\n## Quality Gate\n\nThe confidence rubric double-checks each finding against three lenses:\n\n| Lens | Question |\n|------|----------|\n| **Exploitability** | Can a real attacker trigger this from a trust boundary? |\n| **Actionability** | Would a security engineer accept a fix recommendation for this? |\n| **Precedent** | Has this type of finding passed\u002Ffailed human review before? |\n\n---\n\n# False-Positive Exclusion Rules\n\nApplied during Phase 4 of the scan. Findings matching any hard exclusion are\nautomatically suppressed. Precedents from prior reviews guide borderline cases.\n\n## Hard Exclusions\n\nAutomatically exclude findings matching these patterns:\n\n| # | Rule | Rationale |\n|---|------|-----------|\n| 1 | **Denial of Service (DOS)** — resource exhaustion, CPU\u002Fmemory attacks | Handled separately; not actionable in code review |\n| 2 | **Secrets on disk** if otherwise secured | Secrets management is a separate concern |\n| 3 | **Rate limiting** concerns | Operational, not a code vulnerability |\n| 4 | **Memory consumption \u002F CPU exhaustion** | Not actionable in diff review |\n| 5 | **Input validation on non-security-critical fields** without proven exploit path | Theoretical, not concrete |\n| 6 | **GitHub Actions input sanitization** unless clearly triggerable via untrusted input | Most workflow vulns are not exploitable |\n| 7 | **Lack of hardening measures** | Code is not expected to implement all best practices |\n| 8 | **Race conditions \u002F timing attacks** that are theoretical | Only report if concretely problematic |\n| 9 | **Outdated third-party libraries** | Managed separately by dependency scanners |\n| 10 | **Memory safety** in Rust or other memory-safe languages | Impossible by language guarantees |\n| 11 | **Hardcoded SQL with proven authorship** — migrations, seeds, static admin queries with no user interpolation | Developer-authored SQL is safe per SQL-safety doctrine (e45s41) |\n| 12 | **Unit test files only** | Not production risk |\n| 13 | **Log spoofing** | Outputting unsanitized input to logs is not a vuln |\n| 14 | **SSRF that only controls path** | Only host\u002Fprotocol control is exploitable |\n| 15 | **User-controlled content in AI system prompts** | Not a security vulnerability |\n| 16 | **Regex injection** | Injecting untrusted content into regex is not a vuln |\n| 17 | **Regex DOS** | Excluded alongside general DOS |\n| 18 | **Documentation files** (.md, .txt) | Insecure docs are not code vulnerabilities |\n| 19 | **Lack of audit logs** | Not a vulnerability |\n\n## Precedent Rules\n\nThese guide borderline cases based on prior human review decisions:\n\n| # | Precedent | Reasoning |\n|---|-----------|-----------|\n| 1 | **Logging high-value secrets in plaintext IS a vuln.** Logging URLs is safe. | Secrets in logs = credential exposure; URLs are not secrets |\n| 2 | **UUIDs are unguessable** — no validation needed | Cryptographic property of UUID v4\u002Fv7 |\n| 3 | **Environment variables and CLI flags are trusted values** | Attackers cannot modify these in secure environments |\n| 4 | **Resource management issues** (memory leaks, fd leaks) are NOT valid | Operational, not security |\n| 5 | **Tabnabbing, XS-Leaks, prototype pollution, open redirects** — do NOT report unless extremely high confidence | Subtle, low-impact, high false-positive rate |\n| 6 | **React\u002FAngular XSS** — safe unless `dangerouslySetInnerHTML`, `bypassSecurityTrustHtml`, etc. | Framework auto-escapes |\n| 7 | **GitHub Action workflow vulns** — verify concrete attack path before reporting | Most are theoretical |\n| 8 | **Client-side JS\u002FTS auth checks** — not a vuln; server is authoritative | Client code is untrusted |\n| 9 | **IPython notebook vulns** — only report if concrete untrusted-input trigger | Most are not exploitable |\n| 10 | **Logging non-PII data** — not a vuln even if sensitive. Only PII\u002Fsecrets\u002Fpasswords. | Intent: operational logging vs credential exposure |\n| 11 | **Shell script command injection** — only report if concrete untrusted-input path | Most shell scripts don't process untrusted input |\n\n## Confidence Scoring\n\nFindings that survive exclusions get a confidence score (1–10):\n\n| Range | Meaning | Action |\n|-------|---------|--------|\n| 9–10 | Certain exploit path, testable | Report as HIGH |\n| 8 | Clear vulnerability pattern | Report as HIGH\u002FMEDIUM |\n| 7 | Suspicious, needs conditions | Report as LOW or suppress |\n| \u003C7 | Too speculative | **Do not report** |\n\n**Hard threshold:** Only report findings with confidence ≥ 8.\n\n## Signal Quality Criteria\n\nFor remaining findings, assess:\n1. Is there a concrete, exploitable vulnerability with a clear attack path?\n2. Does this represent a real security risk (vs theoretical best practice)?\n3. Are there specific code locations and reproduction steps?\n4. Would this finding be actionable for a security team?\n\n---\n\n# Vulnerability Categories — Detection Guidance\n\nEach category: vulnerable pattern → safe pattern → code example.\n\n## SQL Injection\n\n| Aspect | Detail |\n|--------|--------|\n| **Vulnerable** | String interpolation in SQL queries: `f\"SELECT * FROM users WHERE id = {uid}\"` |\n| **CWE** | CWE-89 (SQL Injection) |\n| **Fixtures** | `fixtures\u002FCWE-89-sqli-positive.py` (flag) · `fixtures\u002FCWE-89-sqli-negative.py` (pass) |\n| **Safe** | Parameterized queries \u002F ORM: `cursor.execute(\"SELECT * FROM users WHERE id = %s\", (uid,))` |\n| **Look for** | f-strings, `+` concatenation, `format()` in query builders; raw SQL in ORM `.raw()` \u002F `.execute()` |\n| **False-positive guard** | Not a FP if the input is user-controlled (HTTP param, file, env var, CLI arg). Env vars are trusted (see exclusion rules). |\n\n## Cross-Site Scripting (XSS)\n\n| Aspect | Detail |\n|--------|--------|\n| **Vulnerable** | `element.innerHTML = userInput`, `dangerouslySetInnerHTML={{__html: userInput}}` |\n| **CWE** | CWE-79 (Cross-site Scripting) |\n| **Fixtures** | `fixtures\u002FCWE-79-xss-positive.js` (flag) · `fixtures\u002FCWE-79-xss-negative.js` (pass) |\n| **Safe** | `element.textContent = userInput`, React JSX (auto-escaped), template engines with auto-escaping |\n| **Look for** | `.innerHTML`, `document.write()`, `dangerouslySetInnerHTML`, `v-html` (Vue), `bypassSecurityTrustHtml` (Angular) |\n| **False-positive guard** | React\u002FAngular components without unsafe methods are NOT vulnerable (see exclusion rules). |\n\n## Server-Side Request Forgery (SSRF)\n\n| Aspect | Detail |\n|--------|--------|\n| **Vulnerable** | User-controlled URL passed to server-side HTTP client: `requests.get(user_url)` |\n| **Safe** | URL allowlist validation, internal-network blocking, protocol\u002Fhost restriction |\n| **Look for** | User input → `fetch`, `requests.get`, `axios.get`, `urllib`, `curl`, `http.get`; host control only (path-only is excluded) |\n\n## Command Injection\n\n| Aspect | Detail |\n|--------|--------|\n| **Vulnerable** | User input in shell commands: `os.system(f\"ping {host}\")`, `subprocess.run(f\"grep {pattern} file\", shell=True)` |\n| **Safe** | `subprocess.run([\"ping\", host])` with arguments as list; `shlex.quote()` |\n| **Look for** | `shell=True`, `os.system`, `os.popen`, `exec()`, `eval()`, `$()`, backticks |\n| **False-positive guard** | Shell scripts without untrusted user input are generally not exploitable. |\n\n## Authentication\u002FAuthorization Bypass\n\n| Aspect | Detail |\n|--------|--------|\n| **Vulnerable** | Missing auth check on protected endpoint; JWT without signature verification; hardcoded admin tokens |\n| **Safe** | Consistent auth middleware; JWT with `RS256`\u002F`HS256` verification; role-based access control |\n| **Look for** | Routes without auth decorators; `@login_required` \u002F `@require_auth` missing; JWT without `.verify()`; client-side auth checks only |\n\n## Unsafe Deserialization\n\n| Aspect | Detail |\n|--------|--------|\n| **Vulnerable** | `pickle.load(user_data)`, `yaml.load(user_input)`, `JSON.parse()` on untrusted tokens, `eval(input())` |\n| **Safe** | `yaml.safe_load()`, `json.loads()` (safe for JSON), `pickle.load(weights_only=True)` (PyTorch), schema validation |\n| **Look for** | `pickle.load`, `yaml.load` (not safe_load), `torch.load(weights_only=False)`, `eval`, `marshal.load`, `node-serialize` |\n\n## Path Traversal\n\n| Aspect | Detail |\n|--------|--------|\n| **Vulnerable** | User input in file paths: `open(f\"\u002Fdata\u002F{filename}\")`, `path.join(base, user_path)` |\n| **Safe** | Path normalization + prefix check: `os.path.realpath(path).startswith(BASE_DIR)`; allowlist of valid filenames |\n| **Look for** | `open()`, `read_file()`, `os.path.join` with user input; `..\u002F` traversal without normalization |\n\n## Insecure Direct Object Reference (IDOR)\n\n| Aspect | Detail |\n|--------|--------|\n| **Vulnerable** | API endpoint uses user-supplied ID without ownership check: `GET \u002Fapi\u002Forder\u002F{order_id}` — returns any user's order |\n| **Safe** | Ownership verification: verify `order.user_id == current_user.id` before returning data |\n| **Look for** | CRUD endpoints that accept IDs without authorization; horizontal\u002Fvertical privilege checks missing |\n\n## Weak Cryptography\n\n| Aspect | Detail |\n|--------|--------|\n| **Vulnerable** | MD5\u002FSHA1 for passwords; ECB mode; hardcoded keys; `random` module (not `secrets`); short key lengths |\n| **Safe** | `bcrypt`\u002F`argon2` for passwords; AES-GCM; `secrets` module; RSA 2048+; proper IV generation |\n| **Look for** | `md5`, `sha1`, `DES`, `ECB`, `PKCS1_v1_5`, `random` for crypto, hardcoded `key=`, `Crypto.Cipher` without AEAD |\n\n## Secrets Exposure\n\n| Aspect | Detail |\n|--------|--------|\n| **Vulnerable** | Hardcoded API keys, passwords, tokens in source code; secrets in logs; secrets in client-side code |\n| **Safe** | Environment variables; secret manager (AWS Secrets Manager, HashiCorp Vault); `.env` excluded from VCS |\n| **Look for** | `API_KEY=`, `password=`, `secret=`, `token=` in code; AWS keys, GitHub tokens, Stripe keys, JWTs in source |\n| **False-positive guard** | Secrets stored on disk but otherwise secured ARE excluded. Logging high-value secrets IS a vuln. Logging URLs is safe. |\n\n## Template Injection (SSTI)\n\n| Aspect | Detail |\n|--------|--------|\n| **Vulnerable** | User input in template rendering: `Template(user_input).render()`, `render_template_string(user_input)` |\n| **Safe** | Static templates; input passed as context variable, not template string |\n| **Look for** | `render_template_string`, `Template()()` with user string; `eval` in template context; `${user_input}` in JS template literals on server |\n\n## NoSQL Injection\n\n| Aspect | Detail |\n|--------|--------|\n| **Vulnerable** | User input in MongoDB queries: `db.users.find({username: user_input})` where input is `{\"$gt\": \"\"}` |\n| **Safe** | Schema validation; type checking on query params; ORM sanitization |\n| **Look for** | MongoDB `$where`, `$gt`, `$regex` from user input; raw mongo queries without type coercion |\n","\u003C!-- story: e45s41 -->\n\u003C!-- story: e45s18 -->\n\u003C!-- story: e26s01 -->\n\u003C!-- story: e26s02 -->\n\u003C!-- story: e26s03 -->\n\u003C!-- story: e26s04 -->\n\u003C!-- story: e26s05 -->\n\u003C!-- story: e26s06 -->\n\u003C!-- story: e26s07 -->\n\u003C!-- story: e45s26 -->\n\n# Security Review\n\n> **HARD GATE** — Requires git context (branch with merge-base or diff). Never\n> writes files outside `specs\u002Fsecurity\u002F`. Findings below confidence 8\u002F10 are\n> suppressed. Pre-flight: `git rev-parse HEAD >\u002Fdev\u002Fnull 2>&1`\n\n## Parallel worktree mode (e45s18)\n\nWhen running alongside `audit-code`, use isolated worktrees so scans do not race on the same index:\n\n```bash\nbash scripts\u002Flib\u002Fparallel-review-worktrees.sh security-review\n```\n\nEach check gets a detached worktree at `.bigpowers\u002Fworktrees\u002Freview-\u003Cname>\u002F`; reports still write only under `specs\u002Fsecurity\u002F`.\n\n## 5-phase scan\n\n| # | Phase | What |\n|---|-------|------|\n| 1 | **Scope Resolution** | Detect diff via `git diff --merge-base origin\u002FHEAD`; resolve languages\u002Fframeworks from dependency files |\n| 2 | **Context Research** | Identify existing security patterns, sanitization, auth model in the codebase |\n| 3 | **Vulnerability Assessment** | Trace user input → sink; check auth boundaries, crypto, deserialization, path ops |\n| 4 | **False-Positive Filtering** | Cross-check each finding against exclusion rules; reject confidence \u003C 8 |\n| 5 | **Report Generation** | Output structured markdown: file:line, severity, category, exploit scenario, fix |\n\n## Categories\n\nCovered: SQLi, XSS, SSRF, command injection, auth bypass, unsafe deserialization, path traversal, IDOR, crypto flaws, secrets exposure, template injection, NoSQLi\n\n## CWE mapping mandate (e45s26)\n\nEvery **new detection rule** added to this skill MUST:\n\n1. Map to a [CWE](https:\u002F\u002Fcwe.mitre.org\u002F) ID in `REFERENCE-vuln-categories.md` (e.g. SQLi → CWE-89, XSS → CWE-79).\n2. Ship **two fixture pairs** under `skills\u002Fsecurity-review\u002Ffixtures\u002F`:\n   - **Positive** — minimal code the rule MUST flag (vulnerable pattern present).\n   - **Negative** — structurally similar code the rule MUST NOT flag (safe pattern \u002F false-positive guard).\n\n| Rule | CWE | Positive fixture | Negative fixture |\n|------|-----|------------------|------------------|\n| SQL injection | CWE-89 | `fixtures\u002FCWE-89-sqli-positive.py` | `fixtures\u002FCWE-89-sqli-negative.py` |\n| XSS (DOM) | CWE-79 | `fixtures\u002FCWE-79-xss-positive.js` | `fixtures\u002FCWE-79-xss-negative.js` |\n| Missing tenant scoping (IDOR) | CWE-639 | `fixtures\u002FCWE-639-idor-positive.go` | `fixtures\u002FCWE-639-idor-negative.go` |\n| Fail-open verify directive | CWE-754 | `fixtures\u002FCWE-fail-open-verify-positive.sh` | `fixtures\u002FCWE-fail-open-verify-negative.sh` |\n\nBefore merging a new category, run both fixtures through the detection guidance and confirm positive flags \u002F negative passes.\n\n## SQL-safety doctrine (e45s41 — proven authorship)\n\nFormal rule for SQL injection classification:\n\n| SQL source | Attacker-reachable input? | Verdict |\n|------------|---------------------------|---------|\n| Hardcoded \u002F compile-time constant string | N\u002FA | **Safe** — proven authorship |\n| Developer-authored query with bound parameters only | No dynamic fragments from user input | **Safe** |\n| String concatenation \u002F template with user-controlled values | Yes | **Unsafe** — report as SQLi |\n| ORM query builder with user input in WHERE\u002FJOIN | Yes | **Unsafe** unless parameterized |\n| Stored procedure call with bound args | Args from trusted constants only | **Safe** |\n| Stored procedure with dynamic SQL inside | User input reaches EXEC | **Unsafe** |\n\n**Provenance test:** If the agent cannot prove the query string was authored entirely by the developer (no attacker-reachable interpolation), treat as vulnerable. Hardcoded SQL in migrations, seeds, and admin scripts is safe; anything reachable from HTTP\u002FCLI\u002Fuser input is not.\n\n## BCP Plus Integration\n\nThis skill maps to **BCP Plus dimension 12 (Security & Compliance)**. When BCP Plus sizing is active, the threat model categories above correspond to sub-elements within dimension 12. The NFR Gate rule applies: standard-expectation items (e.g., \"use HTTPS\", \"hash passwords\") score 0 with a one-line rationale; only above-standard security requirements contribute to the dimension 12 count. See `docs\u002Freferences\u002Fbcp-plus.md` for the full 13-dimension framework and NFR Gate pattern.\n\n## Integration points\n\n| Skill | Touchpoint |\n|-------|------------|\n| `build-epic` | Step 0 — threat-model epic scope → `specs\u002Fsecurity\u002Fepics\u002F\u003Cid>\u002FTHREAT_MODEL.md` |\n| `plan-work` | `security:` field (none\u002Flow\u002Fmedium\u002Fhigh) on story tasks |\n| `plan-release` | +2 WSJF risk boost for HIGH+ risk epics |\n| `audit-code` | Checklist: \"diff scanned — no unaddressed HIGH findings\" |\n| `request-review` | Inject threat model categories + false-positive rules into reviewer prompt |\n| `investigate-bug` | Security-impact assessment in RCA (NONE→CRITICAL) |\n| `validate-fix` | Recurrence hardening check for security bugs |\n| `verify-work` | Phase 5 — blocks on HIGH findings ≥ 8 confidence |\n| `release-branch` | Hard gate — blocks merge if unresolved HIGH findings |\n\n## Report format\n\nEach finding: **`File:Line` — Severity — Category**\n- Description: how the vulnerability manifests\n- Exploit scenario: concrete attack path\n- Recommendation: fix with code example\n\n## Reference files\n\n- [Vuln categories](..\u002F..\u002F..\u002Fskills\u002Fsecurity-review\u002FREFERENCE-vuln-categories.md) — detection guidance per vuln type\n- [False positives](..\u002F..\u002F..\u002Fskills\u002Fsecurity-review\u002FREFERENCE-false-positives.md) — hard exclusions + precedent\n- [Confidence rubric](..\u002F..\u002F..\u002Fskills\u002Fsecurity-review\u002FREFERENCE-confidence-rubric.md) — scoring methodology (0–10)\n\n## Verify\n\n→ verify: `test -d specs\u002Fsecurity && test -f scripts\u002Flib\u002Fparallel-review-worktrees.sh && bash scripts\u002Fverify-cwe-fixture-sync.sh >\u002Fdev\u002Fnull && git rev-parse HEAD >\u002Fdev\u002Fnull 2>&1`\n\n---\n\n# Confidence Scoring Rubric\n\nEvery finding that survives Phase 4 false-positive filtering receives a confidence\nscore from 1 (speculative) to 10 (certain). Only findings ≥ 8 are reported.\n\n## Score 9–10: Certain Exploit Path\n\n**Criteria:**\n- Concrete, testable exploit with clear reproduction steps\n- No assumptions about uncommon configurations\n- No chain of multiple unlikely conditions\n- Attacker has full control over the input vector\n\n**Examples:**\n- User-supplied SQL in a `SELECT` statement with no parameterization\n- `os.system(f\"rm {user_path}\")` where user controls the path\n- Pickle deserialization of user-supplied data without any wrapping\n\n**Severity:** HIGH\n\n## Score 8: Clear Vulnerability Pattern\n\n**Criteria:**\n- Well-known vulnerability pattern with standard exploitation method\n- Requires specific conditions but conditions are commonly met\n- Exploitability is well-documented in OWASP \u002F CVE databases\n\n**Examples:**\n- JWT without signature verification in authentication middleware\n- SSRF where attacker controls the full URL including host\n- Hardcoded AWS secret key in source code\n\n**Severity:** HIGH or MEDIUM\n\n## Score 7: Suspicious Pattern\n\n**Criteria:**\n- Unusual code that may indicate a vulnerability\n- Requires specific conditions that may not be present\n- Alternative secure interpretation is equally likely\n- Defense-in-depth concern rather than direct exploit\n\n**Examples:**\n- A function accepting user input that passes through multiple layers before reaching a sink (unclear if sanitized)\n- Custom encryption implementation (likely weak, but may not process sensitive data)\n- Path construction that looks safe but has a subtle bypass\n\n**Severity:** LOW or suppress\n\n## Score \u003C 7: Do Not Report\n\n**Criteria:**\n- Theoretical concern without exploit path\n- Requires unrealistic attacker capabilities\n- Violates one or more hard exclusion rules\n- Better handled by separate tooling (dependency scanner, SAST, secret scanner)\n- Purely stylistic or best-practice concern without security impact\n\n**Examples:**\n- \"This function doesn't validate all inputs\" without proving the validated input is the attack surface\n- \"This uses MD5\" where the hash is not used for security (e.g., cache key)\n- \"This function could consume too much memory\" (DOS exclusion)\n\n**Action:** Suppress entirely. Do not include in report.\n\n## Severity Mapping\n\nOnce confidence ≥ 8 is confirmed, map to severity:\n\n| Severity | Impact | Examples |\n|----------|--------|---------|\n| **CRITICAL** | Remote compromise, full data breach | RCE, auth bypass with admin escalation, SQLi with data exfiltration |\n| **HIGH** | Significant security boundary crossed | SSRF to internal services, hardcoded cloud credentials, insecure deserialization |\n| **MEDIUM** | Limited impact or requires conditions | Stored XSS behind auth, IDOR on non-sensitive data, weak but not broken crypto |\n| **LOW** | Defense-in-depth, minimal blast radius | Missing security header, verbose error messages in non-production |\n\n## Quality Gate\n\nThe confidence rubric double-checks each finding against three lenses:\n\n| Lens | Question |\n|------|----------|\n| **Exploitability** | Can a real attacker trigger this from a trust boundary? |\n| **Actionability** | Would a security engineer accept a fix recommendation for this? |\n| **Precedent** | Has this type of finding passed\u002Ffailed human review before? |\n\n---\n\n# False-Positive Exclusion Rules\n\nApplied during Phase 4 of the scan. Findings matching any hard exclusion are\nautomatically suppressed. Precedents from prior reviews guide borderline cases.\n\n## Hard Exclusions\n\nAutomatically exclude findings matching these patterns:\n\n| # | Rule | Rationale |\n|---|------|-----------|\n| 1 | **Denial of Service (DOS)** — resource exhaustion, CPU\u002Fmemory attacks | Handled separately; not actionable in code review |\n| 2 | **Secrets on disk** if otherwise secured | Secrets management is a separate concern |\n| 3 | **Rate limiting** concerns | Operational, not a code vulnerability |\n| 4 | **Memory consumption \u002F CPU exhaustion** | Not actionable in diff review |\n| 5 | **Input validation on non-security-critical fields** without proven exploit path | Theoretical, not concrete |\n| 6 | **GitHub Actions input sanitization** unless clearly triggerable via untrusted input | Most workflow vulns are not exploitable |\n| 7 | **Lack of hardening measures** | Code is not expected to implement all best practices |\n| 8 | **Race conditions \u002F timing attacks** that are theoretical | Only report if concretely problematic |\n| 9 | **Outdated third-party libraries** | Managed separately by dependency scanners |\n| 10 | **Memory safety** in Rust or other memory-safe languages | Impossible by language guarantees |\n| 11 | **Hardcoded SQL with proven authorship** — migrations, seeds, static admin queries with no user interpolation | Developer-authored SQL is safe per SQL-safety doctrine (e45s41) |\n| 12 | **Unit test files only** | Not production risk |\n| 13 | **Log spoofing** | Outputting unsanitized input to logs is not a vuln |\n| 14 | **SSRF that only controls path** | Only host\u002Fprotocol control is exploitable |\n| 15 | **User-controlled content in AI system prompts** | Not a security vulnerability |\n| 16 | **Regex injection** | Injecting untrusted content into regex is not a vuln |\n| 17 | **Regex DOS** | Excluded alongside general DOS |\n| 18 | **Documentation files** (.md, .txt) | Insecure docs are not code vulnerabilities |\n| 19 | **Lack of audit logs** | Not a vulnerability |\n\n## Precedent Rules\n\nThese guide borderline cases based on prior human review decisions:\n\n| # | Precedent | Reasoning |\n|---|-----------|-----------|\n| 1 | **Logging high-value secrets in plaintext IS a vuln.** Logging URLs is safe. | Secrets in logs = credential exposure; URLs are not secrets |\n| 2 | **UUIDs are unguessable** — no validation needed | Cryptographic property of UUID v4\u002Fv7 |\n| 3 | **Environment variables and CLI flags are trusted values** | Attackers cannot modify these in secure environments |\n| 4 | **Resource management issues** (memory leaks, fd leaks) are NOT valid | Operational, not security |\n| 5 | **Tabnabbing, XS-Leaks, prototype pollution, open redirects** — do NOT report unless extremely high confidence | Subtle, low-impact, high false-positive rate |\n| 6 | **React\u002FAngular XSS** — safe unless `dangerouslySetInnerHTML`, `bypassSecurityTrustHtml`, etc. | Framework auto-escapes |\n| 7 | **GitHub Action workflow vulns** — verify concrete attack path before reporting | Most are theoretical |\n| 8 | **Client-side JS\u002FTS auth checks** — not a vuln; server is authoritative | Client code is untrusted |\n| 9 | **IPython notebook vulns** — only report if concrete untrusted-input trigger | Most are not exploitable |\n| 10 | **Logging non-PII data** — not a vuln even if sensitive. Only PII\u002Fsecrets\u002Fpasswords. | Intent: operational logging vs credential exposure |\n| 11 | **Shell script command injection** — only report if concrete untrusted-input path | Most shell scripts don't process untrusted input |\n\n## Confidence Scoring\n\nFindings that survive exclusions get a confidence score (1–10):\n\n| Range | Meaning | Action |\n|-------|---------|--------|\n| 9–10 | Certain exploit path, testable | Report as HIGH |\n| 8 | Clear vulnerability pattern | Report as HIGH\u002FMEDIUM |\n| 7 | Suspicious, needs conditions | Report as LOW or suppress |\n| \u003C7 | Too speculative | **Do not report** |\n\n**Hard threshold:** Only report findings with confidence ≥ 8.\n\n## Signal Quality Criteria\n\nFor remaining findings, assess:\n1. Is there a concrete, exploitable vulnerability with a clear attack path?\n2. Does this represent a real security risk (vs theoretical best practice)?\n3. Are there specific code locations and reproduction steps?\n4. Would this finding be actionable for a security team?\n\n---\n\n# Vulnerability Categories — Detection Guidance\n\nEach category: vulnerable pattern → safe pattern → code example.\n\n## SQL Injection\n\n| Aspect | Detail |\n|--------|--------|\n| **Vulnerable** | String interpolation in SQL queries: `f\"SELECT * FROM users WHERE id = {uid}\"` |\n| **CWE** | CWE-89 (SQL Injection) |\n| **Fixtures** | `fixtures\u002FCWE-89-sqli-positive.py` (flag) · `fixtures\u002FCWE-89-sqli-negative.py` (pass) |\n| **Safe** | Parameterized queries \u002F ORM: `cursor.execute(\"SELECT * FROM users WHERE id = %s\", (uid,))` |\n| **Look for** | f-strings, `+` concatenation, `format()` in query builders; raw SQL in ORM `.raw()` \u002F `.execute()` |\n| **False-positive guard** | Not a FP if the input is user-controlled (HTTP param, file, env var, CLI arg). Env vars are trusted (see exclusion rules). |\n\n## Cross-Site Scripting (XSS)\n\n| Aspect | Detail |\n|--------|--------|\n| **Vulnerable** | `element.innerHTML = userInput`, `dangerouslySetInnerHTML={{__html: userInput}}` |\n| **CWE** | CWE-79 (Cross-site Scripting) |\n| **Fixtures** | `fixtures\u002FCWE-79-xss-positive.js` (flag) · `fixtures\u002FCWE-79-xss-negative.js` (pass) |\n| **Safe** | `element.textContent = userInput`, React JSX (auto-escaped), template engines with auto-escaping |\n| **Look for** | `.innerHTML`, `document.write()`, `dangerouslySetInnerHTML`, `v-html` (Vue), `bypassSecurityTrustHtml` (Angular) |\n| **False-positive guard** | React\u002FAngular components without unsafe methods are NOT vulnerable (see exclusion rules). |\n\n## Server-Side Request Forgery (SSRF)\n\n| Aspect | Detail |\n|--------|--------|\n| **Vulnerable** | User-controlled URL passed to server-side HTTP client: `requests.get(user_url)` |\n| **Safe** | URL allowlist validation, internal-network blocking, protocol\u002Fhost restriction |\n| **Look for** | User input → `fetch`, `requests.get`, `axios.get`, `urllib`, `curl`, `http.get`; host control only (path-only is excluded) |\n\n## Command Injection\n\n| Aspect | Detail |\n|--------|--------|\n| **Vulnerable** | User input in shell commands: `os.system(f\"ping {host}\")`, `subprocess.run(f\"grep {pattern} file\", shell=True)` |\n| **Safe** | `subprocess.run([\"ping\", host])` with arguments as list; `shlex.quote()` |\n| **Look for** | `shell=True`, `os.system`, `os.popen`, `exec()`, `eval()`, `$()`, backticks |\n| **False-positive guard** | Shell scripts without untrusted user input are generally not exploitable. |\n\n## Authentication\u002FAuthorization Bypass\n\n| Aspect | Detail |\n|--------|--------|\n| **Vulnerable** | Missing auth check on protected endpoint; JWT without signature verification; hardcoded admin tokens |\n| **Safe** | Consistent auth middleware; JWT with `RS256`\u002F`HS256` verification; role-based access control |\n| **Look for** | Routes without auth decorators; `@login_required` \u002F `@require_auth` missing; JWT without `.verify()`; client-side auth checks only |\n\n## Unsafe Deserialization\n\n| Aspect | Detail |\n|--------|--------|\n| **Vulnerable** | `pickle.load(user_data)`, `yaml.load(user_input)`, `JSON.parse()` on untrusted tokens, `eval(input())` |\n| **Safe** | `yaml.safe_load()`, `json.loads()` (safe for JSON), `pickle.load(weights_only=True)` (PyTorch), schema validation |\n| **Look for** | `pickle.load`, `yaml.load` (not safe_load), `torch.load(weights_only=False)`, `eval`, `marshal.load`, `node-serialize` |\n\n## Path Traversal\n\n| Aspect | Detail |\n|--------|--------|\n| **Vulnerable** | User input in file paths: `open(f\"\u002Fdata\u002F{filename}\")`, `path.join(base, user_path)` |\n| **Safe** | Path normalization + prefix check: `os.path.realpath(path).startswith(BASE_DIR)`; allowlist of valid filenames |\n| **Look for** | `open()`, `read_file()`, `os.path.join` with user input; `..\u002F` traversal without normalization |\n\n## Insecure Direct Object Reference (IDOR)\n\n| Aspect | Detail |\n|--------|--------|\n| **Vulnerable** | API endpoint uses user-supplied ID without ownership check: `GET \u002Fapi\u002Forder\u002F{order_id}` — returns any user's order |\n| **Safe** | Ownership verification: verify `order.user_id == current_user.id` before returning data |\n| **Look for** | CRUD endpoints that accept IDs without authorization; horizontal\u002Fvertical privilege checks missing |\n\n## Weak Cryptography\n\n| Aspect | Detail |\n|--------|--------|\n| **Vulnerable** | MD5\u002FSHA1 for passwords; ECB mode; hardcoded keys; `random` module (not `secrets`); short key lengths |\n| **Safe** | `bcrypt`\u002F`argon2` for passwords; AES-GCM; `secrets` module; RSA 2048+; proper IV generation |\n| **Look for** | `md5`, `sha1`, `DES`, `ECB`, `PKCS1_v1_5`, `random` for crypto, hardcoded `key=`, `Crypto.Cipher` without AEAD |\n\n## Secrets Exposure\n\n| Aspect | Detail |\n|--------|--------|\n| **Vulnerable** | Hardcoded API keys, passwords, tokens in source code; secrets in logs; secrets in client-side code |\n| **Safe** | Environment variables; secret manager (AWS Secrets Manager, HashiCorp Vault); `.env` excluded from VCS |\n| **Look for** | `API_KEY=`, `password=`, `secret=`, `token=` in code; AWS keys, GitHub tokens, Stripe keys, JWTs in source |\n| **False-positive guard** | Secrets stored on disk but otherwise secured ARE excluded. Logging high-value secrets IS a vuln. Logging URLs is safe. |\n\n## Template Injection (SSTI)\n\n| Aspect | Detail |\n|--------|--------|\n| **Vulnerable** | User input in template rendering: `Template(user_input).render()`, `render_template_string(user_input)` |\n| **Safe** | Static templates; input passed as context variable, not template string |\n| **Look for** | `render_template_string`, `Template()()` with user string; `eval` in template context; `${user_input}` in JS template literals on server |\n\n## NoSQL Injection\n\n| Aspect | Detail |\n|--------|--------|\n| **Vulnerable** | User input in MongoDB queries: `db.users.find({username: user_input})` where input is `{\"$gt\": \"\"}` |\n| **Safe** | Schema validation; type checking on query params; ORM sanitization |\n| **Look for** | MongoDB `$where`, `$gt`, `$regex` from user input; raw mongo queries without type coercion |\n",{"name":5,"model":35,"description":7},"main","72f5e4c8b43f60cf86b37078ad8cd7e22daf67aa",".pi\u002Fskills\u002Fsecurity-review",24,"https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers","https:\u002F\u002Fdanielvm-git.github.io\u002Fbigpowers\u002F","https:\u002F\u002Fgithub.com\u002Fdanielvm-git","danielvm.net","2026-11-10 01:18:54",{"source":8,"skillName":5,"commands":59,"prompt":69,"zipAvailable":70},[60,63,66],{"tool":61,"command":62},"npx","npx skills add danielvm-git\u002Fbigpowers --skill security-review",{"tool":64,"command":65},"bunx","bunx skills add danielvm-git\u002Fbigpowers --skill security-review",{"tool":67,"command":68},"pnpm","pnpm dlx skills add danielvm-git\u002Fbigpowers --skill security-review","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002F.pi\u002Fskills\u002Fsecurity-review\u002FSKILL.md",true,[72,78,82,86,90,94,98,102,106,112,116],{"path":73,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":76,"sourceHtmlUrl":77},"fixtures\u002FCWE-639-idor-negative.go","SCRIPT","脚本",1471,"https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002F.pi\u002Fskills\u002Fsecurity-review\u002Ffixtures\u002FCWE-639-idor-negative.go",{"path":79,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":80,"sourceHtmlUrl":81},"fixtures\u002FCWE-639-idor-positive.go",1053,"https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002F.pi\u002Fskills\u002Fsecurity-review\u002Ffixtures\u002FCWE-639-idor-positive.go",{"path":83,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":84,"sourceHtmlUrl":85},"fixtures\u002FCWE-79-xss-negative.js",220,"https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002F.pi\u002Fskills\u002Fsecurity-review\u002Ffixtures\u002FCWE-79-xss-negative.js",{"path":87,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":88,"sourceHtmlUrl":89},"fixtures\u002FCWE-79-xss-positive.js",187,"https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002F.pi\u002Fskills\u002Fsecurity-review\u002Ffixtures\u002FCWE-79-xss-positive.js",{"path":91,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":92,"sourceHtmlUrl":93},"fixtures\u002FCWE-89-sqli-negative.py",348,"https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002F.pi\u002Fskills\u002Fsecurity-review\u002Ffixtures\u002FCWE-89-sqli-negative.py",{"path":95,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":96,"sourceHtmlUrl":97},"fixtures\u002FCWE-89-sqli-positive.py",330,"https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002F.pi\u002Fskills\u002Fsecurity-review\u002Ffixtures\u002FCWE-89-sqli-positive.py",{"path":99,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":100,"sourceHtmlUrl":101},"fixtures\u002FCWE-fail-open-verify-negative.sh",174,"https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002F.pi\u002Fskills\u002Fsecurity-review\u002Ffixtures\u002FCWE-fail-open-verify-negative.sh",{"path":103,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":104,"sourceHtmlUrl":105},"fixtures\u002FCWE-fail-open-verify-positive.sh",239,"https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002F.pi\u002Fskills\u002Fsecurity-review\u002Ffixtures\u002FCWE-fail-open-verify-positive.sh",{"path":107,"resourceType":108,"resourceTypeDesc":109,"sizeBytes":110,"sourceHtmlUrl":111},"REFERENCE-confidence-rubric.md","REFERENCE","参考文档",3383,"https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002F.pi\u002Fskills\u002Fsecurity-review\u002FREFERENCE-confidence-rubric.md",{"path":113,"resourceType":108,"resourceTypeDesc":109,"sizeBytes":114,"sourceHtmlUrl":115},"REFERENCE-false-positives.md",4446,"https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002F.pi\u002Fskills\u002Fsecurity-review\u002FREFERENCE-false-positives.md",{"path":117,"resourceType":108,"resourceTypeDesc":109,"sizeBytes":118,"sourceHtmlUrl":119},"REFERENCE-vuln-categories.md",5970,"https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002F.pi\u002Fskills\u002Fsecurity-review\u002FREFERENCE-vuln-categories.md",[121,141,148,176,198,219],{"skillNo":122,"name":123,"nameZh":6,"description":124,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":125,"categories":126,"keywords":132,"publishedAt":44},"01M71KBG9F8X644MJB16H4V8M7","skill-verify-fail-open-fixture","Negative-path fixture for run-skill-verify.sh — must never PASS.","https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002Fspecs\u002Fverifications\u002Ffixtures\u002Fskill-verify-fail-open\u002FSKILL.md",[127],{"categoryNo":128,"categoryName":129,"taxonomyType":130,"taxonomyTypeDesc":131},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[133,134,135,136,137,138,139,34,140],"fixture","open","verify","skill verify fail open fixture","skill verify","path","run","never",{"skillNo":142,"name":143,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":144,"categories":145,"keywords":146,"publishedAt":44},"01M71KBE3BKEMKNE0C5DGVDWZH","negative-path","https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002Fspecs\u002Fverifications\u002Ffixtures\u002Fnegative-path\u002FSKILL.md",[],[147,138],"negative path",{"skillNo":149,"name":150,"nameZh":6,"description":151,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":152,"categories":153,"keywords":157,"publishedAt":44},"01M71KBBGF7Y4EB4AMHBZ8CJFC","write-document","Write, organize, and sync high-integrity technical documents using the BMAD methodology. Ensures every document is Bold, Minimal, Actionable, and Durable. Use when creating architectural docs, technical guides, or organizing the specs\u002F directory.","https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002Fskills\u002Fwrite-document\u002FSKILL.md",[154],{"categoryNo":155,"categoryName":156,"taxonomyType":130,"taxonomyTypeDesc":131},"01JBSEEDCAT000000000000002","文档处理",[158,159,160,161,162,163,164,165,166,167,32,168,169,170,35,171,172,173,174,175],"write","write document","document","documents","actionable","technical","methodology","high","bmad","standard","when","minimal","bold","integrity","organize","sync","directory","guides",{"skillNo":177,"name":178,"nameZh":6,"description":179,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":180,"categories":181,"keywords":182,"publishedAt":44},"01M71KB8TM089JJD5AY5KAFSDM","wire-observability","Add structured JSON logging, observability commands, and idempotent setup scripts to a project. Use when a project needs production-readiness instrumentation, when user wants structured logging, or as a production-readiness gate at any phase of development.","https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002Fskills\u002Fwire-observability\u002FSKILL.md",[],[183,184,185,167,186,32,187,188,189,190,35,191,192,193,194,195,41,168,196,197],"observability","wire observability","readiness","commands","development","as","logging","add","instrumentation","at","structured logging","production-readiness","idempotent","project","scripts",{"skillNo":199,"name":200,"nameZh":6,"description":201,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":202,"categories":203,"keywords":204,"publishedAt":44},"01M71KB6CNRANP449DQA3NJZ96","wire-ci","CI pipeline setup with bundled, forge-neutral templates and local validation. Detects the forge from the git remote, generates workflows for supported forges, and skips honestly for the rest. The CI equivalent of wire-observability.","https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002Fskills\u002Fwire-ci\u002FSKILL.md",[],[205,206,207,208,209,210,211,212,213,214,215,167,216,34,183,35,217,218],"wire ci","ci","remote","local","pipeline","forge","validation","setup","templates","REST","with","ci pipeline setup","git","workflows",{"skillNo":220,"name":221,"nameZh":6,"description":222,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":223,"categories":224,"keywords":232,"publishedAt":44},"01M71KB2ZV98P03X88QR8MT9F1","visual-dashboard","Start a browser-based dashboard that visualizes architecture, implementation plans, and project status. Persists artifacts in .bigpowers\u002Fdashboard\u002F. Reads specs\u002Fstate.yaml, release-plan.yaml, epics, and planning-status via HTTP API or opencode panel.","https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002Fskills\u002Fvisual-dashboard\u002FSKILL.md",[225,228,229],{"categoryNo":226,"categoryName":227,"taxonomyType":130,"taxonomyTypeDesc":131},"01JBSEEDCAT000000000000013","分析与可视化",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":230,"categoryName":231,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000033","数据分析师",[233,234,235,236,237,238,239,240,241,35,242,39,243,244,245,246,247,196,248,249],"dashboard","visual","visual dashboard","status","artifacts","http","plans","planning","panel","start","opencode","plan","browser","api","architecture","project status","http api"]