agentleFS
XavierErXavierEr/appsec-agent-skills/skills/security-audit/SKILL.md

security-audit

Skill4 starsChanged 7 months agoMITView on GitHub

Master orchestrator skill for comprehensive security auditing. Auto-detects the project's technology stack and selectively invokes applicable security scanning skills. Produces a unified report with context-aware remediation. Trigger when the user asks for: "security audit", "full security scan", "comprehensive vulnerability assessment", "scan this project for security issues", "run all security checks", "full pentest", or any request for a broad, multi-dimensional security review.

  • Reads credentials

192 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use create-stories, story-done and 10 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • lilangMaxSkill

    create-stories

    Break a single epic into implementable story files. Reads the epic, its GDD, governing ADRs, and control manifest. Each story embeds its GDD requirement TR-ID, ADR guidance, acceptance criteria, story type, and test evidence path. Run after /create-epics for each epic.

    Also in 11 projects that use this

  • lilangMaxSkill

    story-done

    End-of-story completion review. Reads the story file, verifies each acceptance criterion against the implementation, checks for GDD/ADR deviations, prompts code review, updates story status to Complete, and surfaces the next ready story from the sprint.

    Also in 11 projects that use this

  • nicepkgSkill

    community-led-growth

    Expert in community-led growth (CLG) - leveraging user communities to drive acquisition, retention, and expansion. Covers building developer communities, user groups, ambassador programs, and turning customers into advocates. Knows the difference between community as a feature vs community as a growth engine, and how to measure community ROI. Use when "community-led, CLG, ambassador program, champion program, user community, developer community, word of mouth, user group, " mentioned.

    Also in 5 projects that use this

  • nicepkgSkill

    ph-community-outreach

    Engage Reddit, Indie Hackers, Hacker News and other communities for Product Hunt launches. Use this skill to identify relevant communities, craft appropriate posts, and drive cross-platform engagement without appearing spammy.

    Also in 5 projects that use this

  • +7 more from lilangMax
  • +1 more from nicepkg

The file

Show its rules and text

We split this skill into the rules it gives an agent

20 rules. 0 are common, 16 are distinctive, and 4 are very specific to this project.

  • 0

    Common

    Most of the 174 edited versions we read keep these.

  • 16

    Distinctive

    This author's own choices. Worth a look.

  • 4

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Check for manifest files to identify the primary language(s):

    line 55
  2. Distinctive:

    If multiple manifest files exist, the project is polyglot — note all detected languages.

    line 68
  3. Distinctive:

    Read the manifest files and entry points to identify the framework(s) in use:

    line 72
  4. Distinctive:

    Use the Bash tool to probe common development ports for live HTTP services:

    line 85
  5. Distinctive:

    Search the project for API specification files:

    line 98
  6. Distinctive:

    Test files (existing security tests)

    line 121
  7. Distinctive:

    Use the AskUserQuestion tool to confirm the detection results and skill selection with the user before proceeding to Step 3.

    line 162
  8. Distinctive:

    Run selected skills in this optimal order (fastest and most critical first):

    line 166
  9. Very specific:

    Use the Read tool to load the skill's SKILL.md file from .claude/skills/{skill-name}/SKILL.md

    line 178
  10. Very specific:

    Follow the workflow defined in that skill's SKILL.md

    line 179
  11. Distinctive:

    After all skills have executed, aggregate and normalize the findings.

    line 193
  12. Distinctive:

    Ensure consistent severity across all skills:

    line 212
  13. Distinctive:

    Use a unified Critical / High / Medium / Low / Info scale

    line 213
  14. Distinctive:

    Use the project's detected language, framework, and library versions

    line 278
  15. Very specific:

    If the project contains secure counterparts (e.g., // SECURE VERSION:), reference them

    line 280
  16. Distinctive:

    Start with the simplest fix, then mention more comprehensive alternatives

    line 282
  17. Distinctive:

    Document what was NOT tested and why:

    line 330
  18. Distinctive:

    Start the application server and re-run with DAST enabled

    line 335
  19. Distinctive:

    Add API specification files for contract testing

    line 336
  20. Very specific:

    After applying fixes, run /remediation-validator to confirm vulnerabilities are resolved and detect regressions

    line 339

“Common” is measured: kept by at least 6 in 10 of the 174 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Security Audit — Smart Orchestrator

Overview

This is the master orchestrator skill. It auto-detects the project's technology stack and selectively invokes the appropriate security scanning skills. It produces a unified report with context-aware remediation tailored to the project's language, framework, and existing code patterns.

The orchestrator is language-agnostic — it dynamically determines what to scan and how based on what it finds in the project directory.

Available Sub-Skills

#SkillDescription
1llm-sast-scannerStatic Application Security Testing — source code analysis for 34+ vulnerability classes using taint tracking and pattern matching
2dast-scannerDynamic Application Security Testing — running endpoint probing, fuzzing, and runtime vulnerability detection against live services
3dependency-auditDependency vulnerability scanning — identifies known CVEs in third-party packages and transitive dependencies
4security-config-reviewInfrastructure and configuration hardening review — Docker, CI/CD, cloud IaC, framework settings
5api-contract-testingAPI specification vs behavior validation — detects undocumented endpoints, schema mismatches, auth bypass
6secrets-scannerHardcoded secrets detection — scans source code, config files, and git history for leaked credentials
7compliance-mapperFramework mapping — maps findings to OWASP Top 10, CWE Top 25, NIST 800-53, and PCI DSS requirements

Workflow

Step 1: Project Context Detection

Scan the project directory to build a complete picture of the technology stack. Use the Read tool to load references/project_detection.md for comprehensive detection patterns. Use the Glob tool to find manifest and config files.

1a. Language and Runtime Detection

Check for manifest files to identify the primary language(s):

Manifest FileLanguage/Runtime
package.jsonNode.js / TypeScript
requirements.txt / pyproject.toml / Pipfile / setup.pyPython
pom.xml / build.gradle / build.gradle.ktsJava / Kotlin
GemfileRuby
go.modGo
composer.jsonPHP
Cargo.tomlRust
*.csproj / *.fsproj.NET (C# / F#)

If multiple manifest files exist, the project is polyglot — note all detected languages.

1b. Framework Detection

Read the manifest files and entry points to identify the framework(s) in use:

  • Node.js: Express, Koa, Fastify, NestJS, Hapi, Restify
  • Python: Flask, Django, FastAPI, Tornado, Sanic, Starlette
  • Java: Spring Boot, Micronaut, Quarkus, Jakarta EE, Dropwizard
  • Ruby: Rails, Sinatra, Hanami, Grape
  • Go: Gin, Echo, Fiber, Chi, net/http (stdlib)
  • PHP: Laravel, Symfony, Slim, Lumen, CodeIgniter
  • Rust: Actix-web, Axum, Rocket, Warp, Tide
  • .NET: ASP.NET Core, Blazor, Minimal APIs

1c. Running Services Detection

Use the Bash tool to probe common development ports for live HTTP services:

Ports to probe: 3000, 3001, 4000, 5000, 5173, 8000, 8080, 8443, 9000
Command: curl -s -o /dev/null -w "%{http_code}" --max-time 2 http://localhost:PORT/
Running if: HTTP status is 200, 301, 302, 403, or 404
Not running if: connection refused or timeout

Also check for HTTPS on ports 443, 8443.

1d. API Specification Detection

Search the project for API specification files:

  • OpenAPI: openapi.yaml, openapi.json, openapi.yml
  • Swagger: swagger.yaml, swagger.json, swagger.yml
  • GraphQL: schema.graphql, *.graphql, *.gql
  • RAML: *.raml
  • Postman: *.postman_collection.json

1e. Configuration File Detection

Scan for infrastructure and configuration files:

  • Containers: Dockerfile, docker-compose.yml, docker-compose.yaml, .dockerignore
  • CI/CD: .github/workflows/*.yml, .gitlab-ci.yml, Jenkinsfile, .circleci/config.yml, .travis.yml, bitbucket-pipelines.yml
  • Environment: .env, .env.*, .env.local, .env.production
  • Cloud IaC: terraform/, *.tf, cloudformation/, pulumi/, cdk.json, serverless.yml
  • Security: .helmet, cors.json, csp.json, security middleware configs

1f. Source Structure Analysis

Identify the project's code organization:

  • Route/controller files (where HTTP handlers are defined)
  • Middleware files (authentication, authorization, validation)
  • Model/schema files (data structures, database schemas)
  • Configuration files (app settings, database connections)
  • Test files (existing security tests)

Step 2: Skill Selection

Based on the detection results from Step 1, determine which sub-skills are applicable:

SkillConditionCategory
secrets-scannerAny text files exist in the projectAlways
llm-sast-scannerSource code files exist in a supported languageAlways
dependency-auditAt least one manifest or lock file foundConditional
security-config-reviewDocker, CI/CD, cloud, or framework configuration files foundConditional
api-contract-testingAPI specification file found OR a live server detectedConditional
dast-scannerA live HTTP server detected on a probed portConditional
compliance-mapperAny findings produced by the above skillsAlways (runs last)

Before proceeding, display the detection results and selected skills to the user:

## Project Detection Results

| Attribute | Detected |
|-----------|----------|
| Language(s) | {languages} |
| Framework(s) | {frameworks} |
| Package Manager | {package_manager} |
| Running Services | {ports or "None detected"} |
| API Specifications | {specs or "None found"} |
| Config Files | {list of config files found} |
| Source Structure | {summary of code organization} |

## Skills Selected for Execution

| # | Skill | Reason |
|---|-------|--------|
| 1 | secrets-scanner | Always runs |
| 2 | llm-sast-scanner | {language} source code detected |
| ... | ... | ... |

Use the AskUserQuestion tool to confirm the detection results and skill selection with the user before proceeding to Step 3.

Step 3: Sequential Skill Execution

Run selected skills in this optimal order (fastest and most critical first):

  1. secrets-scanner — Fast scan, catches critical credential leaks immediately
  2. llm-sast-scanner — Comprehensive source code analysis across all vulnerability classes
  3. dependency-audit — Check packages against CVE databases
  4. security-config-review — Review infrastructure and framework configurations
  5. api-contract-testing — Validate API behavior against specifications (if spec found or server running)
  6. dast-scanner — Active probing against running endpoints (most time-intensive, requires live server)
  7. compliance-mapper — Aggregate all findings and map to compliance frameworks (always runs last)

Execution process for each skill:

  1. Use the Read tool to load the skill's SKILL.md file from .claude/skills/{skill-name}/SKILL.md
  2. Follow the workflow defined in that skill's SKILL.md
  3. Collect all findings in a structured format (ID, title, severity, location, evidence, remediation)
  4. Track execution status: completed, skipped (condition not met), or failed (error during execution)
  5. Note the finding count per severity level

Between skills, provide a brief progress update:

[2/7] SAST Scanner complete — found X findings (C critical, H high, M medium, L low)
[3/7] Starting Dependency Audit...

Step 4: Findings Aggregation

After all skills have executed, aggregate and normalize the findings.

4a. Deduplication

Apply deduplication rules (see references/report_format.md for full logic):

  • Same CWE + same file:line from different skills → merge into single finding, note all source skills
  • Same vulnerability type at different locations → keep separate (each is independently exploitable)
  • SAST finding + DAST confirmation of same issue → merge, mark confidence as "Confirmed"
  • Dependency CVE + SAST confirming vulnerable function usage → merge, note "Vulnerable function confirmed in use"

4b. Correlation and Confidence

Boost confidence when multiple skills corroborate:

  • Single skill finding → confidence: "Likely"
  • Two skills confirming → confidence: "Confirmed"
  • SAST + DAST confirming → confidence: "Confirmed (static + dynamic)"

4c. Severity Normalization

Ensure consistent severity across all skills:

  • Use a unified Critical / High / Medium / Low / Info scale
  • Apply severity escalation: if 3+ High findings exist, escalate overall risk to Critical
  • Corroborated findings (multi-skill confirmation) → increase severity by one level (up to Critical)

4d. Counting

Tally final deduplicated findings by severity:

  • Total Critical, High, Medium, Low, Informational
  • Determine overall risk rating based on the highest individual finding severity (with escalation rules)

Step 5: Unified Report Generation

Produce a single comprehensive report following the structure in references/report_format.md.

Section 1: Executive Summary

# Security Audit Report

## Executive Summary

| Attribute | Value |
|-----------|-------|
| **Project** | {name} |
| **Stack** | {language} / {framework} |
| **Scan Date** | {date} |
| **Skills Executed** | {count} of {total available} |
| **Overall Risk** | {Critical/High/Medium/Low} |

### Finding Totals

| Critical | High | Medium | Low | Info |
|----------|------|--------|-----|------|
| X | Y | Z | W | V |

### Top 3 Critical Issues

1. **SEQ-001**: {one-line description} — {location}
2. **SEQ-002**: {one-line description} — {location}
3. **SEQ-003**: {one-line description} — {location}

Section 2: Detection Summary

Table showing what was detected and which skills were run, including any skills that were skipped and why.

Section 3: Findings (grouped by severity)

For each finding, present:

  • ID: SEQ-001, SEQ-002, etc. (sequential across all skills)
  • Title: One-line vulnerability description
  • Severity: Critical / High / Medium / Low / Info
  • Confidence: Confirmed / Likely / Possible
  • Source: Which skill(s) identified this finding
  • Location: file:line for code issues, endpoint URL for runtime issues
  • Evidence: Code snippet, request/response pair, or configuration excerpt
  • Impact: What an attacker can achieve by exploiting this vulnerability
  • Framework References:
    • OWASP Top 10 category (e.g., A03:2021 Injection)
    • CWE ID (e.g., CWE-89: SQL Injection)
    • NIST 800-53 control (e.g., SI-10: Information Input Validation)
    • PCI DSS requirement (e.g., 6.5.1: Injection Flaws)
  • Context-Aware Remediation:
    • Reference the exact file and line where the fix should be applied
    • Use the project's detected language, framework, and library versions
    • Show before/after code using the project's actual patterns and imports
    • If the project contains secure counterparts (e.g., // SECURE VERSION:), reference them
    • Suggest framework-native solutions (e.g., helmet() for Express, csrf_protect for Django)
    • Start with the simplest fix, then mention more comprehensive alternatives
  • Effort Estimate: Low / Medium / High

Section 4: Compliance Scorecard

### OWASP Top 10 (2021)

| Category | Status | Finding Count |
|----------|--------|---------------|
| A01: Broken Access Control | {PASS/FAIL/N/A} | X |
| A02: Cryptographic Failures | {PASS/FAIL/N/A} | X |
| ... | ... | ... |

### CWE Top 25

Matched: X of 25 most dangerous software weaknesses

### NIST 800-53

| Control Family | Findings |
|----------------|----------|
| AC (Access Control) | X |
| ... | ... |

### PCI DSS v4.0

| Requirement | Status |
|-------------|--------|
| 6.2.4: Software engineering techniques | {PASS/FAIL/N/A} |
| ... | ... |

Section 5: Remediation Roadmap

Prioritize fixes by impact and effort:

PriorityCriteriaAction
P1 — ImmediateCritical severity + Low effortFix now, these are quick wins with maximum impact
P2 — Short-termHigh severity, or Critical + High effortSchedule for current sprint
P3 — Medium-termMedium severityPlan for next sprint or release cycle
P4 — Long-termLow severity, architectural changesAdd to backlog, address during refactoring

List each finding under its priority tier with the specific remediation action.

Section 6: Gap Analysis

Document what was NOT tested and why:

  • Skills that were skipped (e.g., "DAST scanner skipped — no running server detected on probed ports")
  • Vulnerability classes not fully covered (e.g., "Business logic flaws require manual review")
  • Recommended follow-up actions:
    • Start the application server and re-run with DAST enabled
    • Add API specification files for contract testing
    • Perform manual penetration testing for logic flaws
    • Review third-party integrations not covered by automated scanning
    • After applying fixes, run /remediation-validator to confirm vulnerabilities are resolved and detect regressions

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.