QA & TestingBásico

Shift Left Security

Práctica de integrar pruebas y controles de seguridad más temprano en el ciclo de desarrollo de software, en lugar de dejarlas para el final.

Pronunciación

/ʃɪft lɛft sɪˈkjʊərɪti/
"shift left si-kiú-ri-ti"
Escuchar en:Forvo

Qué es

Shift Left Security (Seguridad a la Izquierda) significa mover las pruebas y controles de seguridad más temprano en el ciclo de desarrollo de software (SDLC).

El nombre viene de visualizar el SDLC como una línea temporal de izquierda a derecha: “shift left” = mover a la izquierda = más temprano.

Errores comunes de pronunciación

  • ❌ “shif lef” (las ‘t’ finales de shift y left se pronuncian)

El problema tradicional

┌─────────────────────────────────────────────────────────┐
│          MODELO TRADICIONAL (Seguridad al final)        │
├─────────────────────────────────────────────────────────┤
│                                                          │
│   Requisitos → Diseño → Código → Test → QA → SEGURIDAD │
│                                                    ↑     │
│                                                    │     │
│   "Encontramos 47 vulnerabilidades críticas.       │     │
│    El lanzamiento se retrasa 3 meses."      ───────┘     │
│                                                          │
│   Costo de arreglar un defecto:                         │
│   crece cuanto más tarde se detecta                     │
│   (diseño < código < producción)                        │
│                                                          │
└─────────────────────────────────────────────────────────┘

La solución: Shift Left

┌─────────────────────────────────────────────────────────┐
│          MODELO SHIFT LEFT (Seguridad continua)         │
├─────────────────────────────────────────────────────────┤
│                                                          │
│   Requisitos → Diseño → Código → Test → QA → Deploy    │
│       ↑          ↑         ↑        ↑      ↑            │
│       │          │         │        │      │            │
│   Threat     Security   SAST    DAST   Pentest         │
│   Modeling   Review     SCA     IAST                    │
│                                                          │
│   Seguridad integrada en CADA fase                      │
│                                                          │
└─────────────────────────────────────────────────────────┘

Herramientas por fase

Fase Herramienta Qué hace
Requisitos Threat Modeling Identifica amenazas temprano
Diseño Security Review Revisa arquitectura
Código SAST (Snyk, SonarQube) Analiza código estático
Código SCA (Dependabot) Revisa dependencias
Build Container Scanning Revisa imágenes Docker
Test DAST (OWASP ZAP) Pruebas dinámicas contra la app en ejecución
Test IAST Análisis instrumentado en runtime durante las pruebas
Pre-release Pentest Pruebas manuales de penetración

Ejemplo práctico: Pipeline con Shift Left

Tip de seguridad: nunca uses ramas como @master; fija las acciones de terceros a una versión y, en producción, a un SHA de commit completo. Los tags también pueden moverse: en marzo de 2026, un atacante reescribió 76 de los 77 tags de versión de aquasecurity/trivy-action para que apuntaran a malware que robaba credenciales (aviso de seguridad de Trivy). Los ejemplos de abajo usan tags por legibilidad.

# .github/workflows/secure-pipeline.yml
name: Secure CI/CD

on: [push, pull_request]

jobs:
  # 1. SAST - Análisis estático (muy temprano)
  sast:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6

      - name: Run SAST
        uses: snyk/actions/node@v1.0.0
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
        with:
          command: code test   # Snyk Code = SAST
          args: --severity-threshold=high

  # 2. SCA - Análisis de dependencias
  dependency-check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6

      - name: Check for vulnerabilities
        run: npm audit --audit-level=high

      - name: Snyk dependency scan
        uses: snyk/actions/node@v1.0.0
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
        with:
          command: test        # Snyk Open Source = SCA

  # 3. Secrets scanning
  secrets:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6

      - name: Scan for secrets
        uses: trufflesecurity/trufflehog@v3.97.4
        with:
          path: ./

  # 4. Container scanning
  container-scan:
    runs-on: ubuntu-latest
    needs: [sast, dependency-check]
    steps:
      - uses: actions/checkout@v6

      - name: Build image
        run: docker build -t myapp:${{ github.sha }} .

      - name: Scan container
        uses: aquasecurity/trivy-action@v0.36.0
        with:
          image-ref: myapp:${{ github.sha }}
          severity: HIGH,CRITICAL

  # 5. DAST - Solo si todo lo anterior pasó
  dast:
    runs-on: ubuntu-latest
    needs: [container-scan]
    steps:
      - name: OWASP ZAP Scan
        uses: zaproxy/action-full-scan@v0.13.0
        with:
          target: 'https://staging.myapp.com'

Beneficios de Shift Left

Métrica Sin Shift Left Con Shift Left
Costo por defecto Alto (se detecta en producción) Menor (se detecta en desarrollo)
Tiempo de fix Días/Semanas Horas
Vulnerabilidades en prod Muchas Pocas
Tiempo de release Impredecible Predecible
Confianza del equipo Baja Alta

Caso práctico: Antes vs Después

Antes (Seguridad al final)

Lunes: Desarrollador termina feature
Martes-Jueves: QA prueba funcionalidad
Viernes: Equipo de seguridad revisa
         → Encuentra SQL Injection
Siguiente semana: Desarrollador arregla
         → Otro ciclo de QA
         → Release retrasado 2 semanas

Después (Shift Left)

Lunes: Desarrollador escribe código
       → IDE muestra warning de SAST: posible SQL Injection
       → Desarrollador arregla en el momento (5 min)
       → Push al repo
       → Pipeline ejecuta SAST, SCA, container scan
       → Todo verde ✅
Martes: QA prueba, seguridad ya validada
Miércoles: Release on time

Implementación gradual

Fase 1: Quick wins (Semana 1-2)

# Agregar a tu pipeline existente
- name: Dependency audit
  run: npm audit --audit-level=high

- name: Secret scan
  uses: trufflesecurity/trufflehog@v3.97.4

Fase 2: SAST (Semana 3-4)

- name: SAST scan
  uses: snyk/actions/node@v1.0.0
  # Solo fallar en críticos al inicio
  with:
    args: --severity-threshold=critical

Fase 3: Container Security (Mes 2)

- name: Container scan
  uses: aquasecurity/trivy-action@v0.36.0

Fase 4: DAST (Mes 3)

- name: DAST scan
  uses: zaproxy/action-full-scan@v0.13.0

Herramientas populares

Categoría Open Source Comercial
SAST Semgrep, Bandit Snyk, SonarQube (tiene edición gratuita)
SCA OWASP Dependency-Check Snyk, Mend (antes WhiteSource)
Secrets TruffleHog, git-secrets GitGuardian
Container Trivy, Clair Aqua, Prisma Cloud
DAST OWASP ZAP Burp Suite, Acunetix

Métricas para medir éxito

Las metas son ejemplos orientativos; ajústalas a tu contexto y nivel de riesgo.

Métrica Qué mide Meta de ejemplo
MTTR Tiempo medio de remediación < 24 horas
Vulnerabilidades escapadas Bugs que llegan a prod 0 críticos
Cobertura de scan % de código/deps escaneado > 90%
Tiempo de pipeline Duración de CI/CD < 15 min

Términos relacionados

  • CI/CD - Pipeline donde se integra seguridad
  • DevSecOps - Cultura de seguridad en DevOps
  • SAST - Static Application Security Testing
  • DAST - Dynamic Application Security Testing

Recuerda: Shift Left no significa eliminar las pruebas de seguridad al final—significa agregar seguridad en cada fase. Entre más temprano detectes un problema, más barato y fácil es arreglarlo.

Artículos relacionados

Todos los términos