Riesgo de Manipulacion de Artefactos

Los artefactos de build (binarios, imagenes de contenedor, paquetes) producidos sin firmas criptograficas o atestaciones de procedencia pueden ser reemplazados silenciosamente por un atacante entre el build CI y el despliegue, resultando en compromiso de la cadena de suministro.

Cómo Funciona

En un pipeline CI/CD, el codigo se construye en artefactos: imagenes Docker, paquetes npm, binarios compilados o bundles de despliegue. Estos artefactos tipicamente se pushean a un registry o almacen de artefactos. Si los artefactos no estan firmados criptograficamente, no hay forma de verificar que fueron producidos por tu pipeline CI legitimo y que no han sido modificados. Un atacante que obtiene acceso al registry de artefactos (via credenciales filtradas, permisos mal configurados o un paso CI comprometido) puede reemplazar un artefacto legitimo con uno malicioso. Sin verificacion de firma al momento del despliegue, el artefacto manipulado se despliega a produccion. SLSA (Supply-chain Levels for Software Artifacts) y Sigstore proporcionan frameworks para firmar y verificar la procedencia de artefactos.

Código Vulnerable

# BAD: Docker image built and pushed without signing or attestation
name: Build and Push
on:
  push:
    branches: [main]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}
      - uses: docker/build-push-action@v5
        with:
          push: true
          tags: ghcr.io/myorg/myapp:latest
          # No signing, no attestation, no SBOM
          # Anyone with registry write access can replace this image

Código Seguro

# GOOD: Docker image with cosign signature and SLSA provenance
name: Build and Push
on:
  push:
    branches: [main]
jobs:
  build:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      packages: write
      id-token: write  # needed for cosign keyless signing
    steps:
      - uses: actions/checkout@v4
      - uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}
      - uses: docker/build-push-action@v5
        id: build
        with:
          push: true
          tags: ghcr.io/myorg/myapp:${{ github.sha }}
      - uses: sigstore/cosign-installer@v3
      - run: cosign sign --yes ghcr.io/myorg/myapp@${{ steps.build.outputs.digest }}

Ejemplo Real

El ataque de SolarWinds de 2020 es el ejemplo mas notorio de manipulacion de artefactos. Los atacantes comprometieron el sistema de build de SolarWinds e inyectaron codigo malicioso en el proceso de build del software Orion. Los artefactos de build manipulados fueron firmados con el certificado de firma de codigo legitimo de SolarWinds y distribuidos a 18,000 clientes incluyendo agencias del gobierno de EE.UU. Si hubiera existido atestacion de procedencia de artefactos, la modificacion no autorizada del output de build podria haberse detectado.

Cómo Prevenirlo

Firma todos los artefactos de build usando cosign (Sigstore) para imagenes de contenedor o GPG para paquetes y binarios
Genera atestaciones de procedencia SLSA en CI para probar criptograficamente que codigo fuente, builder y pasos de build produjeron cada artefacto
Usa tags inmutables (SHA de commit o digest) en lugar de tags mutables como 'latest' para prevenir ataques de reemplazo basados en tags
Verifica las firmas de artefactos al momento del despliegue antes de jalar o ejecutar cualquier artefacto en entornos de produccion

Tecnologías Afectadas

GitHub ActionsNode.jsPythonDocker

Data Hogo detecta esta vulnerabilidad automáticamente.

Escanea Tu Repo Gratis

Vulnerabilidades Relacionadas

GitHub Actions Sin Fijar a SHA

high

Usar GitHub Actions referenciados por tags mutables como @main o @v3 en lugar de SHAs de commit completos significa que una action comprometida o secuestrada puede inyectar codigo malicioso en tu pipeline CI sin ningun cambio en tu archivo workflow.

CWE-1395OWASP A08:2021

Inyeccion de Script en GitHub Actions

critical

Usar datos de eventos no confiables como github.event.issue.title directamente dentro de bloques run: permite a los atacantes inyectar comandos shell arbitrarios en tu pipeline CI creando titulos de issues, cuerpos de PR o mensajes de commit maliciosos.

CWE-94OWASP A03:2021

Secretos Filtrados en Logs de CI

high

Imprimir o hacer echo de variables de entorno que contienen secretos en scripts de CI los expone en los logs de build, que frecuentemente son accesibles para todos los colaboradores del repositorio y a veces visibles publicamente en proyectos open-source.

CWE-532OWASP A09:2021

Riesgos de Runners Self-Hosted

high

Usar runners self-hosted de GitHub Actions con pull_request_target o workflows de forks publicos permite que codigo no confiable de contribuidores externos se ejecute en tu infraestructura con acceso a secrets, estado persistido y la red del host.

CWE-94OWASP A08:2021