La cadena de suministro de software es todo lo que interviene entre el código que alguien escribe y el software que se ejecuta: repositorio, dependencias, compilación, registros de paquetes y distribución. La documentación de SLSA lo resume así: existe «riesgo de modificación de código» en cada eslabón, «desde el origen hasta la compilación, pasando por el empaquetado y la distribución». Defenderla se apoya en cuatro controles que se refuerzan entre sí: un SBOM para saber qué se envía, procedencia firmada para saber de dónde vino, fijado de versiones para reducir lo que se confía, y un proceso de compilación endurecido —lo que SLSA mide con niveles—. Todo con un encuadre defensivo: proteger lo propio.
Ver índice de contenidos
Dónde se rompe la cadena
El cambio de mentalidad que exige este tema es incómodo: el código que escribís es una fracción mínima del que ejecutás. Una aplicación con diez dependencias declaradas arrastra cientos de dependencias indirectas, cada una mantenida por gente que no conocés y publicada en un registro al que tu pipeline le cree por defecto.
La documentación de SLSA lo enuncia sin rodeos: el riesgo de modificación del código «existe en cada eslabón de una cadena de suministro típica de software, desde el origen hasta la compilación, pasando por el empaquetado y la distribución». Y el ataque es atractivo porque es más eficiente comprometer un paquete que usan miles de organizaciones que atacar a cada una por separado. Los eslabones, con el tipo de falla que aparece en cada uno:
| Eslabón | Cómo se rompe | Control que lo cubre |
|---|---|---|
| Origen del código | Cuenta comprometida, confirmación sin revisión, dependencia agregada a mano | Revisión obligatoria, doble factor, historial protegido |
| Dependencias | Paquete malicioso, mantenedor comprometido, nombre parecido al legítimo | Archivo de bloqueo, revisión de dependencias, espejos internos |
| Compilación | Pipeline con permisos excesivos, acción de tercero sin fijar, secretos accesibles | Niveles de SLSA, permisos mínimos, aislamiento |
| Empaquetado | Artefacto alterado después de compilar | Firma y procedencia verificables |
| Distribución | Registro comprometido, imagen suplantada, etiqueta reescrita | Verificación en el momento de admitir, referencias por resumen |
Los ataques que ya pasaron
Esto no es teórico. El blog de Underc0de documenta el patrón con regularidad, y los casos enseñan más que cualquier lista de recomendaciones:
- Paquetes maliciosos en los registros públicos. En julio de 2026 se detectaron paquetes maliciosos en npm y PyPI que roban credenciales. El vector es el más simple de todos: publicar algo que parezca útil y esperar que alguien lo instale.
- Un paquete legítimo que se vuelve malicioso. El caso de malware en versiones de npm de node-ipc muestra el escenario que rompe la intuición: la dependencia que auditaste ayer puede publicar mañana una versión distinta.
- Disfraz de herramienta inofensiva. Los paquetes en PyPI que distribuían un troyano disfrazado de corrector ortográfico apuntan a lo que nadie revisa: las utilidades chicas y aburridas.
- El registro de modelos también es cadena de suministro. El malware en Hugging Face que suplantaba un modelo de OpenAI extiende el problema a los pesos de modelos, que se descargan con la misma confianza que un paquete.
- Credenciales que viajan dentro del artefacto. En más de 10.000 imágenes de Docker Hub se detectaron credenciales filtradas: el secreto no se robó, se publicó.
El hilo común es que ninguno de esos ataques requiere vulnerar tu infraestructura. Entran por la puerta que dejaste abierta a propósito, que es la instalación automática de dependencias.
SBOM: saber qué enviás
Un SBOM —Software Bill of Materials, lista de materiales del software— es el inventario de todo lo que compone un artefacto: componentes, versiones y relaciones. Su valor se entiende con la pregunta que responde: cuando mañana aparezca una vulnerabilidad crítica en una biblioteca, ¿en cuáles de mis sistemas está y en qué versión? Sin inventario, la respuesta lleva días de rastreo manual. Los dos formatos abiertos de referencia:
- SPDX. Se describe como «un estándar abierto capaz de representar sistemas con componentes de software como SBOM». Es estándar internacional: ISO/IEC 5962:2021. Su versión 3.1 extiende el modelo más allá del software, a seguridad, servicios, hardware y cadena de suministro.
- CycloneDX. «Un estándar completo de lista de materiales que provee capacidades avanzadas de cadena de suministro para la reducción del riesgo cibernético», mantenido por la Fundación OWASP junto con el comité técnico de Ecma International y publicado como ECMA-424. Cubre además de SBOM otros tipos de inventario: de servicios, de criptografía, de hardware, de modelos de IA y de explotabilidad de vulnerabilidades.
El error de tratarlo como un trámite
Generar un SBOM y guardarlo en una carpeta no aporta nada. El valor aparece cuando está asociado a cada artefacto publicado y existe una forma de consultarlo para todo el parque. Si ante una vulnerabilidad nueva nadie puede decir en diez minutos dónde está la biblioteca afectada, el SBOM todavía no sirve.
SLSA y la procedencia
SLSA —Supply-chain Levels for Software Artifacts, y se pronuncia «salsa»— se define como «un conjunto de pautas de adopción incremental para la seguridad de la cadena de suministro, establecidas por consenso de la industria». Su valor práctico está en que no exige todo de una vez: propone niveles.
La pieza central es la procedencia: la declaración verificable de cómo se produjo un artefacto —de qué origen salió, con qué proceso, en qué plataforma, a partir de qué entradas—. Su vía de compilación define cuatro niveles:
- Nivel 0 · Ninguna garantía«Sin requisitos: L0 representa la ausencia de SLSA.» Es el punto de partida de la mayoría.
- Nivel 1 · Existe procedencia«El paquete tiene procedencia que muestra cómo se compiló. Puede usarse para prevenir errores, pero es trivial de eludir o falsificar.»
- Nivel 2 · Plataforma de compilación alojada«Falsificar la procedencia o eludir la verificación requiere un “ataque” explícito, aunque este puede ser fácil de realizar.»
- Nivel 3 · Compilaciones endurecidas«Falsificar la procedencia o eludir la verificación requiere explotar una vulnerabilidad más allá de las capacidades de la mayoría de los adversarios.»
La progresión tiene una lógica clara: el nivel 1 protege contra errores, el nivel 2 contra la alteración posterior a la compilación —porque la procedencia está firmada por la plataforma— y el nivel 3 contra la alteración durante la compilación, con aislamiento entre ejecuciones y protección de las claves frente a los pasos que define quien envía el código. Ese último punto es el más subestimado: si un paso arbitrario del pipeline puede leer la clave de firma, la firma no prueba nada.
Firmar sin custodiar claves
Firmar artefactos es una recomendación vieja que casi nadie seguía, por una razón práctica: custodiar claves de larga vida es difícil. Si la clave vive en el sistema de integración continua, quien lo compromete firma lo que quiera; si vive en una computadora personal, el proceso deja de ser automático. Sigstore —«un proyecto de código abierto para mejorar la seguridad de la cadena de suministro de software»— cambia el modelo: en lugar de custodiar una clave, se apoya en identidades y en un registro público.
| Componente | Qué hace |
|---|---|
| Cosign | El cliente: genera un par de claves efímero para cada firma y coordina el proceso, sin que nadie administre claves de larga vida |
| Fulcio | La autoridad de certificación: verifica un token de identidad de OpenID Connect y emite un certificado de corta duración que liga la clave pública a esa identidad —una persona, una cuenta de servicio o un flujo de trabajo de integración continua— |
| Rekor | El log de transparencia: un registro inmutable y de solo adición de los eventos de firma, que permite auditar públicamente y detectar usos indebidos de una identidad |
El cambio de fondo es el sujeto de la confianza: ya no se confía en «quien tenga la clave» sino en «esta identidad firmó esto, y quedó registrado donde todos pueden verlo». Para un pipeline, la identidad que firma puede ser el propio flujo de trabajo, lo que vuelve verificable la afirmación «esta imagen salió de mi pipeline, a partir de mi repositorio». El proyecto está respaldado por la OpenSSF, dentro de la Linux Foundation.
El marco de prácticas del NIST
Las herramientas resuelven partes del problema; el proceso las ordena. El NIST SP 800-218, «Secure Software Development Framework (SSDF) Version 1.1», publicado en febrero de 2022, organiza las prácticas en cuatro grupos que sirven bien como estructura de trabajo:
- Preparar la organización (PO). «Asegurar que las personas, los procesos y la tecnología de la organización estén preparados para realizar desarrollo seguro de software.»
- Proteger el software (PS). «Proteger todos los componentes del software contra la alteración y el acceso no autorizado.»
- Producir software bien protegido (PW). «Producir software bien protegido, con vulnerabilidades mínimas en sus versiones publicadas.»
- Responder a las vulnerabilidades (RV). «Identificar las vulnerabilidades residuales en las versiones publicadas y responder de forma apropiada.»
Los dos que más suelen faltar son el segundo y el cuarto. Proteger el software es donde entran la firma y la procedencia; responder a las vulnerabilidades es lo que hace que el SBOM tenga sentido, porque sin proceso de respuesta el inventario es un archivo. Existe además el SP 800-218A, un perfil comunitario del mismo marco para IA generativa y modelos de base de doble uso: la señal de que el problema ya incluye los pesos y los datos, no solo el código.
Qué hacer el lunes
Este tema paraliza porque parece exigir un programa entero. No es así: hay tres medidas de costo bajo que cubren el escenario del incidente típico.
# 1. Instalar exactamente lo que dice el archivo de bloqueo, sin resolver de nuevo
npm ci # respeta package-lock.json y falla si no coincide
pip install -r requirements.txt --require-hashes
# 2. Fijar los componentes del pipeline por identificador exacto, no por etiqueta
# ✗ usa: acciones/checkout@v4 una etiqueta se puede reescribir
# ✓ usa: acciones/checkout@<resumen-completo-del-commit>
# 3. Referenciar imágenes por resumen y no por etiqueta
# ✗ imagen:ultima ✓ imagen@sha256:<resumen>Y después, en orden de esfuerzo creciente:
- Permisos mínimos en los tokens del pipeline. De solo lectura por defecto, y escritura solo en el trabajo que la necesita.
- Análisis de dependencias en cada propuesta de cambio. Que agregar una dependencia sea una decisión visible en la revisión, no un detalle del archivo de bloqueo.
- Ningún secreto en el código ni en la imagen. Variables de entorno o gestor de secretos, y revisión automática para detectar los que se filtren.
- Generar procedencia y firmar los artefactos. El salto de SLSA nivel 0 a nivel 1 y 2, que hoy la mayoría de las plataformas de compilación ofrece de forma integrada.
- Verificar la firma en el momento de admitir. Que el entorno rechace lo que no viene firmado por una identidad esperada. Sin este paso, firmar es decorativo.
- Publicar un SBOM por artefacto. Y tener el medio para consultarlo cuando aparezca la próxima vulnerabilidad.
El quinto punto merece énfasis porque es el más olvidado: una firma que nadie verifica no protege de nada. La cadena se cierra en el consumo, no en la producción.
El riesgo nuevo que trae la IA
La asistencia por IA agregó un vector que conviene conocer. Un modelo puede sugerir con total confianza el nombre de un paquete que no existe, y si ese nombre inventado se repite, alguien puede registrarlo con contenido malicioso a la espera de que se instale. Es una suplantación de nombre que no necesita parecerse a nada legítimo: basta con ocupar el hueco que la herramienta inventó.
La defensa es la disciplina de siempre con más atención: verificar que cada dependencia sugerida existe, es la que se quería y tiene mantenimiento real, antes de que llegue al archivo de bloqueo. El mismo criterio vale para los modelos y pesos que se descargan.
Errores frecuentes
- Firmar y no verificar. La mitad de la operación que no protege nada por sí sola.
- Confiar en etiquetas. Una etiqueta se puede reescribir; un resumen criptográfico, no.
- Generar el SBOM y archivarlo. Sin proceso de consulta y respuesta, es documentación muerta.
- Auditar una dependencia una sola vez. El riesgo no está en la versión que revisaste, sino en la próxima.
- Dar permisos amplios al pipeline «para que no falle». Es el atajo que convierte una falla menor en un compromiso total.
- Mirar solo las dependencias directas. El árbol indirecto es donde vive la mayor parte del código que ejecutás.
- Tratar los modelos de IA como datos y no como software. Se descargan de registros públicos igual que los paquetes.
Preguntas frecuentes
¿Qué es la cadena de suministro de software?
Es todo lo que interviene entre el código que alguien escribe y el software que termina ejecutándose: el repositorio, las dependencias de terceros, el sistema de compilación, los registros de paquetes e imágenes, y el mecanismo de distribución. La documentación de SLSA lo plantea con precisión: existe riesgo de modificación del código en cada eslabón, desde el origen hasta la compilación y de ahí al empaquetado y la distribución. Atacar la cadena es más rentable que atacar un objetivo, porque un solo paquete comprometido llega a todos sus usuarios.
¿Qué es un SBOM y para qué sirve?
Un SBOM es el inventario de todo lo que compone un artefacto de software: componentes, versiones y relaciones entre ellos. Sirve para responder en minutos una pregunta que sin él lleva días: cuando aparece una vulnerabilidad en una biblioteca, ¿en cuáles de mis sistemas está y en qué versión? Los dos formatos abiertos de referencia son SPDX, estándar internacional ISO/IEC 5962:2021, y CycloneDX, mantenido por la Fundación OWASP junto con Ecma International y publicado como ECMA-424.
¿Qué es SLSA y qué son sus niveles?
SLSA —Supply-chain Levels for Software Artifacts, que se pronuncia «salsa»— es «un conjunto de pautas de adopción incremental para la seguridad de la cadena de suministro, establecidas por consenso de la industria». Su vía de compilación define cuatro niveles: L0 es la ausencia de SLSA; en L1 existe procedencia que muestra cómo se compiló el artefacto, útil contra errores pero trivial de falsificar; en L2 la compilación corre en una plataforma alojada que firma la procedencia; y en L3 la plataforma está endurecida, con aislamiento entre ejecuciones y protección de las claves de firma.
¿Qué es la procedencia y por qué importa firmarla?
La procedencia es la declaración verificable de cómo se produjo un artefacto: de qué origen salió, con qué proceso, en qué plataforma y a partir de qué entradas. Sin firma, esa declaración la puede escribir cualquiera, así que el valor aparece cuando la genera la plataforma de compilación y la firma con una clave que quien envía el código no controla. Ahí la pregunta «¿esta imagen salió de mi pipeline, a partir de mi repositorio?» pasa a tener una respuesta comprobable en lugar de una suposición.
¿Cómo funciona la firma sin claves de Sigstore?
Sigstore evita el problema de custodiar claves de larga vida. Su cliente genera un par de claves efímero para cada firma; Fulcio, la autoridad de certificación, verifica una identidad por medio de un token de OpenID Connect —una cuenta, un servicio o un flujo de trabajo de integración continua— y emite un certificado de corta duración que liga esa clave pública a esa identidad; y Rekor registra el evento en un log de transparencia inmutable y de solo adición. La clave privada se descarta y la verificación se apoya en el registro público.
¿Por dónde empiezo si no tengo nada de esto?
Por lo que cuesta poco y elimina las fallas más comunes: fijar las versiones de las dependencias con un archivo de bloqueo y que la instalación en el pipeline respete ese archivo; fijar las acciones y contenedores de terceros del pipeline por identificador exacto y no por etiqueta móvil; y reducir los permisos de los tokens del pipeline al mínimo, de solo lectura por defecto. Con esas tres cosas ya no dependés de que nadie publique una versión nueva con sorpresa, que es el escenario del incidente típico.
Fuentes
Documentación oficial y material de la comunidad consultados para esta guía. Fecha de consulta: 27 de julio de 2026.
Aportes de la comunidad Underc0de
- Underc0de, blog. Detectan paquetes maliciosos en npm y PyPI que roban credenciales, 9 de julio de 2026.
- Underc0de, blog. Malware detectado en versiones npm de node-ipc, 14 de mayo de 2026.
- Underc0de, blog. Malware en Hugging Face suplanta modelo de OpenAI, 12 de mayo de 2026.
- Underc0de, blog. Paquetes maliciosos en PyPI distribuyen un RAT disfrazado de corrector ortográfico, 28 de enero de 2026.
- Underc0de, blog. Más de 10.000 imágenes de Docker Hub con credenciales filtradas, 11 de diciembre de 2025.
Documentación oficial y estándares
- SLSA, Linux Foundation. About SLSA, especificación versión 1.2. Definición, significado de la sigla y el riesgo en cada eslabón, citados textualmente.
- SLSA. Build track basics. Los cuatro niveles de la vía de compilación, con sus descripciones textuales.
- NIST. Secure Software Development Framework (SSDF), SP 800-218 versión 1.1, febrero de 2022. Los cuatro grupos de prácticas, citados textualmente. Incluye el perfil SP 800-218A para IA generativa.
- Sigstore, OpenSSF. Sigstore overview. Definición del proyecto y funcionamiento de Cosign, Fulcio y Rekor.
- SPDX, Linux Foundation. SPDX. Definición del estándar y su condición de ISO/IEC 5962:2021.
- OWASP CycloneDX. CycloneDX Bill of Materials Standard. Definición, designación ECMA-424 y tipos de inventario que cubre.