# Codebase Security Audit > >- - **Type:** Skill - **Install:** `agentstack add skill-quant-off-skills-codebase-security-audit` - **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior - **Seller:** [Quant-Off](https://agentstack.voostack.com/s/quant-off) - **Installs:** 0 - **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills) - **Latest version:** 0.1.0 - **License:** MIT - **Upstream author:** [Quant-Off](https://github.com/Quant-Off) - **Source:** https://github.com/Quant-Off/skills/tree/main/plugins/codebase-security-audit/skills/codebase-security-audit ## Install ```sh agentstack add skill-quant-off-skills-codebase-security-audit ``` Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent. ## About # Codebase Security Audit Finding the dangerous sink is the mechanical step. The real work is proving an attacker reaches it with data they control, and that no validator breaks the chain. **A pattern match is a worklist entry, not a vulnerability**, and reporting one as a finding is the primary failure mode of this skill. Operate under zero trust: assume every external input is hostile and every trust boundary is crossed. Then prove it, per finding, with a traced flow. ## When to Use - A security audit of a repository, service, module, or single file. - A pre-release or pre-merge security pass on a diff. - Threat-modeling an application's attack surface. - Triaging whether a suspected issue is real before filing it. - Hardening review for a high-assurance, regulated, or air-gapped deployment. ## When NOT to Use - **Cryptographic implementation review.** Constant-time behavior, zeroization, and primitive misuse need `crypto-source-audit`. - **Compiled-artifact verification.** Use `binary-crypto-verify`. - **Runtime testing.** This skill reads code. It does not fuzz, scan a live host, or execute exploits. - **Pure code quality review.** Style, naming, and architecture are out of scope unless they create a security consequence. ## Rationalizations to Reject | Rationalization | Why it is wrong | Required action | | --- | --- | --- | | "This pattern is dangerous, so it is a vulnerability." | Pattern recognition is not analysis. Most `exec` and `query` hits take trusted input. | Trace source to sink before concluding. No trace, no finding. | | "I cannot find the sanitizer, so there is none." | Validation is often centralized in middleware, a framework hook, an ORM layer, or a base class. | Read the framework's request pipeline and the callers before reporting. | | "This is clearly critical." | Models overrate severity and are biased toward seeing bugs. | Apply the severity rubric mechanically. Justify the rating against its criterion. | | "The endpoint is internal, so it is safe." | Internal means undocumented, not unreachable. SSRF, a compromised pod, or a misrouted ingress reaches it. | State the required attacker position instead of dismissing the finding. | | "There is authentication, so authorization is covered." | Authentication proves who; authorization proves whether. IDOR lives in exactly this gap. | Check ownership on every object accessed by a user-supplied identifier. | | "It needs admin, so severity is Low." | Privilege is a precondition, not an exemption. Admin compromise is a normal step in a chain. | Rate on impact, note the precondition. | | "The library handles that." | Libraries have unsafe defaults and unsafe modes. `yaml.load` and `pickle.loads` are library calls. | Confirm the specific call and its configuration. | | "It is only exploitable in a weird config." | If the config ships, it is real. If it is the default, it is worse. | Check the shipped defaults and state which config is affected. | | "I will report everything and let them filter." | An unvalidated list of grep hits destroys the credibility of the real findings. | Every reported item passes the gates below or is not reported. | | "The tests pass, so it is fine." | Tests encode expected behavior. Attackers supply unexpected behavior. | Test coverage is not evidence of safety. | ## Workflow ### Phase 0: Map the attack surface **Exit:** a written list of entry points, trust boundaries, and where secrets and privileged operations live. ```bash ast-outline digest . # module map; or `ast-outline map ` for one file # Entry points and untrusted input rg -n "fn main|func main|def main|public static void main" -tcode rg -n "app\.(get|post|put|patch|delete)|@(Get|Post|Put|Delete)Mapping|@app\.route|router\.(get|post)" -tcode rg -n "argv|getenv|req\.(body|query|params|headers)|request\.(GET|POST|args|json)|Deserialize|read_to_string|recv\(" -tcode ``` Record: which inputs are authenticated, which are raw, which components cross a privilege boundary, and where the sensitive data lives. Everything downstream is scoped to this map. Do not audit code no untrusted input reaches. ### Phase 1: Sweep by bug class Read the catalogue when you reach it. It carries the sink lists, the grep patterns, and the class-specific triage questions. | Area | Reference | | --- | --- | | Injection, deserialization, path traversal, SSRF, XSS, CSRF | [references/bug-classes.md](references/bug-classes.md) | | Authentication, authorization, IDOR, session and token handling | [references/authz-and-identity.md](references/authz-and-identity.md) | | Secrets, memory safety, concurrency, dependency and supply chain | [references/secrets-and-memory.md](references/secrets-and-memory.md) | | Per-language sinks and idioms (Python, JS/TS, Go, Rust, Java, C/C++, PHP, Ruby) | [references/language-sinks.md](references/language-sinks.md) | Crypto hits during this sweep (weak primitives, static IVs, `memcmp` on a MAC, non-CSPRNG tokens) are handed to `crypto-source-audit` rather than analyzed here. ### Phase 2: Trace each candidate For every hit, write the flow explicitly. This is the work. ``` source: POST /api/report body field `filename` (untrusted, unauthenticated) -> ReportController.create():41 no validation -> ReportService.render():88 passed as `template_path` -> sink: fs.readFileSync(path.join(TEMPLATE_DIR, template_path)) render.js:88 mitigation searched: no canonicalization, no allowlist, no boundary check ``` If you cannot write the flow, you do not have a finding. Record the item as inspected and dismissed with the reason. ### Phase 3: Gate before reporting Every candidate passes all six gates or it is not reported. Full criteria and worked examples are in [references/validation-gates.md](references/validation-gates.md). | # | Gate | Passes when | | --- | --- | --- | | 1 | Source is untrusted | The input crosses a trust boundary from an attacker-influenced origin | | 2 | Reachability | A concrete request or invocation path reaches the sink | | 3 | Attacker control | The attacker controls enough of the value to change behavior | | 4 | No mitigation | No validator, encoder, parameterization, or authz check breaks the chain | | 5 | Real impact | Exploitation yields RCE, privilege escalation, data disclosure, integrity loss, or denial of service | | 6 | Devil's advocate | You attempted to refute the finding and failed | Verdict line for each candidate: `CANDIDATE #N TRUE POSITIVE: ` or `CANDIDATE #N FALSE POSITIVE: `. ### Phase 4: Report Rank by severity, and state what you did not cover. ## Severity rubric Rate on impact and precondition, not on how alarming the code looks. Align with CVSS 3.1 intuition. | Severity | Criterion | | --- | --- | | Critical | Unauthenticated RCE, authentication bypass, or mass exfiltration of sensitive data. No meaningful precondition. | | High | Authenticated RCE, IDOR exposing other users' sensitive data, stored credential or key disclosure, privilege escalation to admin. | | Medium | Stored or reflected XSS, SSRF with limited reach, CSRF on a state-changing action, weak crypto protecting live data, DoS reachable by a normal user. | | Low | Information disclosure with no direct leverage, missing hardening header, verbose errors, defense-in-depth gaps. | | Info | No security consequence. Hygiene only. | Do not invent a severity between tiers. Pick the tier whose criterion the finding meets and justify it in one sentence. ## Report format Lead with a one-paragraph verdict on overall risk posture and a severity tally. Then, most severe first: ``` [SEVERITY] confidence: confirmed|likely Location : path/to/file:line-line Class : injection | authz | secrets | memory | deserialize | ssrf | deps | ... CWE : CWE-xxx Flow : untrusted source -> intermediate -> sink (with file:line at each hop) Trigger : the concrete input or request that exploits it Impact : what the attacker gains, and the precondition required Evidence : the specific code that is wrong, quoted Gates : 1-6 pass, with the one-line justification for gate 5 and gate 6 Fix : the specific remediation. Never "sanitize input" or "validate." ``` Close with three lists: - **Cleared**: high-risk areas inspected and found sound, each citing the file:line of the control that makes it sound. No entry without that citation. - **Dismissed**: candidates that failed a gate, with the gate number. This is what separates an audit from a grep dump. - **Not covered**: out-of-scope areas, code paths you could not follow, and anything needing dynamic testing or credentials you did not have. State this plainly so the gap is not mistaken for a clean bill of health. ## Limitations 1. **Static reading only.** No execution, no fuzzing, no live testing. Findings are analytical and unproven at runtime. 2. **No interprocedural data flow engine.** Traces are done by reading code. Dynamic dispatch, reflection, function pointers, message queues, and RPC boundaries will break a trace. State where. 3. **Framework behavior is assumed, not verified.** Where a mitigation is claimed to live in framework middleware, that middleware is not audited. 4. **Dependencies are checked by version, not by review.** A clean advisory database says nothing about an unreported vulnerability. 5. **Configuration and deployment are usually out of tree.** Infrastructure, secrets management, and network policy shape real exploitability and are not visible here. 6. **Absence of findings is not absence of vulnerabilities.** Say so in the report. ## References - CWE Top 25 Most Dangerous Software Weaknesses; OWASP Top 10 (web) and OWASP API Security Top 10. - CVSS 3.1 specification for severity calibration. - CWE-89 (SQLi), CWE-78 (OS command injection), CWE-79 (XSS), CWE-22 (path traversal), CWE-502 (unsafe deserialization), CWE-918 (SSRF), CWE-639 (IDOR), CWE-798 (hardcoded credentials), CWE-416 (use after free), CWE-190 (integer overflow), CWE-362 (race condition). ## Source & license This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code. - **Author:** [Quant-Off](https://github.com/Quant-Off) - **Source:** [Quant-Off/skills](https://github.com/Quant-Off/skills) - **License:** MIT Install and usage instructions live in the source repository linked above. ## Pricing - **Free** — Free ## Security capabilities Automated source analysis of v0.1.0 — what this tool can access: - **Network access:** no - **Filesystem access:** yes - **Shell / process execution:** no - **Environment & secrets:** yes - **Dynamic code execution:** no *"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.* ## Versions - **0.1.0** — security scan: passed — Imported from the upstream source. ## Links - Listing page: https://agentstack.voostack.com/l/skill-quant-off-skills-codebase-security-audit - Seller: https://agentstack.voostack.com/s/quant-off - Browse the marketplace: https://agentstack.voostack.com/browse --- Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.