Seguridad en la cadena de suministro de software: por qué los SBOM serán imprescindibles en 2026
⏱ 8 min de lectura
SolarWinds, Log4Shell, 3CX – la lista de ataques exitosos a la cadena de suministro de software se alarga cada año. Sonatype cifra el aumento de los ataques a componentes de código abierto en más del 700 por ciento desde 2020. Al mismo tiempo, la Ley de Resiliencia Cibernética de la UE (CRA) hará obligatorios los Software Bills of Materials (SBOM) a partir de 2027 para todos los productos digitales. Las empresas que no actúen ahora se quedarán pronto sin acceso al mercado.
En resumen
- 700 % más ataques a la cadena de suministro desde 2020: las dependencias de código abierto son la puerta de entrada principal – una aplicación utiliza de media más de 200 dependencias transitivas (Sonatype, 2025).
- Ley de Resiliencia Cibernética de la UE (CRA): a partir de 2027, todos los productos digitales deberán entregarse con SBOM, gestión de vulnerabilidades y actualizaciones de seguridad.
- Integración en DevSecOps: la generación de SBOM, el escaneo de dependencias y la firma de contenedores deben integrarse en la CI/CD – no en listas de verificación manuales.
Anatomía de un ataque a la cadena de suministro
Los ataques a la cadena de suministro no apuntan al software en sí, sino a sus dependencias – bibliotecas, frameworks, herramientas de compilación y componentes de infraestructura. El vector de ataque es especialmente eficaz porque un paquete comprometido se distribuye automáticamente a miles de usuarios finales.
Los métodos más comunes son: typosquatting (publicar un paquete con un nombre casi idéntico al de uno popular), suplantación de cuenta (tomar el control de la cuenta de un mantenedor de confianza), confusión de dependencias (sobrescribir un paquete interno con uno público del mismo nombre) y compromiso del sistema de compilación (manipular el servidor de compilación o la canalización CI/CD).
El incidente de 3CX en 2023 mostró todo su alcance: los atacantes comprometieron una biblioteca upstream utilizada por 3CX. El código manipulado llegó al cliente de escritorio oficial de 3CX, usado por más de 600.000 empresas. La detección tardó semanas.
„Las cadenas de suministro de software son el eslabón más débil en la ciberseguridad. Las empresas confían ciegamente en código que no han escrito ni revisado – y que a menudo es mantenido por personas individuales no remuneradas.»
– Brian Behlendorf, Director General, Open Source Security Foundation (2025)
SBOM, firmas y la Ley de Resiliencia Cibernética de la UE
Un Software Bill of Materials (SBOM) es un listado legible por máquina de todos los componentes de un software – incluyendo versiones, licencias y vulnerabilidades conocidas. Los dos estándares principales son SPDX (Linux Foundation) y CycloneDX (OWASP). Ambos son funcionalmente equivalentes y están soportados por las principales herramientas.
La Ley de Resiliencia Cibernética de la UE (CRA) hará obligatorios los SBOM a partir de 2027 para todos los productos digitales vendidos en la UE. Los fabricantes deberán gestionar activamente las vulnerabilidades, proporcionar actualizaciones de seguridad durante toda la vida útil del producto y entregar los SBOM a la ENISA. Esto afecta no solo a fabricantes de software, sino también a dispositivos IoT, sistemas de control industrial y productos de consumo conectados.
La firma de código y de artefactos complementa los SBOM: herramientas como Sigstore (Linux Foundation) permiten la firma criptográfica de artefactos de compilación e imágenes de contenedores – de forma gratuita y transparente. Así, cualquier usuario puede verificar que un artefacto proviene efectivamente de la canalización de compilación esperada y no ha sido manipulado.
Canalización DevSecOps: seguridad como parte del proceso de compilación
La seguridad en la cadena de suministro solo funciona si se integra en el proceso de desarrollo – no como auditoría posterior, sino como parte automatizada de la canalización CI/CD:
Escaneo de dependencias: herramientas como Snyk, Grype o Dependabot escanean automáticamente todas las dependencias directas y transitivas en busca de CVE conocidos en cada compilación. Las vulnerabilidades críticas bloquean la compilación – ningún merge sin corrección o aceptación de riesgo documentada.
Generación de SBOM: Syft (Anchore) o cdxgen generan automáticamente un SBOM en formato CycloneDX o SPDX en cada lanzamiento. El SBOM se almacena como artefacto de compilación y puede entregarse a clientes o autoridades reguladoras.
Seguridad en contenedores: las imágenes de contenedores son especialmente vulnerables – una imagen base típica contiene cientos de paquetes, muchos con vulnerabilidades conocidas. Trivy o Grype escanan imágenes antes del despliegue. Imágenes Distroless (Google) o Chainguard reducen radicalmente la superficie de ataque.
Firma de artefactos: cada artefacto de compilación se firma con Sigstore/Cosign. Los clústeres de Kubernetes pueden aceptar solo imágenes firmadas mediante políticas (por ejemplo, Kyverno, OPA Gatekeeper) – los despliegues sin firma se bloquean automáticamente.
El esfuerzo de integración es manejable: en una canalización existente de GitHub Actions o GitLab-CI, los pasos adicionales pueden implementarse en un día. Las herramientas son de código abierto y gratuitas.
Datos clave de un vistazo
Preguntas frecuentes
¿Qué es un SBOM?
Un Software Bill of Materials (SBOM) es un listado legible por máquina de todos los componentes de un software – bibliotecas, frameworks, dependencias – incluyendo números de versión, licencias y vulnerabilidades conocidas. Equivalente a una lista de ingredientes para software.
¿Qué formato de SBOM debería usar?
CycloneDX (OWASP) y SPDX (Linux Foundation) son los dos estándares consolidados. CycloneDX tiene mejor integración con vulnerabilidades, SPDX es más fuerte en análisis de licencias. Para enfoque en seguridad se recomienda CycloneDX, para enfoque en cumplimiento, SPDX. La mayoría de herramientas soportan ambos.
¿Cuándo entra en vigor la Ley de Resiliencia Cibernética de la UE?
El CRA fue aprobado en 2024. Los fabricantes tienen un periodo de transición hasta 2027 para adaptar sus productos. A partir de entonces, todos los productos digitales en la UE deberán entregarse con SBOM, gestión activa de vulnerabilidades y actualizaciones de seguridad.
¿Cómo empiezo con la seguridad en la cadena de suministro?
Tres medidas inmediatas: 1) Integrar escaneo de dependencias en la CI/CD (Snyk, Dependabot – disponibles niveles gratuitos). 2) Automatizar la generación de SBOM (Syft, cdxgen). 3) Escanear imágenes de contenedores con Trivy. Todo junto puede implementarse en un día.
¿Qué es Sigstore?
Sigstore es un proyecto de código abierto de la Linux Foundation para la firma criptográfica de artefactos de software. Permite a los desarrolladores firmar código, imágenes de contenedores y otros artefactos de forma gratuita – sin necesidad de infraestructura PKI propia. Las firmas son transparentes y verificables públicamente.
¿Son los componentes de código abierto más inseguros que los propietarios?
No necesariamente – pero son más visibles para los atacantes. El código es público, lo que ayuda tanto a atacantes como a defensores. El principal riesgo reside en proyectos descuidados con mantenedores individuales. Herramientas como OpenSSF Scorecard evalúan automáticamente la madurez en seguridad de proyectos de código abierto.
Más artículos sobre el tema
→ EU Cyber Resilience Act: Qué les espera a los fabricantes
→ Passkeys 2025: Guía para su implementación empresarial
Lectura recomendada en la red
Cloud & DevOps: Buenas prácticas de seguridad en contenedores (CloudMagazin)
Desarrollo de software: DevSecOps: Seguridad en el desarrollo de software (MBF)
Fuente de imagen: Pexels / cottonbro studio
