| name | semgrep-audit |
| description | Runs Semgrep static analysis security audits with scoped rulesets and structured findings. Use for security scans, vulnerability audits, or when touching auth, secrets, SQL, or user input boundaries. |
When to use
- security scans, vulnerability audits, or when touching auth, secrets, SQL, or user input boundaries
On-demand loading: Read this skill only when performing Semgrep security scans or validating security-sensitive changes. Do not load for unrelated work.
Related: Human-readable diff review → differential-review. Broader audit → security-review.
Semgrep Audit Skill
Use this skill to perform static analysis security auditing using Semgrep. Invoke when the user asks for a security scan, static analysis, vulnerability audit, or when touching security-sensitive code surfaces.
Trigger phrases
- "run semgrep"
- "static analysis"
- "security scan"
- "audit for vulnerabilities"
- "check for security issues"
Skill instructions
When this skill is invoked:
Step 1: Determine scope
Read the user's request to identify:
- Target paths (default: current workspace)
- Ruleset to use (default:
auto)
- Language/framework context
- Severity threshold (default: WARNING and above)
Step 2: Check Semgrep availability
Verify Semgrep is available via one of:
- The
Semgrep MCP server (Cursor plugin — preferred; use semgrep_scan tool)
- Local
semgrep CLI via Bash
- Docker:
docker run --rm -v $(pwd):/src semgrep/semgrep semgrep scan --config auto /src
Step 3: Select rulesets
Choose rulesets based on context:
| Context | Recommended rulesets |
|---|
| General security | p/owasp-top-ten, p/security-audit |
| Secrets detection | p/secrets |
| JavaScript/TypeScript | p/javascript, p/typescript, p/nodejs |
| Python | p/python, p/flask, p/django |
| Ruby/Rails | p/ruby, p/rails |
| Go | p/golang |
| Java | p/java, p/spring |
| PHP | p/php |
| Full audit | p/default |
Step 4: Execute scan
Using the Semgrep MCP tool (preferred):
Use Semgrep MCP server → semgrep_scan with appropriate config
Using CLI fallback:
semgrep --config p/owasp-top-ten --config p/secrets --json --output semgrep-results.json .
Step 5: Analyze results
Delegate finding analysis to the verification-specialist subagent, or process inline:
For each finding:
- Record: severity, rule ID, file path, line number, message
- Read surrounding code context (±10 lines)
- Assess: is this a true positive or false positive?
- Note: is the finding in test code?
- Identify: what is the remediation?
Step 6: Report findings
Structure the output as:
## Semgrep Audit Results
**Scan target:** <path>
**Rulesets:** <rulesets used>
**Total findings:** N (X critical, Y high, Z medium, W low)
---
### Critical / High Findings
#### [RULE-ID] Brief title
**File:** path/to/file.ts:LINE
**Severity:** HIGH
**Description:** What the vulnerability is and why it matters.
**Code:**
```<lang>
// relevant code snippet
Remediation: How to fix it.
Medium Findings
...
Low / Informational
...
False Positives Excluded
...
Summary
Key risks identified:
Recommended immediate actions:
- ...
### Step 7: Prioritize
Highlight findings that:
- Are reachable from user-controlled input
- Affect authentication, authorization, or secrets
- Are exploitable without authentication
- Affect data at rest or in transit
### Notes
- The Trail of Bits version of this skill references companion docs (`methodology.md`, `adversarial.md`) from their internal repository. Those are not included here but the core scanning workflow is fully functional.
- For supply chain security, add `p/supply-chain` to the ruleset.
- Suppress known false positives with `# nosemgrep: rule-id` in source code.
- For CI integration: `semgrep --config auto --error` (exit 1 on findings).