Audit
Skill 0x1337c0d3/claude-security/skills/sentinel/skills/audit
Intelligence-driven security analysis — the reasoning layer that complements Sentinel's tool-based scanning. Use this skill when the user says "analyze these findings", "explain this vulnerability", "is this exploitable", "false positive?", "fix this security issue", "threat model this", "audit my Dockerfile/Terraform/k8s/GitHub Actions", "harden this config", "review my auth code", "is this JWT safe", "check for secrets", or pastes Sentinel's consolidated.json for deeper analysis. Also trigger on any security question after `/sentinel:sentinel` has run. Works without any tools installed — pure Claude intelligence. Part of the Sentinel plugin (github.com/alissonlinneker/sentinel-claude-skill).From its SKILL.md
npx -y skills add 0x1337c0d3/claude-security --skill auditAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 3 stars3 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
7.2 KB, as published. Nobody here has run it
Security Auditor — Intelligence Layer for Sentinel
Sentinel runs the tools. This skill provides the brain.
When Sentinel output is available: enriches every SENTINEL-XXX finding with attack chains,
exploitability assessment, fix code, and false-positive analysis.
Without Sentinel output: performs full static security analysis on any code, IaC, or config using OWASP Top 10 reasoning, logic vulnerability detection, and the reference files below.
Reference files — load as needed
references/owasp-top10.md— load when analyzing application code (injection, auth, XSS, etc.)references/iac-checklist.md— load when reviewing Dockerfile, k8s YAML, Terraform, GitHub Actions, nginxreferences/crypto-guidance.md— load when crypto issues arise (passwords, JWT, TLS, random, AES)
Only load the reference file relevant to the current analysis. All three together = ~9KB context.
Input modes
| Mode | Trigger | What to do |
|---|---|---|
| Sentinel companion | User pastes consolidated.json or runs /sentinel:audit after a scan | Enrich each SENTINEL-XXX finding |
| Code audit | User pastes source code or uploads a file | Full OWASP analysis, 6 layers |
| IaC audit | Dockerfile, k8s, Terraform, CI YAML | Load iac-checklist.md, produce hardened version |
| Focused question | "Is this JWT safe?" / "Can this be injected?" | Direct answer, no full report |
| Threat model | Architecture description, API spec, data flow | Assets, trust boundaries, attack vectors |
Sentinel companion mode (primary use case)
When the user provides Sentinel's consolidated.json, process each finding:
## Enhanced Analysis: SENTINEL-001
Tool: semgrep | Severity: CRITICAL | CWE: CWE-89
Confirmed? YES / LIKELY / FALSE POSITIVE
[Reasoning from code context]
Exploitability: Trivial / Easy / Moderate / Hard / Theoretical
[Why: "Endpoint is public, no auth required, input reaches sink in 2 hops"]
Attack chain:
1. Attacker sends: GET /users?id=1 OR 1=1--
2. Input reaches db.query() at user.ts:45 without sanitization
3. Result: full users table returned — credentials, emails, PII
Fix (complete, runnable):
[corrected code with inline comments explaining each security change]
OWASP: A03:2021 Injection | Compliance: PCI-DSS 6.5.1, SOC 2 CC6.1
After all findings, add:
## Findings Sentinel missed (logic/architecture)
[Vulnerabilities tools cannot detect: business logic flaws, IDOR, race conditions]
## False positive analysis
[Sentinel findings that appear to be false positives, with reasoning]
## Combined risk score
Sentinel score: XX/100
Manual analysis delta: [+/-] because [reason]
Adjusted score: YY/100
Full audit — 6 layers
When given code to audit without Sentinel output:
Layer 1 — Attack surface mapping
Entry points, trust boundaries, sensitive assets, external dependencies, auth perimeter.
Layer 2 — OWASP Top 10 analysis
Load references/owasp-top10.md. For each finding:
[SEVERITY] [CWE-XXX] Title
Location: file:line | Confidence: HIGH/MEDIUM/LOW
Attack chain:
1. [specific input] → [specific function] → [missing control] → [impact]
Evidence:
[exact vulnerable code]
Fix:
[corrected code + one-line explanation]
Severity: CRITICAL (RCE, auth bypass) | HIGH (SQLi, XSS, SSRF) | MEDIUM (CSRF, weak crypto) | LOW (headers, info disclosure) | INFO (best practice)
Layer 3 — Logic vulnerabilities (tools miss these)
- Broken business logic: rate limit bypass, negative prices, TOCTOU, state machine skips
- Auth/authz: JWT alg:none/kid injection/weak secret, IDOR, OAuth state missing, session fixation
- Crypto misuse: ECB mode, reused IVs, timing attacks (
==vshmac.compare_digest),Math.random()for tokens - Race conditions: check-then-act, double-spend, insufficient locking
Layer 4 — IaC & infrastructure
Load references/iac-checklist.md when Dockerfile, k8s, Terraform, or CI/CD files are present.
Layer 5 — Secrets & credentials
API keys, private keys, DB connection strings, base64-encoded secrets, credentials in comments or URLs. For each: identify service, assess if real vs placeholder, recommend rotation + secrets manager migration.
Layer 6 — Dependencies (pattern-based, no live CVE lookup)
Known vulnerable package patterns, typosquatting risk, unpinned versions.
Note: for live CVE data → run /sentinel:sentinel quick (SCA scanner).
Output format
# Security Audit Report
Component: [name] | Date: [today] | Scope: [what was reviewed]
Summary: X critical, Y high, Z medium, W low
Risk Score: XX/100
## Attack Surface
[Layer 1 output]
## Findings
[One block per finding, format above]
## What's secure ✓
[2–4 specific things done well — always include]
## Priority fix order
1. [Fix today — why]
2. [Next sprint — why]
3. [Nice to have — why]
## Sentinel integration note
[If Sentinel ran: "N findings confirmed, M appear to be false positives"]
[If Sentinel not installed: "Run /sentinel:sentinel for dependency CVEs and git history secrets scan"]
Fix code standards
Every fix must be: runnable (not pseudocode), idiomatic (language best practices), explained (one comment per change), non-breaking (preserves functionality).
# BEFORE (vulnerable):
query = f"SELECT * FROM users WHERE email = '{email}'"
# AFTER — parameterized query separates code from data.
# DB driver handles escaping; user input never reaches the SQL parser.
query = "SELECT * FROM users WHERE email = %s"
cursor.execute(query, (email,))
Scope honesty — always be explicit
- "This covers the auth module only. Payment processing was not reviewed."
- "Cannot confirm SSRF without seeing
validateUrl()— not provided." - "SENTINEL-042 appears to be a false positive:
escape()at line 18 sanitizes before the sink at line 34." - "For live CVE data, this analysis cannot substitute for Sentinel's SCA scanner."
Never fabricate CVE IDs. Describe the vulnerability pattern without asserting a specific CVE number if uncertain.
Report Format
Format your final output following the standard Sentinel report structure defined in
${CLAUDE_SKILL_DIR}/../../templates/report.md. Use your skill's domain-specific
finding IDs (e.g. STRIDE-SPOOF-001, RT-SK-001, API-001) in the Finding ID column.
Include the Security Scorecard and Findings sections as a minimum. Omit the
Cross-Validation Summary section if you ran only AI analysis (no tool comparison).