agentsclimarketplace

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

Install
npx -y skills add 0x1337c0d3/claude-security --skill audit

Assembled 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, nginx
  • references/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

ModeTriggerWhat to do
Sentinel companionUser pastes consolidated.json or runs /sentinel:audit after a scanEnrich each SENTINEL-XXX finding
Code auditUser pastes source code or uploads a fileFull OWASP analysis, 6 layers
IaC auditDockerfile, k8s, Terraform, CI YAMLLoad iac-checklist.md, produce hardened version
Focused question"Is this JWT safe?" / "Can this be injected?"Direct answer, no full report
Threat modelArchitecture description, API spec, data flowAssets, 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 (== vs hmac.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).

Keep looking

Skills are one crate of 627,801. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.