Skip to content
Security
Skill

/scanner-pipeline

Set up and run deterministic security scanners across a repo or a whole fleet of repos — gitleaks, trufflehog, semgrep, osv-scanner, trivy, checkov, Brakeman, govulncheck, Supabase advisors, and (guarded) nuclei/ZAP — then normalize their output to findings.json or SARIF,

BOOST
From plugin
briiirussell-cybersecurity-skills
47942 skills1 agent
Install
$ npx -y skills add briiirussell/cybersecurity-skills --skill scanner-pipeline --agent claude-code

How it fires

How this skill gets triggered: by you, by Claude, or both.

  • Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
  • You can call itInvoke it directly when you want it.
  • Slash command/scanner-pipeline

Context preview

The summary Claude sees to decide when to auto-load this skill.

Set up and run deterministic security scanners across a repo or a whole fleet of repos — gitleaks, trufflehog, semgrep, osv-scanner, trivy, checkov, Brakeman, govulncheck, Supabase advisors, and (guarded) nuclei/ZAP — then normalize their output to findings.json or SARIF,

SKILL.md

scanner-pipeline.SKILL.md
name: scanner-pipeline
description: "Set up and run deterministic security scanners across a repo or a whole fleet of repos — gitleaks, trufflehog, semgrep, osv-scanner, trivy, checkov, Brakeman, govulncheck, Supabase advisors, and (guarded) nuclei/ZAP — then normalize their output to findings.json or SARIF, dedupe, suppress with expiry, schedule in CI, and hand findings to fix agents. Use when the user mentions 'run scanners,' 'security scanning pipeline,' 'set up gitleaks,' 'semgrep in CI,' 'osv-scanner,' 'trivy fs,' 'SARIF,' 'code scanning,' 'scan all my repos,' 'security-scan workflow,' 'weekly security scan,' 'Supabase RLS advisor,' 'dedupe scanner findings,' 'suppression file,' 'stop asking Claude to hack my app,' or wants tools, not an agent, to find the bugs."
allowed-tools: Read, Grep, Glob, Write, Bash(gitleaks:*), Bash(trufflehog:*), Bash(osv-scanner scan:*), Bash(trivy fs:*), Bash(trivy image:*), Bash(trivy config:*), Bash(checkov:*), Bash(bundle-audit:*), Bash(brakeman:*), Bash(gosec:*), Bash(govulncheck:*), Bash(gh repo list:*)

Scanner Pipeline — Run the Real Tools, Normalize, Hand Off

Stop asking the agent to hack your app. Have it pick the right deterministic scanner for each layer, run it non-interactively, merge the output into one format, and route each finding to a fix agent. Scanners find the same thing every time; an agent review finds it when it happens to look.

Field evidence from a 45-app sweep in October 2026 (`patch-sweep`). An agent-led review eventually found all of these; a scanner would have flagged each one on the first run:

  • **10 Supabase tables with RLS disabled**, readable and writable with the public anon key — including 472k inbound email bodies. Supabase's own security advisor reports this as `rls_disabled_in_public`.
  • **An always-true RLS policy**: `csr.collection_id = csr.collection_id`. A custom semgrep rule over migrations catches it (below).
  • **Separate `npm audit`, `pnpm audit`, and `bundle-audit` runs per repo**, where one `osv-scanner` pass covers every lockfile.

**This skill orchestrates.** Interpreting a tool's findings in depth stays with the layer skill: `secrets-audit`, `dependency-audit`, `container-audit`, `cloud-audit`, `owasp-audit`. Active exploitation is `web-pentest` / `red-team-engagement`.

**Why `Write` is pre-approved:** this skill's main output is files — the `scanner-pipeline.md` plan, a `.github/workflows/security-scan.yml`, and scanner configs. It writes only those, and only inside the target repo. Live-app scanners (`nuclei`, `zap`) are deliberately not pre-approved; they always prompt.

Cross-references: `finding-triage` (ranking and disposition), `secrets-audit`, `dependency-audit`, `container-audit`, `cloud-audit` (Supabase advisors, PaaS), `web-pentest` (authorization for live scans), `cicd-security` (SHA-pinned Actions, workflow hardening; zizmor / actionlint results), `patch-sweep` (fleet CVE response), `log-watch`.

Authorization

Before running anything, confirm: 1. **Repos:** the user owns or is authorized to scan each one. For fleet mode, the owners/orgs to enumerate. 2. **Live targets:** only domains the user owns **and names explicitly** in this conversation. Not "whatever the repo deploys to" — the user says the hostnames. 3. **Where results go:** local files only, GitHub code scanning, or issues. Secret findings never go into a public issue.

Refuse to: run live scanners (nuclei, ZAP, Burp) against hosts the user doesn't own or didn't name; scan third-party or shared hosts (a shared Supabase/Vercel/Heroku hostname, a CDN, an API you call); run ZAP active scan or nuclei intrusive templates without the `web-pentest` authorization step; print secret values anywhere.

1. Detect the stack and pick tools per layer

Read the repo first: lockfiles, `Dockerfile`, `*.tf`, `supabase/`, `Gemfile`, `go.mod`, `.github/workflows/`. Then pick one tool per layer, preferring multi-ecosystem tools over per-package-manager ones.

| Layer | Primary | Stack-specific add-ons | Fallback | |---|---|---|---| | Secrets | `gitleaks git` (full history) | `trufflehog git --only-verified` for live verification | — | | Code (SAST) | `semgrep scan` | Brakeman (Rails), gosec (Go), CodeQL (if GHAS), custom semgrep rules (below) | — | | Dependencies | `osv-scanner scan source -r .` (npm, pnpm, yarn, Bundler, pip, Go, Cargo, Composer, Maven in one pass) | `bundle-audit` (Rails), `govulncheck` (Go, call-graph reachability), `pip-audit` | `npm audit` / `pnpm audit --prod` / `yarn audit` | | Infra / IaC / containers | `trivy fs --scanners vuln,misconfig,secret .` | `checkov -d .` (Terraform, CloudFormation, k8s, Actions), `trivy image <img>` | — | | Database (Supabase) | Supabase security advisor (`supabase db advisors`, or Management API `GET /v1/projects/{ref}/advisors/security`) | `supabase db lint` (plpgsql_check: function errors, not RLS), semgrep rule over `supabase/migrations/` | `pg_policies` / `pg_tables.rowsecurity` query | | Live app (guarded) | ZAP baseline (passive) | nuclei with `-rl` | — |

Commands, non-interactive, one output file per tool under `.security/out/`:

mkdir -p .security/out
# Secrets — full history, values redacted
gitleaks git . --redact --report-format sarif --report-path .security/out/gitleaks.sarif
trufflehog git file://. --only-verified --json --no-update | jq -c 'del(.Raw, .RawV2)' > .security/out/trufflehog.jsonl
# Code
semgrep scan --config p/default --config .semgrep/ --metrics=off --sarif --output .security/out/semgrep.sarif
# Dependencies (all lockfiles at once)
osv-scanner scan source -r . --format sarif --output .security/out/osv.sarif
# Infra / IaC / container files
trivy fs --scanners vuln,misconfig,secret --format sarif --output .security/out/trivy.sarif .
checkov -d . -o sarif --output-file-path .security/out/
# Rails
bundle-audit check --update
brakeman --no-pager -f sarif -o .security/out/brakeman.sarif
# Go
govulncheck -format sarif ./... > .security/out/govulncheck.s
Read more
Ships withbriiirussell-cybersecurity-skills

A collection of cybersecurity skills for AI coding agents. The AI does the heavy lifting; you bring the context about your stack and your priorities.

Get the whole plugin