cyhber-deploy git:20260511.4c24f87B

Immutable. This exact content never changes and is served at /api/v1/blob/31df9522737b1cba.

---
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.
---

# 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.

## Cuándo usar Cyhber Deploy

Cyhber Deploy debe activarse o considerarse relevante cuando el usuario:

- 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.

## Flujo de trabajo general

Siempre que el usuario solicite ayuda relacionada con código, despliegues o infra:

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).

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).

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).

4. **Alertas y recomendaciones**
   - Genera alertas estructuradas con severidad y acciones específicas.
   - Propone un orden de corrección por prioridad de riesgo.

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.

## Formato de alertas

Cuando detectes un problema de seguridad o una mala práctica relevante, genera una alerta con este formato:

| 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.

## Capa 1: Código y validación de entradas

Al revisar código relacionado con nuevas features, bugfixes o refactors:

### 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.

**Patrones a detectar:**
```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).

**Patrones críticos:**
```python
# ❌ CRITICO: Command injection
os.system(f"ping {user_input}")

# ❌ CRITICO: SQL injection
cursor.execute(f"SELECT * FROM users WHERE name = '{username}'")

# ✅ BUENO: Parametrización
cursor.execute("SELECT * FROM users WHERE name = ?", (username,))
```

### 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-----

# Generic API Keys
api[_-]?key[s]?\s*[:=]\s*['"][a-zA-Z0-9]{20,}['"]
```

**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.

### 3.2 Manejo seguro

**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.

### 3.3 Datos personales (PII)

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.

**Sugiere:**
- Minimizar recopilación y almacenamiento.
- Encriptar en reposo y en tránsito.
- Implementar políticas de retención.

## Capa 4: CI/CD y proceso de despliegue

Al revisar pipelines y scripts de despliegue:

### 4.1 Pruebas y controles previos

**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

### 4.2 Permisos y secretos en la pipeline

**GitHub Actions - Buenas prácticas:**
```yaml
# ✅ BUENO: Permisos mínimos
permissions:
  contents: read
  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
```

### 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

**Revisar:**
- Puertos expuestos innecesariamente.
- Bases de datos accesibles desde internet.
- Servicios internos sin autenticación.
- Security groups / firewalls demasiado permisivos.

**Ejemplo Terraform:**
```hcl
# ❌ MALO: Base de datos pública
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]
}
```

### 5.2 Permisos IAM / RBAC

**Principio de mínimo privilegio:**
```json
// ❌ MALO: Admin full access
{
  "Effect": "Allow",
  "Action": "*",
  "Resource": "*"
}

// ✅ BUENO: Permisos específicos
{
  "Effect": "Allow",
  "Action": [
    "s3:GetObject",
    "s3:PutObject"
  ],
  "Resource": "arn:aws:s3:::my-bucket/*"
}
```

### 5.3 Transporte y cifrado

**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

**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;
```

### 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.

## Revisión proactiva

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.

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.

## Interacción con el usuario

- 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).

## Estado global y recomendación final

Al terminar el análisis, proporciona:

```
┌─────────────────────────────────────────────┐
│ 🔒 ESTADO DE SEGURIDAD                      │
├─────────────────────────────────────────────┤
│ Nivel de riesgo:  🔴 CRITICO               │
│ Alertas totales:  12                        │
│   • Críticas:     2                         │
│   • Altas:        5                         │
│   • Medias:       3                         │
│   • Bajas:        2                         │
├─────────────────────────────────────────────┤
│ ⚠️  RECOMENDACIÓN:                          │
│ BLOQUEAR despliegue hasta resolver          │
│ hallazgos críticos y altos.                 │
└─────────────────────────────────────────────┘
```

## 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 |

---

**Comentario:** Considera añadir step de escaneo de secretos (TruffleHog) antes del deploy.

## Referencias y recursos

- [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)