cyhber-deploy · diff
git:20260511.4c24f87 to git:20260511.7e033ba
237 added, 340 removed. Audit B to A.
---
name: cyhber-deploy
- description: Acompaña todo el ciclo de desarrollo y despliegue revisando seguridad en código, CI/CD e infraestructura, emitiendo alertas y recomendaciones accionables.
+ description: Use when preparing staging/production deploys, modifying CI/CD pipelines (GitHub Actions, GitLab CI, Jenkins), changing IaC (Terraform, Kubernetes, Docker), handling authentication/authorization/sessions/secrets, detecting injection vulnerabilities, reviewing security groups/IAM/RBAC, hardcoded credentials, exposed endpoints, or requesting security reviews
---
# Cyhber Deploy
- ## Visión general
-
- Cyhber Deploy es un skill de seguridad y DevSecOps que acompaña todo el ciclo de desarrollo y despliegue de un proyecto de software.
-
- Cuando este skill esté activo:
-
- - Analiza cambios de código, configuración, pipelines CI/CD e infraestructura relacionada con despliegues.
- - Identifica riesgos de seguridad y malas prácticas antes de que el código llegue a producción.
- - Emite alertas con severidad y recomendaciones claras para corregir problemas.
- - Señala también riesgos que encuentre fuera de la petición original del usuario, si afectan a la seguridad del proyecto.
+ ## Overview
- ## Cuándo usar Cyhber Deploy
+ Systematic DevSecOps review methodology enforcing 5-layer analysis with standardized severity-tagged alerts.
- Cyhber Deploy debe activarse o considerarse relevante cuando el usuario:
+ **Purpose:** Ensure comprehensive, structured security review - not ad-hoc vulnerability detection.
- - Está preparando un despliegue a staging o producción.
- - Modifica pipelines CI/CD (por ejemplo, GitHub Actions, GitLab CI, etc.).
- - Cambia configuración de contenedores, Kubernetes, Terraform u otra infraestructura como código.
- - Toca autenticación, autorización, manejo de sesiones o datos sensibles.
- - Pide una revisión de seguridad del proyecto o de una parte del repositorio.
+ ## When to Use
- ## Flujo de trabajo general
+ **Trigger on:**
+ - Deploy preparation (staging/production)
+ - CI/CD changes (workflows, pipelines, build scripts)
+ - IaC modifications (Terraform, K8s, Docker, cloud config)
+ - Auth/authz/session handling code
+ - Secret management changes
+ - Security review requests
+ - Suspicious patterns (injection, exposed secrets, overprivileged access)
- Siempre que el usuario solicite ayuda relacionada con código, despliegues o infra:
+ **Also trigger when user mentions:**
+ - GitHub Actions, GitLab CI, Jenkins, CircleCI
+ - AWS, GCP, Azure cloud resources
+ - Docker, Kubernetes, Helm
+ - SQL queries, database access
+ - API keys, tokens, certificates
+ - Environment variables, config files
- 1. **Recolección de contexto**
- - Identifica o pregunta:
- - Lenguajes y frameworks principales.
- - Tipo de aplicación (API, backend, frontend, microservicios).
- - Entornos relevantes (dev, staging, producción).
- - Plataforma de despliegue (on-premise, AWS, GCP, Azure, Vercel, Railway, etc.).
- - Archivos, directorios o servicios implicados (código, CI/CD, IaC, configuración).
+ ## Systematic 5-Layer Review
- 2. **Resumen de la situación**
- - Resume en 2–4 frases qué se pretende hacer (bugfix, nueva feature, cambio de infra, despliegue).
- - Explica qué superficie de seguridad se ve afectada (endpoints, datos, redes, secretos).
+ **ALWAYS follow this order** - don't skip layers based on request scope:
- 3. **Análisis por capas**
- - Aplica revisiones en este orden:
- 1. Código de negocio y validación de entradas/salidas.
- 2. Dependencias y servicios externos.
- 3. Gestión de secretos y datos sensibles.
- 4. Pipelines CI/CD y proceso de despliegue.
- 5. Infraestructura y configuración (contenedores, redes, TLS, permisos).
+ ```dot
+ digraph security_review {
+ rankdir=TB;
+ "User request" [shape=doublecircle];
+ "Gather context" [shape=box];
+ "Summarize scope" [shape=box];
+ "Layer 1: Code validation" [shape=box];
+ "Layer 2: Dependencies" [shape=box];
+ "Layer 3: Secrets & PII" [shape=box];
+ "Layer 4: CI/CD pipeline" [shape=box];
+ "Layer 5: Infrastructure" [shape=box];
+ "Generate alerts" [shape=box];
+ "Calculate risk level" [shape=box];
+ "Block deployment?" [shape=diamond];
+ "BLOCK - Fix criticals first" [shape=box, style=filled, fillcolor=red];
+ "APPROVE - With mitigations" [shape=box, style=filled, fillcolor=green];
+
+ "User request" -> "Gather context";
+ "Gather context" -> "Summarize scope";
+ "Summarize scope" -> "Layer 1: Code validation";
+ "Layer 1: Code validation" -> "Layer 2: Dependencies";
+ "Layer 2: Dependencies" -> "Layer 3: Secrets & PII";
+ "Layer 3: Secrets & PII" -> "Layer 4: CI/CD pipeline";
+ "Layer 4: CI/CD pipeline" -> "Layer 5: Infrastructure";
+ "Layer 5: Infrastructure" -> "Generate alerts";
+ "Generate alerts" -> "Calculate risk level";
+ "Calculate risk level" -> "Block deployment?";
+ "Block deployment?" -> "BLOCK - Fix criticals first" [label="CRITICO/ALTO"];
+ "Block deployment?" -> "APPROVE - With mitigations" [label="MEDIO/BAJO"];
+ }
+ ```
- 4. **Alertas y recomendaciones**
- - Genera alertas estructuradas con severidad y acciones específicas.
- - Propone un orden de corrección por prioridad de riesgo.
+ ## Context Gathering
- 5. **Estado global**
- - Asigna un nivel de riesgo global del cambio o despliegue: BAJO, MEDIO, ALTO o CRITICO.
- - Indica explícitamente si recomendarías bloquear el despliegue hasta corregir ciertos puntos.
+ Ask if missing:
+ - **Languages/frameworks:** Node.js, Python, Go, Java, etc.
+ - **App type:** API, frontend, microservices, monolith
+ - **Environments:** dev, staging, production
+ - **Deploy platform:** AWS, GCP, Azure, on-premise, Vercel, Railway
+ - **Related files:** CI/CD configs, IaC, environment configs
- ## Formato de alertas
+ ## Standardized Alert Format
- Cuando detectes un problema de seguridad o una mala práctica relevante, genera una alerta con este formato:
+ **Every security issue MUST use this table:**
| Campo | Valor |
|-------|-------|
| **Severidad** | 🔴 CRITICO \| 🟠 ALTO \| 🟡 MEDIO \| 🟢 BAJO |
- | **ID** | Identificador corto (ej: `CD-SEC-001`) |
- | **Componente** | Archivo/recurso afectado |
- | **Descripción** | Qué ocurre y por qué es un riesgo |
- | **Evidencia** | Fragmento de código o patrón detectado |
- | **Remediación** | Pasos específicos para mitigar |
-
- ### Ejemplo de alerta
-
- | Campo | Valor |
- |-------|-------|
- | **Severidad** | 🟠 ALTO |
- | **ID** | CD-SEC-004 |
- | **Componente** | `.github/workflows/deploy.yml` |
- | **Descripción** | Job de despliegue a producción puede ejecutarse desde cualquier rama |
- | **Evidencia** | No hay restricción de rama en el trigger del workflow |
- | **Remediación** | Limitar trigger a ramas protegidas (main) y requerir revisión manual |
-
- Además de alertas, puedes añadir comentarios de mejora con un prefijo claro:
-
- - **Comentario:** Sugerencias que no bloquean el despliegue pero mejoran la postura de seguridad o mantenibilidad.
+ | **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 |
- ## Capa 1: Código y validación de entradas
+ **Severity levels:**
+ - 🔴 **CRITICO:** Immediate exploitation possible (injection, hardcoded secrets, public DB)
+ - 🟠 **ALTO:** Exploitation likely with recon (weak auth, missing authz, exposed admin)
+ - 🟡 **MEDIO:** Requires chained exploits (verbose errors, missing headers, old deps)
+ - 🟢 **BAJO:** Defense-in-depth improvements (logging gaps, config hardening)
- Al revisar código relacionado con nuevas features, bugfixes o refactors:
+ ## Layer 1: Code Validation
- ### 1.1 Entradas y salidas
- - Asegúrate de que todo input controlado por el usuario se valida (tipo, tamaño, formato, listas blancas).
- - Revisa que las respuestas no expongan datos sensibles innecesarios.
+ ### Input Validation
+ Check ALL user-controlled inputs:
+ - Type, size, format validation
+ - Whitelist over blacklist
+ - Reject vs sanitize (prefer reject)
- **Patrones a detectar:**
+ ### Injection Patterns
```javascript
- // ❌ MALO: Sin validación
- app.post('/user', (req, res) => {
- db.query(`SELECT * FROM users WHERE id = ${req.body.id}`);
- });
-
- // ✅ BUENO: Con validación y parametrización
- app.post('/user', (req, res) => {
- const id = parseInt(req.body.id);
- if (!Number.isInteger(id)) return res.status(400).send('Invalid ID');
- db.query('SELECT * FROM users WHERE id = ?', [id]);
- });
- ```
-
- ### 1.2 Inyección y ejecución
- - Detecta concatenación de strings en queries, comandos del sistema u otros contextos ejecutables.
- - Señala uso de funciones peligrosas (eval, exec, deserialización insegura).
+ // ❌ SQL Injection
+ db.query(`SELECT * FROM users WHERE id = ${req.body.id}`)
- **Patrones críticos:**
- ```python
- # ❌ CRITICO: Command injection
- os.system(f"ping {user_input}")
+ // ❌ Command Injection
+ exec(`ping ${userInput}`)
- # ❌ CRITICO: SQL injection
- cursor.execute(f"SELECT * FROM users WHERE name = '{username}'")
+ // ❌ NoSQL Injection
+ db.find({ user: req.body.user })
- # ✅ BUENO: Parametrización
- cursor.execute("SELECT * FROM users WHERE name = ?", (username,))
+ // ✅ Parameterized queries
+ db.query('SELECT * FROM users WHERE id = ?', [req.body.id])
```
- ### 1.3 Autenticación y autorización
- - Verifica que endpoints sensibles requieran autenticación y tengan controles de autorización adecuados.
- - Señala posibles IDOR u otros problemas de control de acceso.
-
- ### 1.4 Salida de la revisión de código
- - Lista las alertas relacionadas con código.
- - Propone snippets o cambios concretos donde sea útil, manteniendo el foco en seguridad y no sólo en estilo.
-
- ## Capa 2: Dependencias y servicios externos
-
- Cuando veas uso de dependencias, paquetes o servicios externos:
-
- ### Riesgos potenciales
- - Paquetes sin mantenimiento claro o versiones muy antiguas.
- - SDKs que gestionan pagos, identidad o datos sensibles sin configuración segura obvia.
- - Dependencias con vulnerabilidades conocidas (CVEs).
-
- ### Herramientas recomendadas
- - **SAST:** Semgrep, CodeQL, Snyk Code
- - **SCA:** Snyk, Dependabot, npm audit, pip-audit
- - **Secret scanning:** TruffleHog, git-secrets, GitGuardian
-
- ### Prácticas recomendadas
- - Uso de herramientas de análisis de dependencias en CI/CD.
- - Fijar versiones y evitar rangos demasiado abiertos cuando sea razonable.
- - Revisar notas de seguridad de librerías críticas.
- - Implementar renovación automática de dependencias (Renovate, Dependabot).
-
- ## Capa 3: Secretos y datos sensibles
-
- Para archivos de código, configuración e infraestructura:
-
- ### 3.1 Detección de secretos
-
- **Patrones comunes a detectar:**
- ```regex
- # AWS Keys
- AKIA[0-9A-Z]{16}
-
- # GitHub Token
- ghp_[a-zA-Z0-9]{36}
-
- # Private Keys
- -----BEGIN (RSA |EC |OPENSSH )?PRIVATE KEY-----
+ ### Auth/Authz
+ - Endpoints require authentication?
+ - Authorization checks present (not just authn)?
+ - IDOR vulnerabilities (user A access user B data)?
+ - Session management secure (httpOnly, secure, sameSite)?
- # Generic API Keys
- api[_-]?key[s]?\s*[:=]\s*['"][a-zA-Z0-9]{20,}['"]
- ```
+ ## Layer 2: Dependencies
- **Señalar como 🔴 CRITICO cuando:**
- - Un secreto real esté versionado en código.
- - Tokens o claves estén en variables de entorno sin protección.
- - Certificados privados estén expuestos.
+ **Check:**
+ - Outdated packages (>2 years old)
+ - Known CVEs (check npm audit, pip-audit, Snyk)
+ - Unmaintained libraries
+ - Transitive dependency surprises
- ### 3.2 Manejo seguro
+ **Tools to recommend:**
+ - SAST: Semgrep, CodeQL, Snyk Code
+ - SCA: Dependabot, Renovate, npm audit
+ - Secrets: TruffleHog, GitGuardian, git-secrets
- **Recomendaciones:**
- - Mover secretos a gestores seguros (AWS Secrets Manager, HashiCorp Vault, Azure Key Vault).
- - Usar variables de entorno con permisos restrictivos.
- - Proporcionar plantillas de configuración (`.env.example`) sin valores reales.
- - Implementar rotación automática de secretos.
+ ## Layer 3: Secrets & PII
- ### 3.3 Datos personales (PII)
+ ### Secret Patterns
+ See @secret-patterns.md for full regex list.
- Advierte cuando se procesa información potencialmente sensible sin protección adecuada:
- - Nombres, emails, números de teléfono.
- - Datos financieros, de salud o identificación gubernamental.
- - Datos de menores de edad.
+ **Common patterns:**
+ - AWS: `AKIA[0-9A-Z]{16}`
+ - GitHub: `ghp_[a-zA-Z0-9]{36}`
+ - Private keys: `-----BEGIN.*PRIVATE KEY-----`
+ - Generic API keys: `api[_-]?key.*['"][a-zA-Z0-9]{20,}['"]`
- **Sugiere:**
- - Minimizar recopilación y almacenamiento.
- - Encriptar en reposo y en tránsito.
- - Implementar políticas de retención.
+ **🔴 CRITICO when:**
+ - Hardcoded in source
+ - Logged to stdout/files
+ - Committed to git history
+ - Exposed in error messages
- ## Capa 4: CI/CD y proceso de despliegue
+ **Secure handling:**
+ - Move to Secrets Manager / Vault / Key Vault
+ - Env vars with restrictive permissions
+ - `.env.example` templates (no real values)
+ - Auto-rotation policies
- Al revisar pipelines y scripts de despliegue:
+ ### PII Detection
+ Flag unprotected handling of:
+ - Names, emails, phone numbers
+ - Financial, health, govt IDs
+ - Children's data
+ - IP addresses, geolocation
- ### 4.1 Pruebas y controles previos
+ **Recommend:**
+ - Minimize collection
+ - Encrypt at rest + transit
+ - Retention policies
+ - Anonymization where possible
- **Checklist mínimo:**
- - [ ] Tests unitarios y de integración
- - [ ] Análisis estático de código (SAST)
- - [ ] Escaneo de dependencias (SCA)
- - [ ] Escaneo de secretos
- - [ ] Linting y formateo
- - [ ] Build exitoso
+ ## Layer 4: CI/CD Pipeline
- ### 4.2 Permisos y secretos en la pipeline
+ ### Pre-Deploy Checklist
+ - [ ] Unit + integration tests
+ - [ ] SAST scan
+ - [ ] SCA scan
+ - [ ] Secret scan
+ - [ ] Linting + formatting
+ - [ ] Build success
- **GitHub Actions - Buenas prácticas:**
+ ### Pipeline Hardening
```yaml
- # ✅ BUENO: Permisos mínimos
+ # ✅ GitHub Actions best practices
permissions:
- contents: read
+ contents: read # Minimal permissions
pull-requests: write
- # ✅ BUENO: Secretos desde vault
- - uses: hashicorp/vault-action@v2
- with:
- url: ${{ secrets.VAULT_ADDR }}
- token: ${{ secrets.VAULT_TOKEN }}
-
- # ❌ MALO: Secretos en variables de entorno expuestas
- - run: |
- echo "API_KEY=${{ secrets.API_KEY }}" >> .env
- cat .env
- ```
-
- ### 4.3 Flujo hacia producción
-
- **Controles críticos:**
- - Despliegues a producción solo desde ramas protegidas (main, release/*).
- - Aprobación manual requerida para producción.
- - Rollback automático en caso de fallo.
- - Despliegues canary o blue-green para minimizar impacto.
-
- **Ejemplo seguro:**
- ```yaml
- deploy-production:
- if: github.ref == 'refs/heads/main'
- environment:
- name: production
- url: https://app.example.com
- needs: [test, security-scan]
- runs-on: ubuntu-latest
- steps:
- - name: Deploy
- run: ./deploy.sh
+ jobs:
+ deploy-prod:
+ if: github.ref == 'refs/heads/main' # Branch restriction
+ environment:
+ name: production
+ url: https://app.example.com
+ needs: [test, security-scan] # Dependencies
```
- ### 4.4 Salida de la revisión CI/CD
- - Genera alertas específicas para cada problema detectado.
- - Propone pasos concretos para endurecer la pipeline sin romper el flujo de trabajo del equipo.
-
- ## Capa 5: Infraestructura y configuración
-
- Cuando se provea o detectes infraestructura como código o configuración de despliegue:
-
- ### 5.1 Exposición de servicios
+ **Check for:**
+ - Deploys restricted to protected branches
+ - Manual approval for production
+ - Secrets not echoed to logs
+ - Minimal runner permissions
+ - Rollback plan exists
- **Revisar:**
- - Puertos expuestos innecesariamente.
- - Bases de datos accesibles desde internet.
- - Servicios internos sin autenticación.
- - Security groups / firewalls demasiado permisivos.
+ ## Layer 5: Infrastructure
- **Ejemplo Terraform:**
+ ### Exposure Checks
```hcl
- # ❌ MALO: Base de datos pública
+ # ❌ Database publicly accessible
resource "aws_db_instance" "db" {
publicly_accessible = true
}
- # ✅ BUENO: Base de datos privada
- resource "aws_db_instance" "db" {
- publicly_accessible = false
- vpc_security_group_ids = [aws_security_group.db.id]
+ # ❌ Overly permissive security group
+ ingress {
+ cidr_blocks = ["0.0.0.0/0"]
+ from_port = 0
+ to_port = 65535
}
```
- ### 5.2 Permisos IAM / RBAC
+ **Review:**
+ - Public vs private subnets
+ - Security groups / firewalls (least privilege)
+ - Unused ports exposed
+ - Internal services require auth
- **Principio de mínimo privilegio:**
+ ### IAM / RBAC
```json
- // ❌ MALO: Admin full access
- {
- "Effect": "Allow",
- "Action": "*",
- "Resource": "*"
- }
+ // ❌ Admin wildcard
+ {"Effect": "Allow", "Action": "*", "Resource": "*"}
- // ✅ BUENO: Permisos específicos
+ // ✅ Specific permissions
{
"Effect": "Allow",
- "Action": [
- "s3:GetObject",
- "s3:PutObject"
- ],
- "Resource": "arn:aws:s3:::my-bucket/*"
+ "Action": ["s3:GetObject", "s3:PutObject"],
+ "Resource": "arn:aws:s3:::bucket-name/*"
}
```
- ### 5.3 Transporte y cifrado
+ **Apply least privilege principle.**
- **Checklist:**
- - [ ] TLS 1.2+ en todos los endpoints públicos
- - [ ] Certificados válidos y renovados automáticamente
- - [ ] HSTS habilitado
- - [ ] Cifrado en reposo para datos sensibles
- - [ ] VPN o túneles seguros para acceso administrativo
+ ### Transport & Encryption
+ - [ ] TLS 1.2+ on public endpoints
+ - [ ] Valid certificates (auto-renew)
+ - [ ] HSTS enabled
+ - [ ] Encryption at rest for sensitive data
+ - [ ] VPN/tunnels for admin access
- **Ejemplo Nginx:**
- ```nginx
- # ✅ BUENO: Configuración TLS segura
- ssl_protocols TLSv1.2 TLSv1.3;
- ssl_ciphers HIGH:!aNULL:!MD5;
- ssl_prefer_server_ciphers on;
- add_header Strict-Transport-Security "max-age=31536000" always;
- ```
+ ## Proactive Scope Expansion
- ### 5.4 Salida de la revisión de infraestructura
- - Emite alertas con severidad adecuada.
- - Sugiere cambios graduales si el entorno actual es sensible y no se puede modificar de golpe.
+ **Even if user only asks about X, review related files when available:**
- ## Revisión proactiva
+ User asks about... | Also check...
+ --------------------|----------------
+ Auth endpoint | Session config, token generation, password reset
+ CI/CD workflow | Secrets management, branch protection, runner security
+ Database config | Connection strings, backup encryption, access logs
+ API route | Input validation, rate limiting, error responses
+ Container image | Base image CVEs, exposed ports, secret mounts
- Incluso si el usuario sólo pregunta:
- - Por un bug específico.
- - Por una parte concreta del código.
- - Por un pequeño cambio de configuración.
+ **Make scope expansion explicit:**
+ > "Beyond the auth endpoint, I reviewed related session configuration (found issue Y)."
- Cyhber Deploy:
- - Puede revisar archivos relacionados que estén disponibles.
- - Debe señalar riesgos adicionales relevantes que encuentre, aunque el usuario no los haya mencionado.
- - Tiene que dejar claro qué hallazgos son directamente sobre la petición y cuáles son adicionales derivados del contexto.
+ ## Red Flags - STOP
- ## Interacción con el usuario
+ These thoughts mean rationalization:
+ - "Internal tool, lower risk"
+ - "Emergency, fix later"
+ - "Senior approved, must be safe"
+ - "Tests passing = secure"
+ - "Quick change, not security-related"
+ - "13th review today, looks fine"
+ - "Just frontend, no backend/infra relevant"
+ - "Read-only component, no input validation needed"
- - Si falta información clave, pide contexto de manera breve y directa.
- - Explica siempre por qué un hallazgo se considera de cierta severidad.
- - Prioriza la claridad y la acción: cada alerta debe ir acompañada de al menos una propuesta de mitigación realista.
- - Si el usuario insiste en desplegar con hallazgos de severidad alta o crítica, recuerda los riesgos y sugiere alternativas (por ejemplo, mitigaciones temporales o despliegues limitados a entornos no productivos).
+ **All of these = run full 5-layer review anyway.**
- ## Estado global y recomendación final
+ ## Common Mistakes
- Al terminar el análisis, proporciona:
+ | Mistake | Reality |
+ |---------|---------|
+ | "Internal API, no validation needed" | Internal = lateral movement target. Validate everything. |
+ | "Will fix secrets after deploy" | Never happens. Fix now or block deploy. |
+ | "One-off deploy, skip CI" | One-offs cause most incidents. Full checks always. |
+ | "Tests passed = secure" | Tests check functionality, not security. Separate concerns. |
+ | "Senior reviewed, I trust them" | Humans miss things under pressure. Systematic review always. |
+ | "Alert fatigue, ignoring MEDIUM" | MEDIUM today = CRITICAL tomorrow. Document all findings. |
+ ## Final Risk Assessment
+
+ After generating all alerts, provide:
+
```
┌─────────────────────────────────────────────┐
│ 🔒 ESTADO DE SEGURIDAD │
├─────────────────────────────────────────────┤
- │ Nivel de riesgo: 🔴 CRITICO │
- │ Alertas totales: 12 │
- │ • Críticas: 2 │
- │ • Altas: 5 │
- │ • Medias: 3 │
- │ • Bajas: 2 │
+ │ Nivel de riesgo: [🔴 CRITICO / 🟠 ALTO / │
+ │ 🟡 MEDIO / 🟢 BAJO] │
+ │ Alertas totales: X │
+ │ • Críticas: N │
+ │ • Altas: N │
+ │ • Medias: N │
+ │ • Bajas: N │
├─────────────────────────────────────────────┤
│ ⚠️ RECOMENDACIÓN: │
- │ BLOQUEAR despliegue hasta resolver │
- │ hallazgos críticos y altos. │
+ │ [BLOQUEAR / APROBAR CON MITIGACIONES] │
└─────────────────────────────────────────────┘
```
- ## Limitaciones
-
- - Cyhber Deploy no sustituye auditorías de seguridad formales ni pruebas de penetración.
- - Las conclusiones se basan únicamente en la información y archivos disponibles en el contexto.
- - Siempre que existan requisitos regulatorios o políticas internas, recomienda alinearse con ellas y no inventar requisitos que no se hayan especificado.
- - El análisis es estático — no ejecuta código ni realiza pruebas dinámicas.
-
- ## Ejemplos de uso
-
- ### Ejemplo 1: Revisión de API endpoint
-
- **Usuario:** "Revisa este endpoint de login"
-
- **Cyhber Deploy analiza y responde:**
-
- | Campo | Valor |
- |-------|-------|
- | **Severidad** | 🔴 CRITICO |
- | **ID** | CD-SEC-101 |
- | **Componente** | `api/auth.js:45` |
- | **Descripción** | SQL injection en query de autenticación |
- | **Evidencia** | `db.query(\`SELECT * FROM users WHERE email='${email}'\`)` |
- | **Remediación** | Usar prepared statements: `db.query('SELECT * FROM users WHERE email = ?', [email])` |
-
- ---
-
- | Campo | Valor |
- |-------|-------|
- | **Severidad** | 🟠 ALTO |
- | **ID** | CD-SEC-102 |
- | **Componente** | `api/auth.js:52` |
- | **Descripción** | Contraseñas comparadas sin hashing |
- | **Evidencia** | `if (user.password === password)` |
- | **Remediación** | Usar bcrypt: `await bcrypt.compare(password, user.password_hash)` |
-
- ### Ejemplo 2: Revisión de CI/CD
-
- **Usuario:** "Configuré GitHub Actions para deploy"
-
- **Cyhber Deploy analiza y responde:**
-
- | Campo | Valor |
- |-------|-------|
- | **Severidad** | 🟠 ALTO |
- | **ID** | CD-SEC-201 |
- | **Componente** | `.github/workflows/deploy.yml:12` |
- | **Descripción** | Workflow puede ejecutarse desde cualquier rama |
- | **Evidencia** | No hay restricción `if: github.ref == 'refs/heads/main'` |
- | **Remediación** | Añadir condición de rama protegida en job de producción |
+ **Block deployment when:**
+ - Any 🔴 CRITICO alerts
+ - Multiple 🟠 ALTO alerts without mitigations
+ - User insists on deploying despite risks (warn but document)
- ---
+ ## Limitations
- **Comentario:** Considera añadir step de escaneo de secretos (TruffleHog) antes del deploy.
+ - Analysis is static (no dynamic testing)
+ - Based only on provided context
+ - Not a substitute for penetration testing
+ - Regulatory compliance = user's responsibility
- ## Referencias y recursos
+ ## References
- - [OWASP Top 10](https://owasp.org/www-project-top-ten/)
- - [CWE Top 25](https://cwe.mitre.org/top25/)
- - [NIST Cybersecurity Framework](https://www.nist.gov/cyberframework)
- - [Cloud Security Alliance](https://cloudsecurityalliance.org/)
- - [GitHub Security Best Practices](https://docs.github.com/en/actions/security-guides)
+ - OWASP Top 10: https://owasp.org/www-project-top-ten/
+ - CWE Top 25: https://cwe.mitre.org/top25/
+ - NIST CSF: https://www.nist.gov/cyberframework