absolute-audit

3 files shipped with this skill. Inline text is the catalog copy. The upstream link is the source repository.

• skills/absolute-audit/SKILL.md4.6 KB30b5aa51481bupstream ↗

  ---
  name: absolute-audit
  version: 0.5.0
  description: >
    Vulnerability and security scan (defensive, your own repo): dependency CVEs plus risky code patterns (secrets, injection, weak authz), severity x reachability triaged and remediated without suppressing. Complements the built-in /security-review.
    Triggers on "absolute audit", "security audit", "are we vulnerable", "scan for CVEs", "check for secrets/injection", "harden this".
  category: workflow
  tags:
    - workflow
    - security
    - audit
    - vulnerabilities
    - cve
  platforms:
    - claude-code
    - gemini-cli
    - openai-codex
    - mcp
  user-invocable: true
  argument-hint: "[target]"
  license: MIT
  maintainers:
    - github: maddhruv
  ---
  
  > Start your first response with the 🔒 emoji.
  
  ## Absolute Audit
  
  Find and triage security problems across the repo — vulnerable dependencies (CVEs) and
  risky code patterns — then fix the ones worth fixing, safely. Output is a severity-ranked
  findings table with a remediation per item, not a raw scanner dump.
  
  Runs the shared engine in **`references/health-engine.md`** — read it for the
  DETECT → SCAN → TRIAGE → FIX → VERIFY → REPORT loop and the safety contract. This file
  covers only what's specific to security auditing.
  
  > **Authorized defensive use.** This command audits the user's *own* repository to find
  > and fix weaknesses. It is for hardening, not for attacking systems or evading detection.
  
  ---
  
  ## When to use
  
  - "Run a security audit", "are we vulnerable?", "check our deps for CVEs".
  - After a CVE disclosure affecting something you use.
  - Periodic hygiene on `main`.
  
  Distinct from the built-in **`/security-review`** (reviews the *pending diff* on your
  branch) — `audit` scans the **whole committed repo**, deps included. They complement.
  
  ---
  
  ## What it scans
  
  **1. Dependency vulnerabilities (CVEs)** — primary:
  
  | Ecosystem | Scanner |
  |---|---|
  | npm / pnpm / yarn | `npm audit --json` / `pnpm audit --json` / `yarn npm audit --json` |
  | Python | `pip-audit` (preferred) or `safety check` |
  | Go | `govulncheck ./...` |
  | Cross-language | `osv-scanner` against the lockfile if available |
  
  **2. Code-level patterns** — read-only grep/static pass for high-signal issues only:
  hardcoded secrets/keys/tokens, `eval`/dynamic exec on input, SQL built by string
  concatenation, missing authz checks on sensitive routes, disabled TLS verification, unsafe
  deserialization, overly-broad CORS. Prefer the project's existing SAST/linter security
  rules (`eslint-plugin-security`, `bandit`, `gosec`) if configured.
  
  Report suspected leaked secrets but **never print the secret value** — reference
  `path:line` and the kind.
  
  ---
  
  ## Risk ranking (TRIAGE)
  
  Rank by **severity × exploitability × reachability**, not raw CVSS:
  
  | Severity | Default |
  |---|---|
  | Critical / High, reachable, fix available | fix now (wave 1) |
  | Moderate, reachable | fix this pass |
  | Low / not reachable from app code | report, usually defer |
  | Transitive-only, no direct upgrade path | flag, note the blocking parent |
  
  Mark each: is it reachable from the app's actual code paths? A CVE in an unused transitive
  branch is lower priority than a Moderate one on a hot path. State the fixed version or the
  mitigation for each.
  
  ---
  
  ## Fix & verify
  
  - **Dep CVEs** → resolve via the smallest version move that clears it (delegate the actual
    bump mechanics to the `upgrade` flow's per-ecosystem steps). Prefer patched minors;
    escalate to a major only when that's the only fix, and gate it.
  - **Code issues** → apply the concrete fix (parameterize the query, move the secret to env
    + flag the leaked one for rotation, add the authz check). Each fix is its own small wave.
  - After each wave, re-run the scanner: the finding must actually disappear, and tests/build
    stay green. Never resolve by suppressing/allowlisting the alert.
  - Leaked live secrets: flag for **rotation** — removing from code doesn't undo exposure.
  
  ---
  
  ## Gotchas
  
  1. **Audit fatigue → blanket ignore.** Triage by reachability instead of muting the scanner.
  2. **Fixing a CVE by suppressing it.** An allowlisted advisory is still a vulnerability.
  3. **Printing the secret.** Reference location + type only; never echo the value.
  4. **Deleting a secret from code ≠ safe.** It's in git history and was exposed — rotate it.
  5. **Stopping at deps.** Many real issues are in code, not the dependency tree — run both passes.
  
  ---
  
  ## Companion commands
  
  - **`/absolute upgrade`** — does the actual version moves for vulnerable deps.
  - **`/security-review`** (built-in) — pair with this to also cover your pending diff.
  - **`/absolute work`** — if remediation is a real refactor (e.g. replacing an auth flow), hand off.
  

• skills/absolute-audit/README.md814 Bc9780578048dupstream ↗

  # absolute-audit
  
  Vulnerability and security scan for your own repo. Finds dependency CVEs plus risky code patterns (secrets, injection, weak authz), triages by severity × reachability, and remediates without suppressing.
  
  ## Quick Facts
  
  | Field | Value |
  |-------|-------|
  | Category | workflow |
  | Version | 0.5.0 |
  | Platforms | claude-code, gemini-cli, openai-codex, mcp |
  | License | MIT |
  
  ## How to Install
  
  ```bash
  npx skills add maddhruv/absolute-audit
  ```
  
  ## Usage
  
  ```bash
  /absolute-audit "Scan the repo for vulnerable deps and security issues"
  /absolute-audit "Are we vulnerable to any CVEs?"
  ```
  
  Authorized defensive use — audits your own repository. Complements the built-in `/security-review` (which reviews the pending diff).
  
  ## Maintainers
  
  - [@dhruvjainin](https://github.com/dhruvjainin)
  

• skills/absolute-audit/references/health-engine.md5.3 KBb9448a1df179upstream ↗

  <!-- Shared engine for absolute's engineering-health commands: `upgrade`, `audit`, `prune`, `debt`, `deflake`. NOT a command itself — each of those command flows loads this file for the common loop + safety rules. Keep it command-agnostic; edits here affect all five. -->
  
  # Engineering-Health Engine (shared)
  
  The five engineering-health commands — `upgrade`, `audit`, `prune`, `debt`, `deflake` —
  all run the **same loop** on a green `main`. Only *what they scan for* and *how they
  fix it* differ. This file is that shared loop and the safety contract. Each command's
  own reference (`references/<command>.md`) covers the part that's specific to it: what to
  detect, which tools to run per ecosystem, and how to risk-rank findings.
  
  ```
  DETECT ─→ SCAN ─→ TRIAGE (gate) ─→ FIX (safe waves) ─→ VERIFY ─→ REPORT
  ```
  
  These commands are **standing-health** work on the whole repo, distinct from `simplify`
  (which polishes *your working diff*) and the built-in `/security-review` / `/code-review`
  (which review *pending changes*). They operate on committed, green code.
  
  ---
  
  ## Shared principles
  
  1. **Start from green.** Run the project's tests/build first. If `main` is already red,
     stop and surface it — don't pile health changes onto a broken tree.
  2. **Gate before fixing.** Always present risk-ranked findings and get an explicit "go"
     before changing anything. Findings ≠ a mandate to fix everything.
  3. **Safe waves.** Apply fixes lowest-risk first, in batches that can be independently
     verified and reverted. Re-run checks between waves. When unsure, smaller waves.
  4. **Bounded scope.** Fix only what the command targets. Adjacent problems → report as
     deferred, don't absorb them.
  5. **No cheating the gate.** Never silence a check to make it pass — no `@ts-ignore`,
     `eslint-disable`, `# type: ignore`, `--no-verify`, skipped tests, or pinning a vuln
     scanner to "ignore". Fix it or defer it.
  6. **Never auto-commit.** Apply to the working tree, report, suggest a commit/PR per wave;
     the user commits.
  
  ---
  
  ## Step 1 — DETECT
  
  Auto-detect the stack so every command speaks the project's real tools. If
  `.absolute.config.json` or `~/.absolute/config.json` exists (from `/absolute init`), resolve
  the effective config (project file → global `projects["<cwd>"]` → global `defaults`), read
  its cached `conventions` first, and skip re-detection; otherwise use the **Codebase
  Convention Detection** table in `references/work.md` (package manager, language/runtime,
  test runner, linter/formatter, build, CI, available scripts).
  
  Also surface `preferences.health.*` to the command flow when present: `protectedPaths`
  (never-delete globs `prune` honors) and `deflakeRuns` (default repeat-run count for
  `deflake`). `preferences.autonomy` continues to gate whether safe waves auto-apply.
  
  Always drive fixes through the project's own scripts (`npm test`, `make lint`), never raw
  tools, so results match CI. Note the ecosystem(s) — each command reference lists the
  concrete commands per ecosystem (JS/TS, Python, Go).
  
  ---
  
  ## Step 2 — SCAN
  
  Run the command-specific read-only scan (see each command's reference). Produce a raw
  findings list. Do not change anything yet. Capture the exact tool output — it's the
  evidence in the report and the baseline to diff against after fixing.
  
  ---
  
  ## Step 3 — TRIAGE (gate)
  
  Turn raw findings into a **risk-ranked table** and present it. Generic shape:
  
  | # | Finding | Risk | Effort | Recommend |
  |---|---|---|---|---|
  | 1 | … | low / med / high | S / M / L | fix now / defer / skip |
  
  Rank by blast radius and reversibility, not by count. Group obviously-safe items into a
  first wave. Call out anything risky (major version bumps, breaking removals, behavioral
  test changes) explicitly.
  
  **━━ GATE: user picks which findings/waves to apply before any change. ━━**
  
  ---
  
  ## Step 4 — FIX (safe waves)
  
  Before touching files: ensure the tree is clean (commit or stash) and record the current
  commit hash as the rollback point. Then apply the approved findings in waves, lowest-risk
  first. Reuse the safe-wave mechanics in `references/work/execution-model.md` (disjoint,
  independently verifiable batches; serialize when in doubt).
  
  One concern per wave. Keep each wave small enough to revert cleanly if VERIFY fails.
  
  ---
  
  ## Step 5 — VERIFY
  
  After each wave, run the project's real signals — test, lint, typecheck, build — through
  its own scripts. Any failure: revert that wave (or fix-forward if trivial and obvious),
  never paper over it. For risky waves, use the generator-evaluator check in
  `references/work/verification-framework.md`. The bar is "green, the honest way."
  
  ---
  
  ## Step 6 — REPORT
  
  Summarize: what was scanned (with tool versions/output), what changed (per wave, with
  diffs/line counts), what was deliberately deferred and why, and the before/after signal
  state. End with copy-pasteable verification steps and a suggested commit/PR message per
  wave. **Never run `git commit` yourself.**
  
  ---
  
  ## Output / Response Style
  
  Respond terse like smart caveman. Technical substance stays exact; code blocks and quoted
  errors unchanged. Drop caveman for security warnings, irreversible-action confirmations
  (deleting code, removing deps, major version bumps), and multi-step sequences where order
  matters — resume after. Findings tables and reports stay normally formatted.
  

Plain-text copy, no login: /skill-bundles/dhruvjainin-absolute-skills-absolute-audit.md