vibe-security-check

name	vibe-security-check
description	Automated security audit and remediation skill for vibe-coded apps. Use this skill whenever a user wants to check, audit, harden, or secure their app before shipping — even if they don't use the word "security". Trigger phrases include: "check my app before I launch", "make my app production-ready", "is my app safe to ship?", "run a security check", "harden my codebase", "vibe security audit", "security scan my project", or "I'm about to deploy, what should I check?". Also trigger proactively when a user mentions they built their app with AI (Cursor, Lovable, Bolt, Claude Code, etc.) and are preparing to launch or share it publicly. This skill scans the codebase, detects which security domains are present, runs only the relevant checks, auto-fixes vulnerabilities directly in the code, and produces a clean security report — all without requiring any configuration from the user.
license	MIT
metadata	{"version":"1.0.0","author":"open-source (vibe-security-check)","tags":["security","vibe-coding","authentication","vulnerability-scan","production-readiness","web-app","api-security","owasp"],"trigger_phrases":["check my app security","security audit my project","is my app safe to ship","run vibe security check","harden my app","make my app production-ready","scan for vulnerabilities","security review before launch"],"compatible_tools":["claude-code","cursor","windsurf","claude-cowork","any-ai-ide"]}

Vibe Security Check

⚠️ Disclaimer: This skill identifies and fixes the most common vulnerability patterns in vibe-coded apps. It is not a substitute for a professional penetration test for high-stakes applications handling sensitive data, financial transactions, or regulated information. For those cases, engage a qualified security firm after running this skill.

What This Skill Does

You built something great — now let's make sure it's safe to ship. This skill acts like a senior security engineer reviewing your codebase. It scans your project, figures out which security checks are relevant (skipping anything that doesn't apply to your app), then identifies vulnerabilities and fixes them directly in your code. When it's done, you get a clean report showing what was found, what was fixed, and anything that needs your attention.

No configuration needed. Just activate it and let it run.

---

Execution Workflow

When this skill is activated, follow these four phases in order. Read the full module specifications in references/modules.md before beginning Phase 1.

Phase 0 — Project Reconnaissance

Before touching any code, build a map of what exists in the project. This determines which security modules to run and which to skip.

Scan for the following signals:

1. Stack detection — Check for package.json, requirements.txt, Pipfile, Gemfile, composer.json, go.mod, Cargo.toml. Identify the primary language and framework (Next.js, Express, FastAPI, Django, Rails, Laravel, etc.).

2. Authentication signals — Look for files/patterns: auth, login, signup, register, session, passport, nextauth, supabase/auth, firebase/auth, bcrypt, argon2, password_hash, devise, sanctum. Also grep for password in route/controller files.

3. JWT signals — Search for jwt, jsonwebtoken, jose, PyJWT, jwt-decode, Bearer, sign(, verify( in server files, localStorage.setItem near token storage.

4. Password reset signals — Search for reset, forgot, resetToken, reset_token, sendPasswordReset, password_reset in routes, controllers, or API files.

5. Admin route signals — Search for /admin, isAdmin, role, permission, middleware/admin, admin.js, admin.py, admin_required.

6. File upload signals — Search for multer, formidable, busboy, UploadFile, FileField, has_attached_file, store(, S3, cloudinary, multipart, enctype="multipart/form-data".

7. Webhook signals — Search for /webhook, stripe.webhooks, svix, HMAC, x-hub-signature, webhook_secret in route files.

8. Database query signals — Search for raw SQL patterns: query(, execute(, raw(, ${} inside SQL strings, f"SELECT, sprintf with SQL, .where( with string interpolation.

9. Frontend rendering signals — Search for innerHTML, dangerouslySetInnerHTML, eval(, document.write(, v-html (Vue), [innerHTML] (Angular).

10. CORS signals — Search for cors(, Access-Control-Allow-Origin, origin: '*', CORS_ORIGIN, add_middleware(CORSMiddleware.

11. Error handling signals — Search for console.error, res.status(500).json, print(traceback, render json: { error:, return JsonResponse({ 'error':.

12. Dependency manifest — Check for package.json, package-lock.json, yarn.lock, requirements.txt, Pipfile.lock, Gemfile.lock, composer.lock.

13. Deployment config signals — Check for .env, .env.example, docker-compose.yml, Dockerfile, vercel.json, railway.toml, render.yaml, fly.toml, Heroku Procfile.

14. Secrets exposure signals — Scan ALL files (especially .js, .ts, .py, .rb, .php, .env, .json, .yml) for patterns: sk_live_, sk_test_, AKIA, AIza, ghp_, hardcoded connection strings with passwords, mongodb+srv://user:password.

After scanning, output a Reconnaissance Report:

## 🔍 Reconnaissance Complete

**Stack detected:** [e.g., Next.js 14 / TypeScript / PostgreSQL / Prisma]

**Security modules that will run:**
- [x] SEC-01: Secrets & API Key Exposure (hardcoded keys found in 2 files)
- [x] SEC-02: Secure Authentication (auth system detected)
- [ ] SEC-03: JWT Security — SKIPPED (no JWT usage detected)
...

**Modules skipped:** SEC-03, SEC-04, SEC-09, SEC-11
**Reason for skips:** Listed inline above

---

Phase 1 — Sequential Security Checks

Execute each applicable module from references/modules.md in order (SEC-01 through SEC-13). For each module:

• Read the module spec from references/modules.md
• Run the detection step to find specific vulnerable files/lines
• Apply the remediation directly to the codebase
• Before modifying any file, log: [SEC-XX] Modifying <filename>: replacing <old pattern> with <new pattern> because <reason>
• Never delete code silently — always log what is being replaced and why
• Record each finding with severity and fix status

Severity levels:

• Critical — can be exploited immediately by anyone, data breach risk (e.g., exposed API key)
• High — significant attack vector, requires some effort to exploit (e.g., no rate limiting)
• Medium — real risk but requires specific conditions (e.g., verbose error messages)
• Low — defense-in-depth improvement, low direct risk (e.g., missing security headers)

---

Phase 2 — Dependency Vulnerability Scan

Run the appropriate audit command based on detected package manager:

Package Manager	Command
npm / yarn / pnpm	npm audit --json
pip	pip-audit --format json (install with pip install pip-audit if missing)
Bundler (Ruby)	bundle audit check --update (install with gem install bundler-audit if missing)
Composer (PHP)	composer audit
Go modules	govulncheck ./... (install with go install golang.org/x/vuln/cmd/govulncheck@latest if missing)

Parse the output and:

1. List all Critical and High severity CVEs with the package name, current version, and safe version
2. For each, check if a non-breaking upgrade exists (patch or minor bump) and apply it to the manifest file
3. Flag any packages that are abandoned/unmaintained (last release >2 years ago) — mark as "Needs manual review"
4. If the audit tool is not available and cannot be installed (e.g., no internet), note this in the report

---

Phase 3 — Final Security Report

After all checks are complete, generate the following report. This report should be saved as SECURITY_AUDIT_REPORT.md in the project root AND printed to the conversation.

See references/report_template.md for the exact report format to use.

---

Reference Files

• references/modules.md — Full specifications for all 15 security check modules (SEC-01 through SEC-15)
• references/report_template.md — Exact template for the final security report

Read both reference files before beginning Phase 1.

---

CHANGELOG

v1.0.0 (2026-04-07)

• Initial release
• 15 security check modules covering OWASP Top 10 and common vibe-coding vulnerabilities
• Framework support: Node.js/Express, Python/FastAPI/Django, Ruby on Rails, PHP/Laravel
• Auto-remediation with full change logging
• Multi-platform publishing: GitHub, Smithery, SkillHub, SkillMP

---

Publishing & Distribution

1. GitHub (Open Source)

Recommended repository structure:

vibe-security-check/
├── SKILL.md                    ← This file
├── references/
│   ├── modules.md              ← All 15 security check modules
│   └── report_template.md      ← Security report template
├── evals/
│   └── evals.json              ← Test cases
├── README.md                   ← Human-friendly intro (see below)
├── LICENSE                     ← MIT License
└── .github/
    └── CONTRIBUTING.md         ← Contribution guidelines

README.md should include:

• One-line description
• What problems it solves (for vibe coders)
• Installation instructions for each platform
• A short demo GIF or screenshot of the report output
• Link to the security modules reference
• How to contribute new security checks

LICENSE: Use MIT License. Template at https://opensource.org/licenses/MIT

To publish: Create a new GitHub repo, push this directory, add topics: security, claude-skill, vibe-coding, owasp, ai-coding-tools.

2. Smithery

1. Go to https://smithery.ai and create an account or sign in
2. Click "Publish Skill" and select "Upload SKILL.md"
3. Fill in metadata from the YAML frontmatter above
4. Set category to "Security & DevOps"
5. Add the GitHub repo URL as the source
6. Submit for review — Smithery typically approves within 48 hours

3. SkillHub

1. Go to https://skillhub.dev and sign in
2. Navigate to "Submit a Skill"
3. Paste the YAML frontmatter fields into the submission form
4. Upload SKILL.md and the references/ directory as a zip
5. Select tags: security, web-app, owasp, vibe-coding
6. Add a short video demo (optional but increases visibility)

4. SkillMP

1. Go to the SkillMP marketplace and create a publisher account
2. Use the CLI: skillmp publish ./vibe-security-check (install with npm i -g skillmp)
3. The CLI reads the YAML frontmatter automatically
4. Run skillmp validate first to catch any schema issues
5. Set pricing to "Free" and license to "MIT" to maximize adoption