🔐 Secure Vibe Coding Toolkit

Advanced configuration of toolings, skills, and markdowns for automated code review and security auditing in vibe-coded applications.

🇪🇸 Español

Mega-research + toolkit de hardening de seguridad para cualquier proyecto vibe-coded: apps web, AI assistants / chatbots / LLM apps, SaaS multi-tenant, backends, APIs y proyectos de desarrollo en general.

Meta: que cada proyecto pase por un análisis de procesos estandarizado y quede lo más blindado posible contra hackeos, fugas de llaves, inyecciones (SQL, prompt, command), falta de rate limiting, IDOR, RLS mal configurada, secretos en git, supply-chain, etc.

Este repositorio es la fuente de verdad. Clónalo y dile a Claude Code (u otro agente) que venga a esta ruta y use todo lo que hay aquí para auditar y blindar otro proyecto.

📦 Qué contiene (ES)

security/                              ← raíz del toolkit (clona aquí)
├── README.md                          ← este archivo (índice de uso)
├── LICENSE                            ← MIT
├── CONTRIBUTING.md                    ← cómo aportar
├── .gitignore
├── docs/
│   ├── checklists/
│   │   └── 00-checklist-maestro.md    ← Gate de lanzamiento (yes/no por ítem)
│   ├── procedimientos/
│   │   └── flujo-auditoria.md         ← Flujo end-to-end de auditoría (7 fases)
│   └── vulnerabilidades/
│       ├── ES/                        ← Las 13 guías prescriptivas en español
│       └── EN/                        ← Las mismas 13 guías en inglés
├── skill/
│   ├── secure-vibe/                   ← Skill en español: /secure-vibe
│   └── secure-vibe-EN/                ← Skill en inglés: /secure-vibe-en
├── tooling/
│   ├── ci-templates/                  ← 5 workflows de GitHub Actions listos
│   ├── scripts/                       ← scan_secrets.py, check_lockfiles.py
│   └── pre-commit-config.yaml         ← Hooks locales (gitleaks + scripts)
└── plantillas/
    ├── ES/                            ← Reglas preventivas en español
    └── EN/                            ← Reglas preventivas en inglés

🚀 Inicio rápido (ES — 3 pasos)

# 1. Clona el toolkit
git clone https://github.com/yedinrumba-eng/Secure-Vibe.git
cd Secure-Vibe

# 2. (Opcional) verifica que no haya residuos antes de usarlo — cero hallazgos esperados
python tooling/scripts/scan_secrets.py . --no-history

A partir de aquí tienes 3 modos de uso (lo recomendado es A + C siempre, y B al final):

• Modo A — Copia plantillas/ES/CLAUDE.md (Claude Code) o plantillas/ES/AGENTS.md (Cursor/Copilot/Codex/Windsurf) a la raíz del proyecto que vas a construir.
• Modo B — Abre Claude Code en la carpeta del proyecto a auditar y ejecuta /secure-vibe.
• Modo C — Copia los workflows de tooling/ci-templates/ a .github/workflows/ del proyecto objetivo.

Para el detalle completo de cada modo, lee la versión en inglés ⬇ (índice canónico) o los docs en docs/vulnerabilidades/ES/.

🎯 Categorías cubiertas (13 — ES)

🧠 Filosofía (ES)

1. Prevención > detección. Las reglas AGENTS.md/CLAUDE.md evitan que el bug se escriba.
2. Defensa en profundidad. Ninguna capa es suficiente; combina validación + authz + RLS + rate limit + logging.
3. Server-side es la verdad. El frontend no es seguridad. El backend valida todo.
4. Default-deny. Todo (RLS, CORS, permisos, tool calls) arranca cerrado y se abre explícitamente.
5. Mínimo privilegio. Keys, tokens, db users, CI tokens: solo lo necesario, con scope mínimo, rotables.

⚖️ Disclaimer (ES)

Este toolkit no reemplaza a un pentester ni a un proceso formal de AppSec. Es un piso mínimo ambicioso para proyectos vibe-coded. Cuando haya datos reales de usuarios, pagos, salud, finanzas o legales → contrata a un humano experto y haz pentest profesional (ver docs/procedimientos/flujo-auditoria.md).

🤝 Contribuir (ES)

¿Encontraste un caso que el toolkit no cubre? ¿Un patrón nuevo? ¿Una mitigación mejor? Lee CONTRIBUTING.md y abre un PR. Toda contribución debe mapear a OWASP/CWE y usar snippets verificables (los ❌ reproducibles, los ✅ que compilan).

🇺🇸 English

A mega-research + security hardening toolkit for any vibe-coded project: web apps, AI assistants / chatbots / LLM apps, multi-tenant SaaS, backends, APIs and general development projects.

Goal: every project goes through a standardized process analysis and ends up as hardened as possible against hacks, key leaks, injections (SQL, prompt, command), missing rate limiting, IDOR, misconfigured RLS, secrets in git, supply-chain, etc.

This repository is the source of truth. Clone it and tell Claude Code (or another agent) to come to this path and use everything here to audit and harden another project.

📦 What's inside (EN)

security/                              ← toolkit root (clone here)
├── README.md                          ← this file (usage index)
├── LICENSE                            ← MIT
├── CONTRIBUTING.md                    ← how to contribute
├── .gitignore
├── docs/
│   ├── checklists/
│   │   └── 00-checklist-maestro.md    ← Release gate (yes/no per item)
│   ├── procedimientos/
│   │   └── flujo-auditoria.md         ← End-to-end audit flow (7 phases)
│   └── vulnerabilidades/
│       ├── ES/                        ← The 13 prescriptive guides in Spanish
│       └── EN/                        ← The same 13 guides in English
├── skill/
│   ├── secure-vibe/                   ← Skill in Spanish: /secure-vibe
│   └── secure-vibe-EN/                ← Skill in English: /secure-vibe-en
├── tooling/
│   ├── ci-templates/                  ← 5 ready-to-use GitHub Actions workflows
│   ├── scripts/                       ← scan_secrets.py, check_lockfiles.py
│   └── pre-commit-config.yaml         ← Local hooks (gitleaks + scripts)
└── plantillas/
    ├── ES/                            ← Preventive rules in Spanish
    └── EN/                            ← Preventive rules in English

🚀 Quick start (EN — 3 steps)

# 1. Clone the toolkit
git clone https://github.com/yedinrumba-eng/Secure-Vibe.git
cd Secure-Vibe

# 2. (Optional) verify there's no residue before using it — zero findings expected
python tooling/scripts/scan_secrets.py . --no-history

From here you have 3 usage modes (recommended: A + C always, and B at the end):

Mode A — Prevention (during coding, before the bug exists) 🛡️

Copy the template that matches your editor into the root of the project you're going to build (not the toolkit's):

# If you use Claude Code:
cp plantillas/EN/CLAUDE.md   /path/to/your-project/CLAUDE.md

# If you use Cursor / Copilot / Codex / Windsurf:
cp plantillas/EN/AGENTS.md   /path/to/your-project/AGENTS.md

• The agent reads the MUST / MUST NOT rules while generating code and writes secure patterns by default.
• Prevention is 10× cheaper than detection. This is the primary mode.
• If your editor is Copilot, Copilot reads AGENTS.md only if you also place it in .github/copilot-instructions.md (see the header of plantillas/EN/AGENTS.md).

Mode B — Audit / Hardening (when the project already exists) 🔍

Open Claude Code in the folder of the project to audit (not the toolkit's) and run:

/secure-vibe-en

If the skill is not installed globally in your Claude Code, open Claude Code directly in the toolkit folder and invoke the skill, or say in natural language: "Act as a security auditor using the toolkit's checklists I just cloned to audit the project at <target project path>."

The skill will:

1. Detect the target project's stack.
2. Run category-by-category analysis (SAST, secrets, RLS, prompt injection, auth/authz, rate limiting, supply-chain, CI/CD, billing…).
3. Score each finding by severity (Critical / High / Medium / Low / Info).
4. Generate a SECURITY-AUDIT-REPORT.md in the project root with a prioritized remediation plan (what to fix first, how, and how to verify it).

For a manual review or a no-agent release gate, follow docs/checklists/00-checklist-maestro.md directly (rows C1–C10 CRITICAL, H1–H20, M1–M15, L1–L10, AI1–AI11, S1–S8).

Mode C — Continuous automation (CI/CD) ⚙️

Copy the workflows from tooling/ci-templates/ into .github/workflows/ of the target project:

# In the project you want to protect (not the toolkit):
mkdir -p .github/workflows
cp /path/to/toolkit/tooling/ci-templates/*.yml .github/workflows/

# Local pre-commit hooks (optional):
cp /path/to/toolkit/tooling/pre-commit-config.yaml .pre-commit-config.yaml
pip install pre-commit
pre-commit install

Every push/PR will run:

• Secret scanning (gitleaks) — over the repo and the full git history.
• SAST (semgrep) — OWASP + security-audit rulesets + per-language.
• Dependency/SCA scan (osv-scanner) — 9 lockfiles supported, daily schedule.
• Container scan (trivy) — filesystem + Docker image, HIGH/CRITICAL severity.
• Lockfile integrity — npm + pnpm, detects commits without regenerating the lockfile.

Each workflow is an independent required check for branch protection (one per tool — consistent with docs/vulnerabilidades/EN/11-ci-cd-containers.md). All run with permissions: contents: read (least privilege); none use pull_request_target.

The actual deploy blocking is configured via branch protection + required checks on GitHub (Settings → Branches → Require status checks). CI only emits the status; the branch is what blocks.

🎯 Categories covered (13 — EN)

Consolidated from OWASP Top 10 (2021 + 2025), OWASP LLM Top 10 2025, PortSwigger cheatsheets, benavlabs/vibe-check (17 checks), Hainrixz/cyber-neo (11 domains), theaiworks, nxcode, superblocks and community research.

🧠 Philosophy (EN)

1. Prevention > detection. The AGENTS.md/CLAUDE.md rules prevent the bug from being written.
2. Defense in depth. No single layer is enough; combine validation + authz + RLS + rate limit + logging.
3. Server-side is the truth. The frontend is not security. The backend validates everything.
4. Default-deny. Everything (RLS, CORS, permissions, tool calls) starts closed and is opened explicitly.
5. Least privilege. Keys, tokens, db users, CI tokens: only what's needed, with minimal scope, rotatable.

⚖️ Disclaimer (EN)

This toolkit does not replace a pentester or a formal AppSec process. It's an ambitious minimum floor for vibe-coded projects. When there's real user data, payments, health, finance or legal data → hire an expert human and do a professional pentest (see docs/procedimientos/flujo-auditoria.md).

🤝 Contributing (EN)

Found a case the toolkit doesn't cover? A new pattern? A better mitigation? Read CONTRIBUTING.md and open a PR. Every contribution must map to OWASP/CWE and use verifiable snippets (the ❌ reproducible, the ✅ that compile).

📄 License

MIT © 2026 yedinrumba-eng.