Skip to content
Back to skills

Audit Security

ASecurity

Use when asked to review a repo's security, before a release or go-live, or after adding auth, uploads, or a new integration. Scans secrets, dependencies, authz, headers and CI supply chain against security-baseline.md; reports ranked findings, fixes only what is approved.

  • 5 stars
  • 0 votes
  • 0 copies
  • 1 view
  • Added October 10, 2026
developmentgobashdockergitapidatabasefrontendbackendci/cdsecurity

Works with

  • api

Security analysis

A100/100

Pro scans all 2 files and shows the line behind each finding

Scanned October 10, 2026

npx -y skills add VelimirMueller/lab-claude-skills --skill audit-security --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Audit Security?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Audit Security
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/velimirmueller-audit-security/badge)](https://www.skillsdirectory.com/skills/velimirmueller-audit-security)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: audit-security
description: Use when asked to review a repo's security, before a release or go-live, or after adding auth, uploads, or a new integration. Scans secrets, dependencies, authz, headers and CI supply chain against security-baseline.md; reports ranked findings, fixes only what is approved.
---

# Audit Security

Cross-stack review against [security-baseline.md](../_shared/security-baseline.md) (OWASP Top 10:2025, ASVS 5.0). Commands per ecosystem and the authz checklist: [security-checks.md](security-checks.md).

## 1. Audit scope (change nothing)

```bash
cat .claude/stack-profile.md 2>/dev/null
git rev-parse --show-toplevel && git status --porcelain | head
ls pnpm-lock.yaml package-lock.json bun.lock uv.lock go.mod Cargo.toml Dockerfile* docker-compose*.yml vercel.json supabase/config.toml *.tf .github/workflows 2>/dev/null
```

Take languages, framework, backend track, database, hosting, IaC and CI from the profile; detect the rest per [stack-profile.md](../_shared/stack-profile.md). Ask one question only when an ambiguity changes what to scan (for example "which of these two services is public-facing?"), and suggest `set-up-stack-profile`.

State the scope back in one line: what you will scan and what you skip.

## 2. Decide

Pick the checks that apply from [security-checks.md](security-checks.md) by profile: always secrets, dependencies, CI; headers if a web frontend or API exists; authz if there is any user data; IaC if `*.tf`; containers if a Dockerfile exists.

## 3. Check tool versions live

Scanners move. Verify the current version and flags per [version-protocol.md](../_shared/version-protocol.md) before running or recommending one (`gh api repos/gitleaks/gitleaks/releases/latest --jq .tag_name`). If a tool is not installed, say so and give the install line; run only read-only scanners. Do not install anything without approval.

## 4. Run the checks

For each applicable group in [security-checks.md](security-checks.md): run the command, then **read the code** the scanner cannot judge (authorization is almost never found by a scanner). Collect evidence as `path:line`. Never print secret values: show the file, line, rule id and the first 4 characters at most.

Groups: (A) secrets in tree and history, (B) dependencies, (C) authorization at the data boundary, (D) input validation and output encoding, (E) headers, cookies, CORS, (F) CI/CD supply chain, (G) config, IaC and containers, (H) logging and errors.

## 5. Report

Rank by severity: **Critical** (exploitable now, takeover or data exposure), **High** (exploitable with a precondition), **Medium** (weakens a layer), **Low** (hygiene). Each finding:

```
[Severity] <title>
Evidence: <path>:<line>  (<rule id or tool>)
Baseline: rule <n>; OWASP <A0x:2025>; ASVS v5.0.0-<chapter>
Impact: <one sentence: what an attacker gets>
Fix: <the exact change>
Effort: S/M/L
```

End with: counts per severity, what was **not** checked (and why), and any finding that needs a human decision (for example, "rotate this key": a secret in history is rotated, not removed).

Do not pad. No finding without evidence; no "might be vulnerable" without a concrete path. Mark uncertain items as "needs verification" with what to check.

## 6. Fix only what is approved

Ask the user which findings to fix (AskUserQuestion, up to 4 per round, Critical and High first). Then, per approved item: make the minimal change, one concern per commit or PR, add a regression test where the check is testable (for example user A cannot read user B's record). Never rewrite git history or rotate credentials without an explicit instruction. A leaked secret: tell the user to rotate it first, then remove it.

## 7. Verify

```bash
gitleaks dir . --no-banner --redact   # current subcommand per its release notes (v8: `dir`; older: `detect --no-git`); expected: no leaks found
```

Re-run each scanner you ran in step 4 and the tests you added. Expected: approved findings gone, the report's other findings unchanged, no new findings. State the commands and results. A second run of this skill on the same tree reports the same open items.

Files in this skill

  • SKILL.md4 KB
  • security-checks.md6.4 KB

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.