| name | audit-scope |
| description | Generate a security audit scope document from one or more GitHub repo URLs and/or API access descriptions. Outputs a 3-line protocol narrative (mission, user story, attacker story) followed by a scope table with NSLOC, focus areas, and days. Use when scoping a new audit engagement.
|
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:
- One row per auditable component (repo or API surface)
- Lift-off discount row (if streak):
Lift-off discount (streak) | - | - | -0.5
- Similarity discount already baked into component days (no separate row)
- Report writing row:
Report writing | - | - | 1
- 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.
