Cadena de suministro
¿Qué es la seguridad de la cadena de suministro de software?
La seguridad de la cadena de suministro de software es la práctica de proteger todo lo que entra en su software antes de que llegue a los usuarios: los paquetes de código abierto, el sistema de build, las herramientas del pipeline y la propia versión. Los atacantes van cada vez más a por estos elementos en lugar de a por su aplicación, porque un solo paquete o paso de build comprometido llega a todos los productos que lo utilizan.
Actualizado el
¿Qué es la cadena de suministro de software?
La cadena de suministro de software es todo aquel y todo aquello que interviene en llevar el software desde el editor de un desarrollador hasta producción. Puede pensar en ella en cuatro etapas, cada una con sus propios riesgos.
| Etapa | Qué incluye | Qué puede fallar |
|---|---|---|
| Código fuente | Su código, sus repositorios y las cuentas de los desarrolladores | Credenciales robadas, commits maliciosos, secretos filtrados |
| Dependencias | Paquetes de código abierto, imágenes base, código de terceros | Versiones vulnerables, versiones maliciosas, typosquatting |
| Build | Runners de CI, GitHub Actions, herramientas de build, cachés | Acciones comprometidas, cachés envenenadas, secretos del pipeline robados |
| Lanzamiento | Artefactos, registros, despliegues, actualizaciones | Artefactos sustituidos, actualizaciones manipuladas, ningún registro de lo distribuido |
Por qué importa ahora
La mayor parte de lo que usted distribuye no lo escribió usted. Una aplicación moderna es en su mayoría código abierto, y cada dependencia directa trae otras que nadie de su equipo eligió. Esos paquetes se ejecutan con el mismo acceso que su propio código, y sus scripts de instalación pueden ejecutarse dentro de su pipeline de CI, junto a sus secretos.
La historia de los últimos años muestra cómo se aprovecha esto:
- SolarWinds: se comprometió el build, de modo que un código fuente limpio generó una versión envenenada.
- Log4Shell: un fallo en una biblioteca de registro llegó a productos que no sabían que la usaban.
- xz utils: un colaborador de confianza introdujo una puerta trasera en un proyecto presente en distribuciones de Linux.
- tj-actions: una GitHub Action secuestrada ejecutó código del atacante en los pipelines que la utilizaban, con los secretos a su alcance.
- Shai-Hulud: un gusano se propagó por paquetes npm y robó tokens de las máquinas y los jobs de CI que los instalaron.
Para ver paso a paso cómo funcionan estos ataques, consulte qué es un ataque a la cadena de suministro.
Cómo funciona la seguridad de la cadena de suministro de software
Un programa necesita cuatro cosas. Todo lo demás son detalles.
- Sepa lo que distribuye. Mantenga una SBOM precisa de cada versión, obtenida del build que la generó, con las dependencias transitivas incluidas.
- Controle lo que entra. Fije las versiones, utilice un lockfile, limite desde dónde pueden descargar los builds y examine los paquetes nuevos.
- Proteja el build. Aísle los jobs, limite los secretos, fije las acciones por commit y restrinja el tráfico saliente, para que un paquete comprometido no pueda enviar sus tokens a ningún sitio. Consulte seguridad de los runners y por qué la seguridad de la cadena de suministro pertenece al CI.
- Siga vigilando lo que distribuyó. Las nuevas vulnerabilidades afectan al software que ya está en producción. Monitorícelo, averigüe qué versiones están afectadas y siga cada corrección hasta una nueva versión.
Para ver la lista detallada, consulte buenas prácticas de seguridad de la cadena de suministro de software.
Marcos y normativas
| Nombre | Qué es | Ideal para |
|---|---|---|
| SLSA | Niveles de integridad y procedencia del build | Reforzar cómo se compila el software |
| NIST SSDF | Prácticas de desarrollo seguro, SP 800-218 | Un programa completo de desarrollo seguro |
| NIST SP 800-161 | Gestión de riesgos de ciberseguridad en la cadena de suministro | Gestión de riesgos en toda la organización |
| OpenSSF Scorecard | Comprobaciones automatizadas de la salud de los proyectos de código abierto | Examinar dependencias |
| Cyber Resilience Act | Ley de la UE para productos con elementos digitales | Vender en la UE. Consulte qué es el CRA |
¿Qué herramientas intervienen?
Ningún producto cubre todo esto por sí solo. La categoría se divide en herramientas de SCA, herramientas de SBOM, seguridad de CI/CD y de runners, firewalls de paquetes, gestión de la postura de seguridad de aplicaciones y análisis de binarios. Para saber qué hace cada una y quién las vende, consulte la comparativa de herramientas de seguridad de la cadena de suministro de software y cuánto cuestan.
Por dónde empezar
- Genere una SBOM de su producto más importante a partir de su build de CI, y léala.
- Active las alertas de vulnerabilidades en dependencias y decida quién se responsabiliza de ellas.
- Fije sus GitHub Actions por commit y revise a qué secretos pueden acceder sus workflows.
- Restrinja el tráfico saliente de sus builds a los hosts que realmente necesitan.
- Configure la monitorización de lo que ha distribuido, no solo de lo que está compilando.
Cómo lo aborda CRACI
CRACI empieza por el build, porque el build es el único lugar que lo ve todo. Sustituye sus runners alojados por GitHub por otros más rápidos y de menor coste que registran cada paquete que descarga cada job, a cualquier profundidad del árbol e incluidos los paquetes restaurados desde cachés de CI. La política de salida bloquea las conexiones que su build no necesita, de modo que le protege incluso frente a un ataque que nadie haya visto antes. Después, CRACI sigue cotejando lo distribuido con las nuevas vulnerabilidades y acompaña cada una desde el triaje hasta una versión corregida. Consulte seguridad de la cadena de suministro de software con CRACI.
Seguridad de la cadena de suministro de software: preguntas frecuentes
¿Qué es la seguridad de la cadena de suministro de software?
Es la práctica de proteger todo lo que entra en su software antes de que llegue a los usuarios: dependencias de código abierto, sistemas de build, herramientas del pipeline y versiones.
¿Qué ejemplo hay de un ataque a la cadena de suministro de software?
En el ataque a SolarWinds se comprometió el build, de modo que los clientes recibieron una actualización envenenada de un proveedor de confianza. En los ataques de Shai-Hulud, un gusano se propagó por paquetes npm y robó tokens de las máquinas que los instalaron.
¿Cuál es la diferencia entre la seguridad de la cadena de suministro y la seguridad de aplicaciones?
La seguridad de aplicaciones examina los fallos del código que usted escribe. La seguridad de la cadena de suministro examina lo que usted no escribió y cómo se compila y se lanza su software. Un programa necesita ambas.
¿Basta una SBOM para la seguridad de la cadena de suministro?
No. Una SBOM le dice lo que distribuye, que es la base. También necesita controlar lo que entra, proteger el build y seguir monitorizando lo que ha lanzado.
¿Cuáles son los principales marcos?
SLSA para la integridad del build, el NIST SSDF para las prácticas de desarrollo seguro y NIST SP 800-161 para la gestión de riesgos de la cadena de suministro. En la UE, el Cyber Resilience Act establece requisitos legales para los productos con elementos digitales.
¿Quién es responsable de la seguridad de la cadena de suministro de software?
Suele recaer en la seguridad de aplicaciones o de producto, en colaboración con los equipos de plataforma y DevOps que gestionan los pipelines. Las correcciones pasan después a los equipos de ingeniería responsables de cada servicio.
Vea lo que descargan realmente sus builds
Ejecute un workflow de GitHub Actions en CRACI y obtenga una SBOM registrada del build, además de su traza de red.
Reservar una demo