# absolute-audit

Adopt this skill: https://proskills.md/skills/workflow/dhruvjainin-absolute-skills-absolute-audit

Page: https://proskills.md/skills/workflow/dhruvjainin-absolute-skills-absolute-audit
This document is the public skill bundle for that page. It contains SKILL.md and every helper file the catalog carries. No login is required.

## File: skills/absolute-audit/SKILL.md
size: 4722
sha: 30b5aa51481b9552dadd50121425c0f7754a295e
upstream: https://github.com/dhruvjainin/absolute/blob/main/skills/absolute-audit/SKILL.md

```text
---
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.
```

## File: skills/absolute-audit/README.md
size: 814
sha: c9780578048d85f2a3982462c258062be38732e1
upstream: https://github.com/dhruvjainin/absolute/blob/main/skills/absolute-audit/README.md

````text
# 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)
````

## File: skills/absolute-audit/references/health-engine.md
size: 5408
sha: b9448a1df1793c99fa62d0ea90b245d59cb79f50
upstream: https://github.com/dhruvjainin/absolute/blob/main/skills/absolute-audit/references/health-engine.md

````text
<!-- 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.
````