DevSecOps: integración de la seguridad en DevOps

Introducción

DevSecOps es la práctica de integrar la seguridad en cada fase del ciclo de vida del desarrollo de software, desde la planificación y la codificación hasta las pruebas, la implementación y las operaciones. En lugar de tratar la seguridad como una puerta final (o peor aún, una idea de último momento), DevSecOps hace de la seguridad una responsabilidad continua y compartida entre los equipos de desarrollo, operaciones y seguridad.

La filosofía central es "desplazarse hacia la izquierda": abordar los problemas de seguridad lo antes posible en el proceso de desarrollo, cuando son más baratos y fáciles de solucionar. Remediar una vulnerabilidad encontrada en producción cuesta 100 veces más que una detectada durante el diseño.

---

La filosofía del cambio a la izquierda

Costo de reparar vulnerabilidades

Stage         Cost to Fix          Detection
──────────────────────────────────────────────
Design        $1                   Threat modeling, architecture review
Development   $6                   SAST, peer review
Testing       $15                  DAST, penetration testing
Staging       $40                  Integration tests
Production    $100+                Incident response, breach

Fuente: Instituto de Ciencias de Sistemas de IBM

Seguridad como código

Así como DevOps trajo "infraestructura como código", DevSecOps trae "seguridad como código":

# .sast.yml — Security policies defined in code
version: 1.0
policies:
  sql_injection:
    severity: critical
    action: block_build
  hardcoded_secret:
    severity: high
    action: alert_and_review
  deprecated_api:
    severity: medium
    action: warn

---

El canal DevSecOps

Plan → Code → Build → Test → Deploy → Operate
 │      │       │       │       │        │
 ├─ Threat Model
 │      ├─ SAST
 │              ├─ Dependency Scan
 │              ├─ Container Scan
 │                      ├─ DAST
 │                      ├─ IaC Scan
 │                              ├─ Sign
 │                              ├─ Policy Check
 │                                      ├─ Monitoring
 │                                      ├─ SIEM
 │                                      ├─ Incident Response

1. Fase de planificación: modelado de amenazas

Antes de escribir código, identifique amenazas potenciales utilizando marcos como STRIDE:

Categoría	Ejemplo	Mitigación
Mierda	El atacante se hace pasar por un usuario	Autenticación (MFA, JWT)
Tamperación	El atacante modifica los datos en tránsito	TLS, firma
**Repudio	El usuario niega una acción	Registro de auditoría
** Divulgación de información	Fuga de datos a través de mensajes de error	Manejo adecuado de errores
Ddenegación de servicio	Abrumar a la API con solicitudes	Limitación de velocidad
Elevación de Privilegio	El usuario habitual obtiene acceso de administrador	RBAC, controles de autorización

Herramienta: OWASP Threat Dragon: herramienta de modelado de amenazas de código abierto compatible con STRIDE.

2. Fase de código: prueba de seguridad de aplicaciones estáticas (SAST)

SAST analiza el código fuente en busca de vulnerabilidades sin ejecutarlo.

// SAST will flag this as SQL injection
app.get('/user', (req, res) => {
  const sql = `SELECT * FROM users WHERE id = '${req.query.id}'`;
  db.query(sql);
});

// Corrected version
app.get('/user', (req, res) => {
  const sql = 'SELECT * FROM users WHERE id = ?';
  db.query(sql, [req.query.id]);
});

Herramientas SAST:

Herramienta	Idiomas	Integración
SónarQube	Más de 30 idiomas	GitHub/GitLab CI, Jenkins
Semgrep	Python, Go, JS, TS, Java, etc.	CLI, CI, compromiso previo
CódigoQL	C/C++, C#, Java, JS/TS, Pitón	Seguridad avanzada de GitHub
Marque de verificación	Más de 20 idiomas	SDLC empresarial

Integración de CI:

# GitHub Actions — SAST on every PR
name: SAST
on: [pull_request]
jobs:
  sast:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run Semgrep
        uses: semgrep/semgrep-action@v1
        with:
          config: p/default
      - name: Check results
        run: |
          if [ -f semgrep-results.json ]; then
            CRITICAL=$(jq '.results | map(select(.severity=="CRITICAL")) | length' semgrep-results.json)
            if [ "$CRITICAL" -gt 0 ]; then
              echo "❌ $CRITICAL critical vulnerabilities found"
              exit 1
            fi
          fi

3. Fase de construcción: análisis de dependencias y contenedores

Escaneo de dependencias

Las bibliotecas de código abierto representan entre el 60% y el 80% de las aplicaciones modernas. Cada dependencia es un vector de ataque potencial.

Ataques notables a la cadena de suministro:

• Event-stream (2018): un paquete malicioso robó Bitcoin de las billeteras.
• SolarWinds (2020): el proceso de compilación con puerta trasera afectó a más de 18 000 organizaciones.
• Log4j (2021): RCE crítico en una biblioteca de registro ampliamente utilizada.
• xz utils (2024): puerta trasera SSH en la biblioteca de compresión de Linux.

# Dependency scanning with Trivy
$ trivy fs --scanners vuln --severity CRITICAL,HIGH .
Total: 14 (CRITICAL: 3, HIGH: 11)

┌──────────────────────┬──────────────────┬──────────┬───────────────────┐
│ Package              │ Vulnerability ID  │ Severity │ Installed Version │
├──────────────────────┼──────────────────┼──────────┼───────────────────┤
│ lodash               │ CVE-2024-1234     │ CRITICAL │ 4.17.20           │
│ express              │ CVE-2024-5678     │ HIGH     │ 4.18.1            │
└──────────────────────┴──────────────────┴──────────┴───────────────────┘

Bloquear versiones de dependencia y utilizar hashes de integridad:

// package-lock.json ensures reproducible builds with hashes
"lodash": {
  "version": "4.17.21",
  "integrity": "sha512-v2kDEe57lecTulaDIuNTPy3Ry4gLGJ6Z1O3vE1krgXZNrsQ+LFTGHVxVjcXPs17LhbZVGedAJv8XZ1tvj5FvSg=="
}

Escaneo de imágenes de contenedores

# Bad practice: large base image, runs as root
FROM node:20
COPY . .
RUN npm install
USER root
CMD ["node", "app.js"]

# Good practice: minimal base image, non-root user
FROM node:20-alpine
RUN addgroup -S appgroup && adduser -S appuser -G appgroup
COPY --chown=appuser:appgroup . .
RUN npm ci --production
USER appuser
CMD ["node", "app.js"]

# Scan container image
$ trivy image myapp:latest
┌──────────────────┬──────────────────┬──────────┐
│ Library          │ Vulnerability    │ Severity │
├──────────────────┼──────────────────┼──────────┤
│ libcrypto        │ CVE-2024-9999    │ CRITICAL │
│ bash             │ CVE-2024-8888    │ HIGH     │
└──────────────────┴──────────────────┴──────────┘

Recommendation: Use distroless or scratch base images

4. Fase de prueba: Prueba dinámica de seguridad de aplicaciones (DAST)

DAST prueba la aplicación en ejecución en busca de vulnerabilidades:

# OWASP ZAP automated scan
docker run -v $(pwd):/zap/wrk:rw zaproxy/zap-stable \
  zap-cli quick-scan \
  --self-contained \
  --start-options '-config api.addrs.addr.name=.*' \
  http://staging.example.com

# Generate HTML report
zap-cli report -o zap-report.html -f html

Cobertura DAST (OWASP Top 10):

• A01: Control de acceso roto
• A02: Fallas criptográficas
• A03: Inyección (SQL, NoSQL, comando OS)
• A04: Diseño inseguro
• A05: Configuración incorrecta de seguridad
• A06: Componentes vulnerables
• A07: Fallos de autenticación
• A08: Fallas de integridad de datos
• A09: Fallas de registro/monitoreo
• A10: SSRF

5. Fase de implementación: aplicación de políticas

Firma y Verificación

# Cosign — sign container images
cosign sign --key cosign.key registry.example.com/myapp:latest

# Verify before deployment
cosign verify --key cosign.pub registry.example.com/myapp:latest

Controladores de admisión (Kubernetes)

# OPA/Gatekeeper — Deny privileged containers
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sBlockPrivilegedContainers
metadata:
  name: no-privileged-containers
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pod"]
  parameters:
    enforcementAction: deny
  validation:
    message: "Privileged containers are not allowed"
    deny:
      conditions:
        - key: "spec.containers[].securityContext.privileged"
          operator: In
          values: ["true"]

6. Fase de operación: monitoreo continuo

Gestión de eventos e información de seguridad (SIEM)

# Filebeat configuration for shipping logs to ELK
filebeat.inputs:
  - type: container
    paths:
      - /var/log/containers/*.log
output.elasticsearch:
  hosts: ["https://elasticsearch:9200"]
  username: "filebeat"
  password: "${ELASTIC_PASSWORD}"

Reglas de detección SIEM:

# Elastic Security rule: Multiple failed logins
sequence by source.ip
  with maxspan=5m
  [authentication where event.action == "login_failed"] |
  [authentication where event.action == "login_failed"] |
  [authentication where event.action == "login_success"]

Protección en tiempo de ejecución

• Falco: monitoreo de seguridad en tiempo de ejecución para contenedores y Kubernetes.
• AppArmor / SELinux: control de acceso obligatorio en Linux.
• Seccomp: restringe las llamadas al sistema disponibles para los contenedores.

# Falco rule: Shell in container
- rule: Terminal shell in container
  desc: A shell was spawned in a container
  condition: container.id != host
    and proc.name in (bash, zsh, sh, ash)
    and spawned_process
  output: "Shell spawned in container (user=%user.name container=%container.id)"
  priority: WARNING

---

Cultura DevSecOps

DevSecOps tiene que ver tanto con la cultura y los procesos como con las herramientas:

Principios culturales

Principio	Tradicional	DevSecOps
Propiedad de la seguridad	El equipo de seguridad es el propietario.	Todo el mundo lo posee
Cuando ocurre la seguridad	Fin del desarrollo	Continuo en todo momento
Cómo se entrega la retroalimentación	"No" (bloqueador)	"Sí, si..." (habilitador)
Estructura del equipo	Silos separados	multifuncional
Automatización	Puertas de seguridad manuales	Controles de seguridad automatizados
Velocidad versus seguridad	Compensación (lento y seguro versus rápido e inseguro)	Ambos: la seguridad automatizada permite la velocidad

Creación de un programa DevSecOps

1. Empiece poco a poco: agregue SAST y escaneo de dependencias a una canalización.
2. Mostrar valor: realice un seguimiento de las vulnerabilidades detectadas antes de la producción.
3. Automatizar, no bloquear: las puertas de seguridad deben proporcionar retroalimentación, no bloqueadores.
4. Capacite a los desarrolladores: campeones de seguridad en cada equipo.
5. Medida: tiempo medio de reparación (MTTR), densidad de vulnerabilidad.

Programa de campeones de seguridad

Designe defensores de la seguridad dentro de los equipos de desarrollo:

• Actuar como enlaces entre seguridad y desarrollo.
• Revise los hallazgos de la herramienta de seguridad.
• Realizar revisiones de seguridad entre pares.
• Manténgase actualizado sobre las mejores prácticas de seguridad.

---

Resumen de la cadena de herramientas DevSecOps

Fase	Opciones de herramientas	Objetivo
Modelado de amenazas	OWASP Threat Dragon, herramienta de modelado de amenazas de Microsoft	Identificar amenazas tempranamente
SAST	SonarQube, Semgrep, CodeQL, Checkmarx	Análisis de código estático
Dependencia	Snyk, Dependabot, Trivy, OWASP DC	Gestión de vulnerabilidades de código abierto
Recipiente	Trivy, Clair, Docker Scout, Grype	Escaneo de vulnerabilidad de imagen
DAST	OWASP ZAP, Burp Suite, Acunetix	Pruebas de vulnerabilidad en tiempo de ejecución
IaC	Checkov, tfsec, Terrascan, KICS	Detección de mala configuración de infraestructura
Misterios	GitGuardian, TruffleHog, Gitleaks	Detectar secretos en el código
Firma	Firma, Firma, Notario	Firma y verificación de artefactos.
Política	OPA/Guardián, Kyverno, Sentinel	Aplicación de políticas
Tiempo de ejecución	Falco, AppArmor, Seccomp	Detección de amenazas en tiempo de ejecución
SIEM	ELK, Splunk, Seguridad Datadog, Sentinel	Agregación de registros y detección de amenazas

---

Conclusión

DevSecOps transforma la seguridad de un cuello de botella a un facilitador. Al integrar controles de seguridad en cada fase del ciclo de vida de desarrollo y automatizarlos en los canales de CI/CD, las organizaciones pueden:

1. Detecte las vulnerabilidades antes: cuando su reparación sea 100 veces más barata.
2. Envíe más rápido: las puertas de seguridad automatizadas son más rápidas que la revisión manual.
3. Reduzca el riesgo: la supervisión continua de la seguridad detecta lo que los humanos pasan por alto.
4. Crear una cultura de seguridad: la seguridad se convierte en responsabilidad de todos.

Comience con las herramientas de mayor impacto y menor fricción: SAST y escaneo de dependencias. Agregue escaneo de contenedores, DAST e IaC de manera incremental. Mida el progreso, celebre los logros y repita.