swe:security-audit git:20260404.c9ad52fA

Immutable. This exact content never changes and is served at /api/v1/blob/6292b5e60db43db6.

---
name: "swe:security-audit"
description: >-
  Audits a repository, workspace, or monorepo for dependency vulnerabilities,
  outdated security-sensitive packages, license issues, and dependency hygiene
  gaps, then compiles one evidence-backed report. Use when a user says `run a
  security audit`, `check dependencies and licenses`, `audit this monorepo for
  vulnerable packages`, or asks for a package-level security review. Do NOT use
  for a general secure-code review, threat model, or speculative vulnerability
  hunt without manifests, lockfiles, or package surfaces to inspect.
compatibility: >-
  Requires manifests or lockfiles for the target repo and works best with
  ecosystem audit tools such as package-manager audit commands, `osv-scanner`,
  `trivy`, or license scanners.
metadata:
  short-description: Audit services and packages for security risk
---

# SWE Security Audit

## What This Skill Does

Use this skill to run a dependency- and package-surface-focused security audit
across a repository, workspace, or monorepo.

The primary job is to find evidence-backed issues in:

- Vulnerabilities
- Outdated dependencies with real security relevance
- License issues
- Dependency hygiene gaps that materially weaken auditability

## When To Use

Use this skill when the user wants to:

- Audit a repo or monorepo for vulnerable packages
- Check dependency freshness and license risk
- Review package surfaces service by service
- Produce one consolidated dependency-security report

## Do Not Use

Do not use this skill for:

- A broad application code review
- Threat modeling
- Hand-auditing runtime bugs unrelated to dependencies or manifests
- Guessing about security posture without manifests, lockfiles, or scanners

## Inputs To Confirm

Confirm or infer:

- Repo or package scope
- Whether the audit should include all services or only selected units
- Which package managers and ecosystems are present
- What scanners or audit tools are available locally

## Parallelization Rule

Create one session per service or package when the environment supports parallel
agent work.

- Run up to 10 sessions at a time
- Give each session a disjoint surface area
- Have each session return raw evidence, not just conclusions
- Compile the final report centrally after the sessions finish

If parallel sessions are unavailable, process the units in local batches and
keep the same report shape.

## Instructions

### Step 1: Identify Audit Units

Inspect the repository and group the codebase into the smallest practical
independent audit surfaces, such as:

- Services
- Apps
- Packages
- Libraries
- Deployable components

### Step 2: Detect Each Unit's Ecosystem

For every unit, determine the ecosystem and package manager in use so the
correct scanner or audit command can be chosen.

### Step 3: Run The Strongest Available Checks

Run the most appropriate security, dependency, and license checks for each
surface. Prefer the package manager and scanners already used by the repo.

## Tooling Stance

This skill is tool agnostic.

Use the strongest available tools for the detected ecosystem, such as:

- `npm audit`, `pnpm audit`, or `yarn audit`
- `cargo audit`
- `pip-audit`, `safety`, or `poetry show --outdated`
- `bundle audit` or `bundler outdated`
- `go list -m -u all` or `govulncheck`
- `osv-scanner`
- `trivy`
- `license_finder`
- Ecosystem-native outdated or advisory commands

Prefer the package manager and scanner already used by the repository. Do not
invent tooling if the environment already has a clear local pattern.

### Step 4: Capture Raw Evidence

Capture concrete evidence from:

- Tool output
- Lockfiles
- Manifests
- Advisory IDs
- CI signals

If a check cannot be run, say why and do not guess the result.

## Evidence Rules

- Use concrete evidence only
- Cite the service or package audited
- Name the manifest or lockfile involved
- Include vulnerable or outdated package names and versions
- Include the source of the advisory or scanner output when available
- Distinguish observed findings from inferred risk

If a check cannot be run:

- Say why
- Note the missing tool, lockfile, or environment limitation
- Do not guess the result

## What To Check

For each audit unit, check:

- Known vulnerabilities in direct and transitive dependencies
- Outdated dependencies that are materially behind and plausibly risky
- License issues or policy mismatches
- Missing lockfiles or suspicious dependency hygiene gaps
- Existing CI or audit failures tied to dependency health

Do not turn the task into a broad code review unless the dependency issue
directly exposes a security concern.

## Findings Threshold

Report only findings that are grounded in evidence.

For outdated dependencies:

- Prioritize meaningful lag, not trivial patch drift
- Focus on packages with security relevance, high exposure, or obvious staleness

For license issues:

- Report concrete incompatible, unknown, or restricted licenses
- Note when license data is incomplete or unavailable

### Step 5: Aggregate And Rank Findings

Aggregate all findings into one report ranked by severity and confidence.

Call out units with no findings explicitly.

## Output Requirements

Produce one consolidated report with these sections:

1. Scope audited
2. Audit coverage
3. Findings by severity
4. Package or service summaries
5. Recommended next actions

For each finding, include:

- Severity
- Service or package
- Relevant manifest or lockfile
- Dependency or license item
- Current version or status
- Recommended upgrade, remediation, or policy action
- Evidence

For each audited unit, include:

- Unit name
- Ecosystem or package manager
- Checks run
- Result summary

## Output Style

Keep the final report concise and operational.

Prefer short bullets grouped by severity:

- Critical
- High
- Medium
- Low
- No findings

Call out the highest-priority remediation items first.

## Examples

### Example 1

User says: `Run a security audit across this monorepo and tell me which package
dependencies need urgent attention.`

Actions:

1. Split the monorepo into package-sized audit units
2. Detect each unit's ecosystem and package manager
3. Run the strongest available audit and license checks
4. Aggregate the evidence into one severity-ranked report

Result: The user gets a consolidated dependency-security report with clear next
actions.

### Example 2

User says: `Check this service for vulnerable or badly outdated dependencies and
flag any license problems.`

Actions:

1. Inspect the target service's manifests and lockfiles
2. Run the relevant ecosystem-native scanners
3. Report only evidence-backed findings
4. Note explicitly if some checks could not run

Result: The audit stays scoped to one service and avoids unsupported claims.

## Troubleshooting

### Problem: Lockfiles Or Manifests Are Missing

Call that out as a dependency-hygiene finding when appropriate and explain which
checks were blocked as a result.

### Problem: The Best Scanner Is Not Installed

Use the strongest available alternative, but say exactly which preferred check
could not run and how that limits confidence.

### Problem: Mixed Ecosystems Make Coverage Uneven

Report coverage per audit unit so the user can see which surfaces were fully
audited and which ones had partial visibility.

## Quality Bar

- Be evidence-led
- Prefer exact package names, versions, manifests, and advisories
- Use parallel sessions only where write and read scope are cleanly separated
- Keep the aggregation tight and non-redundant
- If the audit surface is too large or partially inaccessible, say so clearly