La ilusión de la seguridad: por qué el escaneo reactivo de CVE está muerto

Durante la última década, la seguridad de CI/CD fue sinónimo de ejecutar un rápido `npm audit`, utilizar Dependabot o colocar un escáner de contenedores al final de una canalización de compilación. Si el escaneo resultaba verde (o, seamos honestos, en su mayoría amarillo), el artefacto se implementaba.

El incidente de XZ Utils demostró que este modelo reactivo está fundamentalmente roto para las amenazas modernas. Los escáneres de vulnerabilidades buscan vulnerabilidades conocidas (CVE) que ya han sido identificadas, analizadas y publicadas. Los ataques a la cadena de suministro —tales como solicitudes de extracción maliciosas, cuentas de mantenedores comprometidas, confusión de dependencias y typo-squatting— introducen código malicioso de día cero que los escáneres simplemente pasan por alto porque el código *funciona* exactamente como el atacante pretendía. No es una vulnerabilidad; es una característica diseñada por un actor malicioso.

Entra SLSA: Seguridad proactiva de la cadena de suministro

Para detener el envenenamiento de canalizaciones y los ataques a la cadena de suministro, las organizaciones de ingeniería están cambiando al marco de trabajo SLSA (Niveles de cadena de suministro para artefactos de software, por sus siglas en inglés). Creado por Google, SLSA es un conjunto de pautas de seguridad adoptables de forma incremental diseñadas para evitar la manipulación, mejorar la integridad y proteger los paquetes y la infraestructura en sus proyectos.

En lugar de simplemente escanear el resultado final, SLSA protege el proceso de construcción del software.

• SLSA Nivel 1: Tiene un proceso de compilación y genera procedencia (metadatos sobre cómo se construyó un artefacto).

• SLSA Nivel 2: El servicio de compilación requiere autenticación y la procedencia está autenticada.

• SLSA Nivel 3: Las plataformas de origen y compilación cumplen con estándares específicos para garantizar la auditabilidad e integridad de la procedencia.

• SLSA Nivel 4: Revisión por parte de dos personas de todos los cambios y un proceso de compilación completamente hermético y reproducible.

Para la mayoría de las startups de alto crecimiento, alcanzar el Nivel SLSA 2 o 3 es el punto ideal. Proporciona una reducción masiva del riesgo sin requerir la extenuante revisión necesaria para las compilaciones herméticas (Nivel 4). Pero, ¿cómo se implementa esto sin obligar a los desarrolladores a pasar por todo tipo de obstáculos?

Automatizar el trabajo pesado: SBOM transparentes y firma de contenedores

La regla de oro de DevSecOps es simple: Si la seguridad requiere que los desarrolladores recuerden comandos o pasos adicionales, fallará. 

Para lograr el cumplimiento de SLSA, necesita dos componentes críticos generados en cada compilación:

1. SBOM (Lista de materiales de software): Un inventario exhaustivo de todos los componentes de software, dependencias y metadatos en su aplicación.

2. Firmas criptográficas: Prueba de que el contenedor o artefacto fue construido por su sistema de CI/CD de confianza y no ha sido manipulado desde entonces.

Puede automatizar esto por completo dentro de sus canalizaciones de CI/CD (por ejemplo, GitHub Actions o GitLab CI) utilizando herramientas como Syft (para la generación de SBOM) y Cosign de Sigstore (para la firma sin llave).

La implementación técnica: firma sin llave en GitHub Actions

Históricamente, administrar claves privadas para la firma de código era una pesadilla. Las claves se almacenaban en variables de CI, se rotaban rara vez e inevitablemente se filtraban. Sigstore revolucionó esto al introducir la firma sin llave mediante OIDC (OpenID Connect). El ejecutor de CI demuestra su identidad ante una autoridad de certificación superior (Fulcio), firma el artefacto y registra la firma en un libro de contabilidad inmutable (Rekor).

Aquí tiene un ejemplo técnico de cómo puede implementar la generación transparente de SBOM y la firma de contenedores en un flujo de trabajo de GitHub Actions:

name: Build, SBOM, and Sign

on:

  push:

    branches: [ "main" ]

# Crucial: Give the workflow permissions to request an OIDC token

permissions:

  contents: read

  packages: write

  id-token: write 

jobs:

  build-and-sign:

    runs-on: ubuntu-latest

    steps:

      - name: Checkout Code

        uses: actions/checkout@v3

      - name: Install Cosign

        uses: sigstore/cosign-installer@v3.1.1

        with:

          cosign-release: 'v2.1.1'

      - name: Install Syft

        uses: anchore/sbom-action/download-syft@v0.14.2

      - name: Log into GitHub Container Registry

        uses: docker/login-action@v2

        with:

          registry: ghcr.io

          username: ${{ github.actor }}

          password: ${{ secrets.GITHUB_TOKEN }}

      - name: Build and Push Docker Image

        id: build-image

        uses: docker/build-push-action@v4

        with:

          push: true

          tags: ghcr.io/your-startup/your-app:${{ github.sha }}

      - name: Generate and Attest SBOM

        run: |

          syft ghcr.io/your-startup/your-app:${{ github.sha }} -o spdx-json=sbom.spdx.json

          cosign attest --yes --predicate sbom.spdx.json --type spdx \

            ghcr.io/your-startup/your-app:${{ github.sha }}

      - name: Sign the Published Image (Keyless)

        run: |

          cosign sign --yes ghcr.io/your-startup/your-app:${{ github.sha }}

Cerrar el ciclo: aplicar firmas en Kubernetes

Generar firmas es solo la mitad de la batalla; debe aplicarlas en el momento de la implementación. Cuando su herramienta de orquestación (como Kubernetes) extrae la imagen, un controlador de admisión debe verificar la firma antes de permitir que el pod se ejecute. 

Usando Kyverno, puede implementar una política de confianza cero que valida la firma sin llave de Sigstore a la perfección. Si un atacante inyecta una imagen maliciosa en su registro, esta no tendrá la firma respaldada por OIDC y Kubernetes la rechazará por completo.

apiVersion: kyverno.io/v1

kind: ClusterPolicy

metadata:

  name: verify-image-signatures

spec:

  validationFailureAction: Enforce

  rules:

    - name: verify-github-actions-signature

      match:

        resources:

          kinds:

            - Pod

      verifyImages:

        - imageReferences:

          - "ghcr.io/your-startup/*"

          attestors:

          - entries:

            - keyless:

                subject: "https://github.com/your-startup/your-repo/.github/workflows/build.yml@refs/heads/main"

                issuer: "https://token.actions.githubusercontent.com"

Por qué esto es importante para la velocidad del desarrollador: Los desarrolladores simplemente envían el código. La canalización compila automáticamente la imagen, genera el SBOM, lo atesta al contenedor y lo firma criptográficamente. El clúster lo aplica automáticamente. La velocidad se mantiene al 100%.

---

Robustecimiento del entorno de compilación: ejecutores de CI/CD de confianza cero

Incluso con SBOM y firmas, su cadena de suministro de software es tan segura como el entorno que ejecuta la compilación. Un ejecutor de CI/CD comprometido es el sueño de un atacante: tiene las llaves de su entorno en la nube, su infraestructura como código y sus implementaciones de producción.

Eliminación de credenciales de larga duración

Si su repositorio de GitHub aún tiene secretos como AWS_ACCESS_KEY_ID y AWS_SECRET_ACCESS_KEY almacenados en la configuración, es altamente vulnerable. Si un atacante compromete una dependencia en su fase de pruebas, puede ejecutar código arbitrario en el ejecutor y exfiltrar esas credenciales estáticas, obteniendo un acceso permanente por puerta trasera a su cuenta de AWS.

La solución: Transición completa a la federación OIDC. Con OIDC, su plataforma de CI/CD actúa como un proveedor de identidad. AWS confía en GitHub y el ejecutor solicita credenciales STS temporales y de corta duración, válidas únicamente durante la duración de la tarea.

Ejemplo de política de confianza de AWS IAM para GitHub Actions:

{

  "Version": "2012-10-17",

  "Statement": [

    {

      "Effect": "Allow",

      "Principal": {

        "Federated": "arn:aws:iam::123456789012:oidc-provider/token.actions.githubusercontent.com"

      },

      "Action": "sts:AssumeRoleWithWebIdentity",

      "Condition": {

        "StringLike": {

          "token.actions.githubusercontent.com:sub": "repo:your-startup/your-app:*"

        },

        "StringEquals": {

          "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"

        }

      }

    }

  ]

}

Ejecutores efímeros y aislados

Los ejecutores de compilación compartidos y de larga duración (como una instancia dedicada de EC2 que ejecuta Jenkins o GitLab Runner las 24 horas del día, los 7 días de la semana) acumulan estado. Si una compilación extrae un paquete de NPM malicioso y con typosquatting, podría modificar sutilmente los módulos globales de node o la caché de compilación, envenenando todas las compilaciones subsiguientes. 

Para lograr el Nivel 3 de SLSA, los entornos de compilación deben ser efímeros y estar aislados.

Utilizando herramientas como Actions Runner Controller (ARC) en Kubernetes (EKS) combinadas con Karpenter, puede iniciar de forma dinámica un pod nuevo y prístino para cada tarea individual de CI/CD. 

1. Un desarrollador envía código.

2. ARC solicita un pod ejecutor.

3. Karpenter aprovisiona recursos de cómputo al instante.

4. La tarea se ejecuta en un contenedor completamente aislado y de confianza cero.

5. El ejecutor se destruye inmediatamente.

Cualquier artefacto malicioso introducido durante la compilación muere con el ejecutor. Además, puede aplicar políticas de red de salida estrictas a estos pods ejecutores. El ejecutor de compilación solo necesita acceso saliente a sus registros de confianza, GitHub y la API de su proveedor de nube. Denegar el acceso genérico de salida a Internet detiene de manera efectiva la filtración de datos en seco.

---

El pivote 80/20: la ventaja del SRE fraccional

Implementar el Nivel 3 de SLSA, implementar la firma sin llave a través de Cosign, escribir controladores de admisión a través de Kyverno, migrar secretos estáticos a OIDC y construir flotas de ejecutores efímeros es un trabajo complejo y altamente especializado. 

Aquí radica la trampa para las startups en crecimiento: Su equipo de ingeniería principal debería estar creando características que generen ingresos, no lidiando con la infraestructura de CI/CD.

Cuando se conoció la noticia de XZ Utils, uno de nuestros clientes —una startup de tecnología financiera Series B de rápido crecimiento— se dio cuenta de que estaba completamente expuesto. Sus clientes corporativos exigían el cumplimiento de SOC 2 y SBOM robustos, pero retirar a sus ingenieros senior de la hoja de ruta del producto para robustecer la cadena de suministro habría retrasado un lanzamiento de producto crítico por todo un trimestre. 

Aquí es exactamente donde interviene Betta. 

A través de nuestro modelo de ingeniería de plataformas y SRE fraccional, nos asociamos con su equipo interno. Nuestros expertos —que construyen estas canalizaciones efímeras y altamente seguras todos los días— se incorporaron como un equipo táctico especializado. 

En tres semanas:

• Auditamos y mapeamos toda su cadena de suministro de software.

• Migramos el 100% de sus secretos estáticos heredados a la federación OIDC.

• Implementamos la generación transparente de SBOM y la firma sin llave de Sigstore en GitHub Actions.

• Implementamos Actions Runner Controller (ARC) en un clúster EKS aislado para compilaciones completamente efímeras y de confianza cero.

• Configuramos controladores de admisión de Kyverno para bloquear la ejecución de cualquier imagen no firmada en producción.

¿La caída en la velocidad del desarrollador? Cero.

Los ingenieros de producto simplemente continuaron enviando código a la rama main. La única diferencia fue que, bajo el capó, toda la cadena de suministro ahora estaba blindada contra vectores de amenaza a nivel estatal, desbloqueando su canal de ventas corporativas de inmediato.

Por qué la modalidad fraccional tiene sentido económico

No necesita un ingeniero de DevSecOps de tiempo completo de USD $250,000 al año para mantener esta configuración una vez construida. Asegurar la cadena de suministro de software es un desafío arquitectónico intenso al principio. Al asociarse con Betta, las startups obtienen acceso a talento especializado de élite para diseñar e implementar la base correctamente desde la primera vez. Construimos el camino, aseguramos las barreras de protección y entregamos las llaves de regreso a su equipo. 

In un mundo posterior a XZ, ya no puede permitirse tratar su canalización de CI/CD como algo secundario. Pero tampoco puede permitirse congelar la velocidad del desarrollador para solucionarlo. Con la arquitectura adecuada y el socio especializado correcto, no tiene que elegir.