# Seguridad de la cadena de suministro de software

**Categoría:** DevOps y cloud · **Nivel:** Intermedio · **Lectura:** 15 min
**Publicada:** 2026-07-27 · **Actualizada:** 2026-07-27 · **Autoría:** Underc0de
**Versión HTML (canónica):** https://underc0de.org/guias/devops-cloud/seguridad-de-la-cadena-de-suministro-de-software/

## Respuesta rápida

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: 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 encuadre defensivo: proteger lo propio.

## 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.

| Eslabón | Cómo se rompe | Control que lo cubre |
|---|---|---|
| Origen del código | Cuenta comprometida, confirmación sin revisión | Revisión obligatoria, doble factor, historial protegido |
| Dependencias | Paquete malicioso, mantenedor comprometido, nombre parecido | Archivo de bloqueo, revisión de dependencias, espejos internos |
| Compilación | 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 al admitir, referencias por resumen |

## Los ataques que ya pasaron

- **Paquetes maliciosos en los registros públicos.** En julio de 2026 se detectaron [paquetes maliciosos en npm y PyPI que roban credenciales](https://blog.underc0de.org/detectan-paquetes-maliciosos-en-npm-y-pypi-que-roban-credenciales/).
- **Un paquete legítimo que se vuelve malicioso.** El caso de [malware en versiones npm de node-ipc](https://blog.underc0de.org/malware-detectado-en-versiones-npm-de-node-ipc/): 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 RAT disfrazado de corrector ortográfico](https://blog.underc0de.org/paquetes-maliciosos-en-pypi-distribuyen-rat-disfrazado-de-corrector-ortografico/) apuntan a lo que nadie revisa.
- **El registro de modelos también es cadena de suministro.** El [malware en Hugging Face que suplantaba un modelo de OpenAI](https://blog.underc0de.org/malware-en-hugging-face-suplanta-modelo-de-openai/) extiende el problema a los pesos.
- **Credenciales dentro del artefacto.** En [más de 10.000 imágenes de Docker Hub se detectaron credenciales filtradas](https://blog.underc0de.org/mas-de-10-000-imagenes-de-docker-hub-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: la instalación automática de dependencias.

## SBOM: saber qué enviás

Un **SBOM** —*Software Bill of Materials*— es el inventario de todo lo que compone un artefacto: componentes, versiones y relaciones. Responde una pregunta que sin él lleva días: *cuando aparezca una vulnerabilidad crítica en una biblioteca, ¿en cuáles de mis sistemas está y en qué versión?*

- **SPDX.** «Un estándar abierto capaz de representar sistemas con componentes de software como SBOM.» Es estándar internacional **ISO/IEC 5962:2021**.
- **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 Ecma International y publicado como **ECMA-424**. Cubre además inventarios de servicios, criptografía, hardware, modelos de IA y explotabilidad de vulnerabilidades.

Generar un SBOM y guardarlo en una carpeta no aporta nada: el valor aparece cuando está **asociado a cada artefacto publicado** y existe forma de consultarlo.

## SLSA y la procedencia

**SLSA** —*Supply-chain Levels for Software Artifacts*, 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». La pieza central es la **procedencia**: la declaración verificable de cómo se produjo un artefacto.

1. **Nivel 0 · Ninguna garantía.** «Sin requisitos: L0 representa la ausencia de SLSA.»
2. **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.»
3. **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.»
4. **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.»

El nivel 1 protege contra **errores**, el nivel 2 contra la **alteración posterior a la compilación** y el nivel 3 contra la **alteración durante la compilación**. Si un paso arbitrario del pipeline puede leer la clave de firma, la firma no prueba nada.

## Firmar sin custodiar claves

**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 |
| Fulcio | La autoridad de certificación: verifica un token de OpenID Connect y emite un certificado de corta duración que liga la clave pública a esa identidad |
| Rekor | El **log de transparencia**: registro inmutable y de solo adición de los eventos de firma |

Ya no se confía en «quien tenga la clave» sino en «esta identidad firmó esto, y quedó registrado». Para un pipeline, la identidad que firma puede ser **el propio flujo de trabajo**. El proyecto está respaldado por la **OpenSSF**, dentro de la Linux Foundation.

## El marco de prácticas del NIST

El **NIST SP 800-218**, «Secure Software Development Framework (SSDF) Version 1.1», de febrero de 2022, organiza las prácticas en cuatro grupos:

- **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.»

Existe además el **SP 800-218A**, perfil comunitario del mismo marco para IA generativa y modelos de base de doble uso.

## Qué hacer el lunes

```bash
# 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.
- **Análisis de dependencias en cada propuesta de cambio.** Que agregar una dependencia sea una decisión visible.
- **Ningún secreto en el código ni en la imagen.**
- **Generar procedencia y firmar los artefactos.** El salto de SLSA nivel 0 a 1 y 2.
- **Verificar la firma en el momento de admitir.** Sin este paso, firmar es decorativo.
- **Publicar un SBOM por artefacto.** Y tener el medio para consultarlo.

**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

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. 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.

## Errores frecuentes

- **Firmar y no verificar.**
- **Confiar en etiquetas.** Una etiqueta se puede reescribir; un resumen criptográfico, no.
- **Generar el SBOM y archivarlo.**
- **Auditar una dependencia una sola vez.** El riesgo está en la próxima versión.
- **Dar permisos amplios al pipeline «para que no falle».**
- **Mirar solo las dependencias directas.**
- **Tratar los modelos de IA como datos y no como software.**

## Preguntas frecuentes

**¿Qué es la cadena de suministro de software?**
Todo lo que interviene entre el código que alguien escribe y el software que se ejecuta: repositorio, dependencias, compilación, registros y 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?**
El inventario de todo lo que compone un artefacto. Sirve para responder en minutos dónde está una biblioteca vulnerable. Formatos de referencia: SPDX (ISO/IEC 5962:2021) y CycloneDX (ECMA-424, OWASP).

**¿Qué es SLSA y qué son sus niveles?**
Un conjunto de pautas de adopción incremental establecidas por consenso de la industria. Su vía de compilación define cuatro niveles, de L0 —ausencia de SLSA— a L3, con compilaciones endurecidas.

**¿Qué es la procedencia y por qué importa firmarla?**
Es la declaración verificable de cómo se produjo un artefacto. Sin firma la puede escribir cualquiera; con firma de la plataforma, «¿esta imagen salió de mi pipeline?» tiene respuesta comprobable.

**¿Cómo funciona la firma sin claves de Sigstore?**
Claves efímeras por firma, un certificado de corta duración emitido contra una identidad de OpenID Connect y un registro público de transparencia. La clave privada se descarta.

**¿Por dónde empiezo si no tengo nada de esto?**
Fijar dependencias con archivo de bloqueo, fijar las acciones del pipeline por identificador exacto y reducir los permisos de los tokens al mínimo.

## Fuentes

Fecha de consulta: 27 de julio de 2026.

**Aportes de la comunidad Underc0de**

1. Underc0de, blog. [Detectan paquetes maliciosos en npm y PyPI que roban credenciales](https://blog.underc0de.org/detectan-paquetes-maliciosos-en-npm-y-pypi-que-roban-credenciales/), 9 de julio de 2026.
2. Underc0de, blog. [Malware detectado en versiones npm de node-ipc](https://blog.underc0de.org/malware-detectado-en-versiones-npm-de-node-ipc/), 14 de mayo de 2026.
3. Underc0de, blog. [Malware en Hugging Face suplanta modelo de OpenAI](https://blog.underc0de.org/malware-en-hugging-face-suplanta-modelo-de-openai/), 12 de mayo de 2026.
4. Underc0de, blog. [Paquetes maliciosos en PyPI distribuyen un RAT disfrazado de corrector ortográfico](https://blog.underc0de.org/paquetes-maliciosos-en-pypi-distribuyen-rat-disfrazado-de-corrector-ortografico/), 28 de enero de 2026.
5. Underc0de, blog. [Más de 10.000 imágenes de Docker Hub con credenciales filtradas](https://blog.underc0de.org/mas-de-10-000-imagenes-de-docker-hub-detectaron-credenciales-filtradas/), 11 de diciembre de 2025.

**Documentación oficial y estándares**

6. SLSA, Linux Foundation. [About SLSA](https://slsa.dev/spec/v1.2/about), especificación versión 1.2.
7. SLSA. [Build track basics](https://slsa.dev/spec/v1.2/build-track-basics).
8. NIST. [Secure Software Development Framework (SSDF)](https://csrc.nist.gov/Projects/ssdf), SP 800-218 versión 1.1, febrero de 2022.
9. Sigstore, OpenSSF. [Sigstore overview](https://docs.sigstore.dev/about/overview/).
10. SPDX, Linux Foundation. [SPDX](https://spdx.dev/).
11. OWASP CycloneDX. [CycloneDX Bill of Materials Standard](https://cyclonedx.org/).

## Guías relacionadas

- [GitOps con Kubernetes y Argo CD](../gitops-con-kubernetes-y-argo-cd/index.md)
- [Inteligencia artificial aplicada a pipelines CI/CD](../inteligencia-artificial-en-pipelines-ci-cd/index.md)
- [Platform Engineering e Internal Developer Platforms](../platform-engineering-e-internal-developer-platforms/index.md)
- [Índice de DevOps y cloud](../index.md)