Systematic DevSecOps Analysis for Claude Code — 5-layer security review with standardized severity-tagged alerts
🚀 Quick Start • 📖 Documentation • 🧪 Test Results • 🐛 Report Bug
Complete rebuild with TDD methodology:
- ✅ Systematic 5-layer review enforced (no ad-hoc analysis)
- ✅ Standardized severity-tagged alerts (CRITICO/ALTO/MEDIO/BAJO)
- ✅ Proactive scope expansion beyond user request
- ✅ Reference material split into dedicated files (secret patterns, tests)
- ✅ Dynamic verification layer (optional, localhost-only runtime probing)
- ✅ Manually evaluated against time/authority/exhaustion scenarios
- ✅ Full evaluation notes included
Observed in manual evaluation: 6-8 categorized alerts vs 1-2 ad-hoc findings on the same test scenarios. These are qualitative comparisons, not automated benchmarks.
See FINAL-REPORT.md for the full evaluation notes.
Every security review follows this structured methodology:
- Code Validation — Input validation, injection (SQL/XSS/Command), auth/authz, error handling
- Dependencies — CVEs, outdated packages, unmaintained libraries, transitive dependencies
- Secrets & PII — Hardcoded API keys, tokens, certificates, exposed personal data
- CI/CD Pipeline — Branch restrictions, secret exposure, security gates, rollback plans
- Infrastructure — Network exposure, IAM/RBAC permissions, encryption, security groups
No layer skipped — even "frontend-only" code triggers full review.
Every finding includes:
| Campo | Valor |
|---|---|
| Severidad | 🔴 CRITICO | 🟠 ALTO | 🟡 MEDIO | 🟢 BAJO |
| ID | CD-SEC-XXX (sequential) |
| Componente | file.js:line or resource name |
| Descripción | What + why it's a risk |
| Evidencia | Code snippet or config excerpt |
| Remediación | Specific fix steps |
┌─────────────────────────────────────────────┐
│ ESTADO DE SEGURIDAD │
├─────────────────────────────────────────────┤
│ Nivel de riesgo: CRITICO │
│ Alertas totales: 8 │
│ - Críticas: 2 │
│ - Altas: 3 │
│ - Medias: 2 │
│ - Bajas: 1 │
├─────────────────────────────────────────────┤
│ RECOMENDACIÓN: │
│ BLOQUEAR despliegue hasta resolver │
│ hallazgos críticos y altos. │
└─────────────────────────────────────────────┘
# Install from local directory
git clone https://github.com/DevCop95/cyhber-deploy.git
cd cyhber-deploy
cp -r skills/cyhber-deploy ~/.claude/skills/# Check skill is loaded
claude # Start Claude Code session
# Skill auto-triggers on: deploy, CI/CD, Terraform, auth, secrets, injectionSkill activates when you mention:
- Deploy: staging, production, release
- CI/CD: GitHub Actions, GitLab CI, Jenkins, CircleCI
- IaC: Terraform, Kubernetes, Docker, Helm
- Cloud: AWS, GCP, Azure
- Security: auth, secrets, injection, SQL, XSS
- Review: "security review", "check this code"
@cyhber-deploy review this for production
Input:
app.post('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/login', (req, res) => {
db.query(`SELECT * FROM users WHERE email='${req.body.email}'`);
});Output:
| Campo | Valor |
|---|---|
| Severidad | 🔴 CRITICO |
| ID | CD-SEC-001 |
| Componente | api/auth.js:2 |
| Descripción | SQL injection - user-controlled email concatenated into query |
| Evidencia | db.query(`SELECT * FROM users WHERE email='${req.body.email}'`) |
| Remediación | Use parameterized query: db.query('SELECT * FROM users WHERE email = ?', [req.body.email]) |
Input:
# .github/workflows/deploy.yml
- run: |
echo "API_KEY=${{ secrets.API_KEY }}" >> .env
cat .envOutput:
| Campo | Valor |
|---|---|
| Severidad | 🔴 CRITICO |
| ID | CD-SEC-002 |
| Componente | .github/workflows/deploy.yml:3 |
| Descripción | API key exposed in workflow logs via cat .env |
| Evidencia | cat .env prints secrets to logs accessible to all repo users |
| Remediación | Remove cat .env. Pass secrets via env vars: env: API_KEY: ${{ secrets.API_KEY }} |
Input:
resource "aws_security_group" "db" {
ingress {
cidr_blocks = ["0.0.0.0/0"]
from_port = 5432
to_port = 5432
}
}Output:
| Campo | Valor |
|---|---|
| Severidad | 🔴 CRITICO |
| ID | CD-SEC-003 |
| Componente | terraform/main.tf:3 |
| Descripción | Database exposed to entire internet via overly permissive security group |
| Evidencia | cidr_blocks = ["0.0.0.0/0"] allows connections from any IP |
| Remediación | Restrict to application subnet: cidr_blocks = ["10.0.1.0/24"] or use VPC peering |
A zero-dependency Python renderer turns findings into colored alert cards plus a final ESTADO DE SEGURIDAD panel — a visual recap of the scan, right in your terminal.
# See it instantly with the bundled demo
python tools/cyhber_report.py --demo
# Render your own findings (see schema in tools/findings.example.json)
python tools/cyhber_report.py findings.json
# Pipe from another tool
cat findings.json | python tools/cyhber_report.pyPreview:
┌────────────────────────────────────────────────┐
│ ESTADO DE SEGURIDAD │
│ Objetivo: examples/vulnerable-api/server.js │
├────────────────────────────────────────────────┤
│ Nivel de riesgo: CRITICO │
│ Alertas totales: 8 │
│ - CRITICO 3 │
│ - ALTO 3 │
│ - MEDIO 1 │
│ - BAJO 1 │
├────────────────────────────────────────────────┤
│ RECOMENDACIÓN: │
│ BLOQUEAR despliegue — resolver críticos/altos │
└────────────────────────────────────────────────┘
- Pure stdlib (no
pip install), works on Windows / macOS / Linux. - Auto-detects color; honors
NO_COLOR/FORCE_COLOR. - Exit code
1when the run should block (any 🔴 or ≥3 🟠),0otherwise — drop it straight into a CI gate.
Static review finds suspected issues; this optional layer confirms them at runtime. Before emitting the verdict, Cyhber Deploy can spin up a throwaway, localhost-only instance of the project and probe it, so the final report separates "possible" from "proven-live".
# Boot the app on localhost, probe it, tear it down, and render the verdict:
python tools/dynamic_probe.py --boot "node server.js" --cwd examples/vulnerable-api \
--port 3000 --route "/search:q" --route "/login:email" --allow-active --json \
| python tools/cyhber_report.py🔒 Authorization boundary.
dynamic_probe.pyrefuses any non-loopback target (it only ever hits 127.0.0.1 / localhost). It is for testing a local, ephemeral instance you own — never a staging box, a LAN host, or anyone else's system.
What it does, safely:
- Loopback-only hard gate — can't be pointed at a third party.
- Non-destructive by default — GET-based probes; no DELETE/DROP. Mildly-active
checks (e.g. SQLi single-quote error) are opt-in via
--allow-active. - Time-boxed — per-request timeout + global budget so you don't DoS your own box.
- Confirmed findings are tagged
verified: trueand flow into the same verdict panel.
Built following OWASP DAST guidance for ephemeral environments: active testing runs only against isolated, throwaway instances, scope-restricted and time-boxed.
For a full-featured scanner, point OWASP ZAP's baseline scan at the same local instance — this layer is a zero-dependency smoke test, not a ZAP replacement.
References:
- OWASP DevSecOps Guideline — Dynamic Application Security Testing
- OWASP ZAP — baseline/full/API scans & automation framework
Skill built following complete RED-GREEN-REFACTOR cycle:
- RED Phase: Baseline testing without skill (3 pressure scenarios)
- GREEN Phase: Skill enforcement verification (systematic 5-layer review)
- REFACTOR Phase: Edge case testing (frontend-only code)
| Metric | Baseline (No Skill) | With Skill |
|---|---|---|
| Issues found | 1-2 | 6-8 |
| Structure | Ad-hoc | 5-layer systematic |
| Output format | Freeform | Severity tables |
| Scope | Limited | Proactive expansion |
Numbers come from manual evaluation on the bundled test scenarios, not from an automated benchmark suite. Treat them as directional, not guaranteed.
Full documentation: tests/FINAL-REPORT.md
- SKILL.md — Complete skill specification
- secret-patterns.md — 35 secret detection patterns
- FINAL-REPORT.md — TDD testing documentation
- Examples — Vulnerable and secure code samples
- tools/cyhber_report.py — Terminal report renderer (visual layer)
- tools/dynamic_probe.py — Dynamic verification (Layer 6, localhost-only)
Built-in detection for:
- AWS keys (AKIA...), Azure, GCP service accounts
- GitHub tokens (ghp_, gho_, glpat-)
- Private keys (RSA, EC, OpenSSH, PGP)
- Database connection strings
- JWT tokens
- Slack/Discord webhooks
- Payment provider keys (Stripe, PayPal, Square)
See secret-patterns.md for complete list.
Contributions welcome! For major changes:
- Fork repo
- Create feature branch (
git checkout -b feature/improvement) - Follow TDD methodology (see tests/ for examples)
- Commit with conventional commits
- Push and open PR
DO NOT open public issues for vulnerabilities.
Email: yared.henriquezb@gmail.com
- Dynamic verification layer (localhost-only runtime probing)
- SARIF output format for CI/CD integration
- Custom rule configuration (.cyhber-deploy.json)
- Multi-language support (Django, Flask, Spring Boot)
- GitHub Action for automated PR reviews
- VS Code extension
- Dashboard for security metrics over time
MIT License - see LICENSE
Author: DevCop95
Built with guidance from:
- Claude Code Superpowers - TDD methodology for skills
- Anthropic Claude - AI platform
Inspired by:
- Semgrep - SAST scanning
- Snyk - Dependency analysis
- TruffleHog - Secret detection
- OWASP - Security standards
- 🐛 Issues
- 💬 Discussions
- 📧 Email: yared.henriquezb@gmail.com
- 🐦 X/Twitter: @Devcop101
Cyhber Deploy provides static analysis and does not replace professional security audits or penetration testing. Use as complement to existing security practices.
Production-Ready • TDD-Tested • Open Source
⭐ Star this repo if it helps your security workflow!