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
- karlo-ks/Infradecktheir own version, first seen Nov 15, 2026
- argos-ci/argostheir own version, first seen Nov 9, 2026
- classroomio/classroomiotheir own version, first seen Nov 9, 2026
- dio-az/dotfilestheir own version, first seen Nov 8, 2026
- roke22/Squadratheir own version, first seen Nov 8, 2026
- qwwiwi/agentos-skills-publictheir own version, first seen Nov 8, 2026
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.
lilangMaxSkillcreate-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
lilangMaxSkillstory-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
nicepkgSkillcommunity-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
nicepkgSkillph-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
Other versions192 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 192
- ruvnet/claude-flow★ 80ksame name
- ruvnet/ruflo★ 79ksame name
- PostHog/posthog★ 40ksame name
- Donchitos/Claude-Code-Game-Studios★ 27ksame name
- cloudflare/security-audit-skill★ 18ksame name
- rommapp/romm★ 14ksame name
- kubeshark/kubeshark★ 12ksame name
- maximhq/bifrost★ 9.4ksame name
- mono/SkiaSharp★ 5.6ksame name
- MaxMiksa/Auto-Company★ 3.2ksame name
182 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository8 other files it gives its agents.
- API Contract TestingSkill
- compliance-mapperSkill
- DAST ScannerSkill
- dependency-auditSkill
- llm-sast-scannerSkill
- remediation-validatorSkill
- secrets-scannerSkill
- security-config-reviewSkill
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
- Distinctive: line 55
Check for manifest files to identify the primary language(s):
- Distinctive: line 68
If multiple manifest files exist, the project is polyglot — note all detected languages.
- Distinctive: line 72
Read the manifest files and entry points to identify the framework(s) in use:
- Distinctive: line 85
Use the Bash tool to probe common development ports for live HTTP services:
- Distinctive: line 98
Search the project for API specification files:
- Distinctive: line 121
Test files (existing security tests)
- Distinctive: line 162
Use the AskUserQuestion tool to confirm the detection results and skill selection with the user before proceeding to Step 3.
- Distinctive: line 166
Run selected skills in this optimal order (fastest and most critical first):
- Very specific: line 178
Use the Read tool to load the skill's SKILL.md file from .claude/skills/{skill-name}/SKILL.md
- Very specific: line 179
Follow the workflow defined in that skill's SKILL.md
- Distinctive: line 193
After all skills have executed, aggregate and normalize the findings.
- Distinctive: line 212
Ensure consistent severity across all skills:
- Distinctive: line 213
Use a unified Critical / High / Medium / Low / Info scale
- Distinctive: line 278
Use the project's detected language, framework, and library versions
- Very specific: line 280
If the project contains secure counterparts (e.g., // SECURE VERSION:), reference them
- Distinctive: line 282
Start with the simplest fix, then mention more comprehensive alternatives
- Distinctive: line 330
Document what was NOT tested and why:
- Distinctive: line 335
Start the application server and re-run with DAST enabled
- Distinctive: line 336
Add API specification files for contract testing
- Very specific: line 339
After applying fixes, run /remediation-validator to confirm vulnerabilities are resolved and detect regressions
“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.
Files
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
| # | Skill | Description |
| 1 | llm-sast-scanner | Static Application Security Testing — source code analysis for 34+ vulnerability classes using taint tracking and pattern matching |
| 2 | dast-scanner | Dynamic Application Security Testing — running endpoint probing, fuzzing, and runtime vulnerability detection against live services |
| 3 | dependency-audit | Dependency vulnerability scanning — identifies known CVEs in third-party packages and transitive dependencies |
| 4 | security-config-review | Infrastructure and configuration hardening review — Docker, CI/CD, cloud IaC, framework settings |
| 5 | api-contract-testing | API specification vs behavior validation — detects undocumented endpoints, schema mismatches, auth bypass |
| 6 | secrets-scanner | Hardcoded secrets detection — scans source code, config files, and git history for leaked credentials |
| 7 | compliance-mapper | Framework 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 File | Language/Runtime |
package.json | Node.js / TypeScript |
requirements.txt / pyproject.toml / Pipfile / setup.py | Python |
pom.xml / build.gradle / build.gradle.kts | Java / Kotlin |
Gemfile | Ruby |
go.mod | Go |
composer.json | PHP |
Cargo.toml | Rust |
*.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 timeoutAlso 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:
| Skill | Condition | Category |
secrets-scanner | Any text files exist in the project | Always |
llm-sast-scanner | Source code files exist in a supported language | Always |
dependency-audit | At least one manifest or lock file found | Conditional |
security-config-review | Docker, CI/CD, cloud, or framework configuration files found | Conditional |
api-contract-testing | API specification file found OR a live server detected | Conditional |
dast-scanner | A live HTTP server detected on a probed port | Conditional |
compliance-mapper | Any findings produced by the above skills | Always (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):
secrets-scanner— Fast scan, catches critical credential leaks immediatelyllm-sast-scanner— Comprehensive source code analysis across all vulnerability classesdependency-audit— Check packages against CVE databasessecurity-config-review— Review infrastructure and framework configurationsapi-contract-testing— Validate API behavior against specifications (if spec found or server running)dast-scanner— Active probing against running endpoints (most time-intensive, requires live server)compliance-mapper— Aggregate all findings and map to compliance frameworks (always runs last)
Execution process for each skill:
- Use the Read tool to load the skill's
SKILL.mdfile from.claude/skills/{skill-name}/SKILL.md - Follow the workflow defined in that skill's SKILL.md
- Collect all findings in a structured format (ID, title, severity, location, evidence, remediation)
- Track execution status: completed, skipped (condition not met), or failed (error during execution)
- 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_protectfor 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:
| Priority | Criteria | Action |
| P1 — Immediate | Critical severity + Low effort | Fix now, these are quick wins with maximum impact |
| P2 — Short-term | High severity, or Critical + High effort | Schedule for current sprint |
| P3 — Medium-term | Medium severity | Plan for next sprint or release cycle |
| P4 — Long-term | Low severity, architectural changes | Add 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-validatorto confirm vulnerabilities are resolved and detect regressions
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
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.

