security-audit

Audit a repository for vulnerabilities using two-pass discovery, triage, and structured reporting.

Updated Jul 9, 2026
One-click install
npx skills add https://github.com/akoita/agent-toolkit --skill security-audit-akoita
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: security-audit
Source: https://github.com/akoita/agent-toolkit/tree/main/plugins/claude/security/skills/security-audit
Command: npx skills add https://github.com/akoita/agent-toolkit --skill security-audit-akoita

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) and assets (resource) components.

What problem does it solve? Running a whole-repository security audit is unbounded and expensive, and raw scanner output is full of false positives. This Skill imposes a fixed, budget-aware audit order — scoped discovery, adversarial CWE-specific verification, deduplication, triage, and a controlled remediation lifecycle — so findings are evidence-backed and the report honestly states what was and was not covered. ## Core Features & Use Cases - Two-pass audit workflow: open-ended discovery for recall, then a CWE-specific second pass that demands proof of reachability and absence of mitigations before any candidate survives. - Shared severity and triage doctrine: a canonical severity/confidence rubric, KEV → EPSS → CVSS prioritization, suppression ordering, and anti-noise guardrails that keep reports credible. - Vulnerability lifecycle management: intake records, ownership assignment, controlled remediation with independent review, and p50/p90 patch-gap metrics via ready-to-use templates. - Use Case: Point the Skill at a service and its data layer, and it will scope the audit, preflight tools like opengrep, osv-scanner, gitleaks, and trivy, run the two-pass review, and produce a severity-ordered report with a tool coverage table and open questions. ## Quick Start Run a security audit of the authentication module on the current branch and produce a findings report with severity, evidence, and remediation recommendations.

Frequently Asked Questions about security-audit

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I run a security audit on an entire repository?▼

Define the in-scope paths, exclusions, and a cost ceiling first, then load security context, preflight tools like opengrep and osv-scanner, and run a two-pass review: open-ended discovery followed by CWE-specific verification requiring proof of reachability. Finish with deduplication, triage, and a structured report.

How do I reduce false positives from security scanners?▼

Treat every scanner alert as a lead, not a finding. Require a written attack path from attacker-controlled input to impact and verified absence of mitigations before promoting it; otherwise drop it or tag it theoretical and cap it at Medium severity.

When should I use security-audit versus security-review?▼

Use security-audit for a deep review of a whole repository or large subsystem. Use security-review when the unit of work is a pull request or diff, and use security-scan when the task is only running the deterministic toolchain.

Can I use Codex Security CLI or CodeCrucible with this audit workflow?▼

Yes, both are supported as optional external LLM scanners with documented install commands, flags, and exit-code behavior. Neither is required; a missing tool is recorded as a coverage gap rather than stopping the audit.

How are CVE findings prioritized during triage?▼

Rank by exploitation evidence rather than CVSS alone: CISA KEV membership is P0, EPSS ≥ 0.1 with CVSS ≥ 7 is P1, CVSS ≥ 9 is P2, and the rest go to the backlog. Reachability in your code outranks all of these.

What are the limitations of LLM-based vulnerability discovery?▼

Standalone LLM scanning shows 15 to 46 percent false-positive rates and inconsistent results across runs, so it is never used as a blocking gate or primary scanner. The model is strongest as a triage layer over deterministic tool output.