📦 deps(thirdparty): update snapshots
This commit is contained in:
@@ -43,15 +43,17 @@ Use the platform's equivalent capabilities while preserving the specified roles,
|
||||
|
||||
## Setup
|
||||
|
||||
Before starting, establish two paths:
|
||||
Before starting, establish two paths and one target identity:
|
||||
- **Target**: the codebase to audit (from the user's request or the current working directory)
|
||||
- **Output directory**: where all audit artifacts go. Ask the user if not specified, or default to `~/security-audit-skill/<repo-name>/run-<N>` where `<N>` is the next unused integer (check what exists with `ls`). Create it if it doesn't exist. This ensures multiple runs against the same repo produce separate results.
|
||||
- **Target identity**: the canonical physical repository path plus its normalized `origin` owner/repository URL. Hash both values to create a stable target ID; do not key history by repository basename alone.
|
||||
- **Output directory**: where all audit artifacts go. Ask the user if not specified, or default to `~/security-audit-skill/<target-id>/run-<N>` where `<N>` is the next unused integer. Create it if it doesn't exist. This ensures same-named repositories cannot share audit history.
|
||||
|
||||
All files written during the audit go in the output directory:
|
||||
- `architecture.md` — Phase 1 output, fed into Phase 2 agent prompts
|
||||
- `REPORT.md` — human-readable report (Phase 4)
|
||||
- `FINDINGS-DETAIL.md` — detailed data flows for MEDIUM+ findings (Phase 4)
|
||||
- `findings.json` — machine-readable structured output (Phase 5)
|
||||
- `target.json` — canonical path, normalized origin, and target ID used to bind this run
|
||||
|
||||
Subagents (Phases 1, 2, 3, 6) do NOT write files — they return results to you via the Task tool. You are responsible for writing all files to the output directory.
|
||||
|
||||
@@ -59,7 +61,7 @@ Subagents (Phases 1, 2, 3, 6) do NOT write files — they return results to you
|
||||
|
||||
Each audit run explores different code paths depending on which agents find what and where they dig. No single run finds everything. Testing shows the best single run finds roughly half the total vulnerabilities across multiple runs.
|
||||
|
||||
**If prior runs exist** for the same repo (check `~/security-audit-skill/<repo-name>/`), read their `findings.json` files before starting Phase 2. Use them to:
|
||||
**If prior runs exist** for the exact target ID, first require their `target.json` canonical path and normalized origin to match the current target byte-for-byte. Treat missing or mismatched manifests as unrelated and never read or summarize their findings. Do not search or reuse prior runs from a basename-only directory. After that identity check, read matching `findings.json` files before starting Phase 2. Use them to:
|
||||
1. **Skip known findings** — don't waste agents re-discovering the same status bypass. Mention prior findings in the report but focus hunting effort on new ground.
|
||||
2. **Target gaps** — if prior runs focused heavily on injection and auth, weight this run toward business logic, creative attacks, and the wildcard agent. If prior runs missed public endpoints, focus there.
|
||||
3. **Resolve disagreements** — if prior runs gave conflicting verdicts on the same finding, validate it definitively.
|
||||
|
||||
+2
@@ -2,6 +2,8 @@
|
||||
|
||||
### Phase 1: Understand the application
|
||||
|
||||
Before using prior-run context, verify the current run's `target.json` against the candidate run: canonical physical path, normalized origin owner/repository URL, and derived target ID must all match exactly. A repository basename is never a target identity. Ignore mismatched or missing manifests rather than importing their findings.
|
||||
|
||||
Before looking for bugs, understand what you're auditing. This requires depth, not just a directory listing. Launch **multiple `research` agents in parallel** to map different aspects of the codebase:
|
||||
|
||||
**Agent 1a: Overview, tech stack, and comparable baseline**
|
||||
|
||||
Reference in New Issue
Block a user