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:

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).

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.