audit-scope

# Audit Scope Skill ## Inputs User provides one or more of: - GitHub repo URL(s) - API documentation / access description (no repo) - Named scope components (e.g. "also include the webhook service") No report-days input needed - report writing is hardcoded (see Constants). ## Constants (hardcoded, never ask user) - **Report writing**: always 1 day Scope is measured in days. Do not attach monetary amounts to the output - days are the unit of measurement here. ## Step-by-step execution ### 1. Ingest repos For each GitHub repo URL provided: - Clone to `/tmp/<repo-name>-audit` via `gh repo clone` - Run `cloc <repo> --quiet --not-match-f="(?i)(spec|test)" --not-match-d="(test|spec|__tests__|__mocks__)" --include-lang=TypeScript,JavaScript,Kotlin,Java,Go,Python,Rust,Solidity,HCL` (exclude test/spec files and dirs, case-insensitive; adjust `--include-lang` for the repo's stack) - Record NSLOC per repo (source lines only - exclude test/spec files, Markdown, YAML, Gradle, shell) - Never estimate NSLOC manually - always run cloc For API-only scope (no repo): - NSLOC = N/A - Estimate days from endpoint count and complexity description ### 2. Explore repo structure Read enough to understand: - What the component does (SDK? API server? webhook handler?) - Core tech: cryptographic primitives, auth mechanisms, external dependencies - Language-specific security surface (JVM, Node, etc.) - Key files: entry point, signing/crypto logic, error handling, config/env ### 3. Identify discounts Apply these automatically - do not ask user: | Condition | Discount | |---|---| | Multiple repos audited back-to-back (streak) | -0.5d lift-off discount | | Multiple repos share same domain/features (similarity) | -20-35% off affected component's days | | Spec/rules doc in scope alongside backend that implements it | -1-2d off backend (domain fluency pre-built) | Lift-off discount = negative row in table (streak saves ramp time). Similarity discount = **bidirectional** - applies whenever two components share significant overlapping attack surface, regardless of order. E.g. SDKs and backend sharing the same signing/API domain discount each other: SDKs get discounted because backend covers the server-side of the same flow; backend gets discounted because SDK work already mapped the signing trust boundary. Bake into the component day estimate directly (no separate row). ### 4. Estimate days per component Base pace: ~300-400 NSLOC/day for deep manual security audit. Adjust for: - Cryptographic code: slower (~200 NSLOC/day) - Boilerplate-heavy languages (Kotlin, Java): filter ~30% noise - Framework-heavy TS backends (NestJS, etc.): DTOs, decorators, module definitions don't need line-by-line audit - pace ~400-500 NSLOC/day for those layers - Narrow attack surface (signer-only, no HTTP): faster - Wide attack surface (HTTP API, DB, auth): slower **Do not pace all NSLOC uniformly. First split the repo into trust-boundary vs non-audited code, then only price the trust boundary at audit depth.** Raw cloc NSLOC != auditable NSLOC. This is the #1 source of overquoting - especially on web frontends, where most lines are presentational or read-only. - **Excluded entirely (not in NSLOC, not priced):** presentational React/Vue UI, charts, visualizers, layout/page JSX, styles, assets. These have no trust boundary. On a frontend this is often 60-80% of cloc's count. - **Skim only (~0.5d flat, not per-NSLOC):** read-only data-fetch and display logic - react-query hooks that fetch stats, `*Stats` mappers, APY/TVL math that only feeds charts, zustand stores, config/utils. Skim for leaked secrets, injection into outbound requests, and any value that feeds transaction sizing - then move on. Do NOT read line-by-line. - **Full audit depth:** the actual trust boundary - transaction/instruction construction, signing & approval flow, output/slippage guards, auth, proxy/SSRF surface, input validation on server routes. This is usually a minority of the lines but where all the findings are. **Contract/SDK out of scope -> frontend crypto pace is faster, not slower.** If the on-chain program or signing SDK lives in a separate repo (imported dependency, not vendored), the frontend only *orchestrates* pre-built instructions. Don't apply the ~200 NSLOC/day crypto pace to it - the frontend can only validate at the guard layer, so those passes are firm but quick. Flag the separate contract/SDK repo as its own potential line item (that's where fund-safety bugs actually live). ### 4b. Sanity-check against common scope sizes Before finalizing days, compare against typical engagement sizes below. These are calibration anchors - if a NSLOC-derived estimate lands well outside the range for its type, re-check the tiering in step 4 (usually display/read-only code priced at audit depth). | Engagement type | Typical days | |---|---| | Red team engagement | ~10-25 | | Security tool development services | ~15-20 | | Cloud misconfiguration review | ~8-12 | | Secure code review | ~10 | | Low-level secure code review | ~10 | | Web app penetration test | ~5-8 | | Android app pentest | ~5 | | SDK secure code review | ~3-5 | | Miniapp with lean backend | ~3-4 | | Incident response | ~2-5 | | 2-day custom training (build time) | ~20 | Web/frontend protocol audits track the "web app pentest" row (5-8d), not "secure code review" (~10d), unless the frontend vendors its own contracts/signing code. ### 5. Build narrative (3 lines, before table) **Line 1 - Protocol mission + why audit needed:** `<Protocol name> is a <what it does>. <Scope components> are/is <role in system> - <why a flaw here = business impact>, making it <risk framing for the engagement>.` Scope components must be woven into this line with clear business justification for auditing them. **Line 2 - User story:** `A <user type> <does X> - <SDK/component> <does Y> and <delivers Z to downstream system>.` **Line 3 - Attacker story + incentives:** `Attacker targets <attack surface> to <attack goal> - enabling <business-critical impact e.g. fund theft, unauthorized access, data breach>.` ### 6. Build scope table Columns: `Component | NSLOC | Focus Areas | Days` Row order: 1. One row per auditable component (repo or API surface) 2. Lift-off discount row (if streak): `Lift-off discount (streak) | - | - | -0.5` 3. Similarity discount already baked into component days (no separate row) 4. Report writing row: `Report writing | - | - | 1` 5. **Total** row: sum all days Focus areas per component: - Name the specific crypto primitives, key-handling patterns, auth mechanisms, serialization paths, and language-specific risks - 4-6 items, comma-separated ### 7. Output Print narrative (3 lines), blank line, then table. Nothing else. ## Example output shape **Protocol:** Acme is a payments infrastructure API enabling businesses to move digital assets across chains. The SDKs (`sdk-lang1`, `sdk-lang2`) are the sole cryptographic trust boundary between a business's private keys and the Acme API - any signing flaw directly enables fund theft or unauthorized wallet creation, making them the highest-risk component in the integration stack. **User story:** A fintech backend creates a wallet and signs a transaction step - the SDK constructs and stamps the activity payload locally, returning a signature the app posts to the Acme API. **Attacker story & incentives:** Attacker targets the private key or signing flow to forge activity stamps - enabling unauthorized wallet creation or hijacking transactions to redirect funds to attacker-controlled addresses. --- ## Expected output table example: | Component | NSLOC | Focus Areas | Days | |---|---|---|---| | sdk-lang1 audit | 943 | P-256 stamp construction, key isolation, body serialization, input validation, logger redaction | 1.5 | | sdk-lang2 audit (similarity discount) | 1,764 | Signing parity with sdk-lang1, JVM key handling, coroutine error propagation, serialization safety | 2 | | Lift-off discount (streak) | - | - | -0.5 | | Report writing | - | - | 1 | | **Total** | **2,707** | | **4** | ## Edge cases - **Single repo, no streak**: no lift-off row, no similarity discount - **3+ repos**: apply lift-off once (-0.5d), apply similarity discount to each repo after the first - **API-only scope**: NSLOC = N/A, days from endpoint/complexity estimate, note estimation method - **Mixed repo + API**: repo gets cloc, API gets endpoint-based estimate; both in same table - **Web/frontend repo**: expect raw cloc to be dominated by presentational UI. Report NSLOC as the auditable surface (trust boundary + skim), not raw cloc, and say so. The trust boundary is: what the app builds & signs, output/slippage guards, wallet/session handling, and any server/proxy routes (SSRF, allowlists, rate-limit, secret exposure). A frontend audit is typically 4-6 days even at 20k+ raw NSLOC; if the estimate exceeds that, check whether display/read-only code got priced at audit depth.