El Reglamento de Ciberresiliencia de la UE — el Cyber Resilience Act (Reglamento (UE) 2024/2847) — entró en vigor en diciembre de 2024, y la mayoría de las hojas de ruta lo archivaron como un «problema de 2027»: todos los requisitos — secure-by-design, evaluación de la conformidad, marcado CE, un SBOM obligatorio y actualizaciones de seguridad durante todo el período de soporte — se aplican desde el 11 de diciembre de 2027. Pero hay una fecha anterior que es fácil pasar por alto, y es la que convierte el SBOM de una línea en la hoja de ruta en una necesidad operativa.
La fecha límite real es el 11 de septiembre de 2026
Las obligaciones de notificación entran en vigor el 11 de septiembre de 2026. Un fabricante de un producto con elementos digitales debe notificar las vulnerabilidades explotadas activamente y los incidentes graves: una alerta temprana a ENISA en un plazo de 24 horas, una notificación completa en 72 horas y un informe final a más tardar 14 días después de que haya una corrección disponible. Formalmente, el SBOM aún no es obligatorio en ese momento. Pero observe la mecánica: llega un aviso sobre una CVE explotada en una biblioteca popular y dispone de un día para determinar si uno solo de sus productos está afectado. Sin un inventario de componentes legible por máquina eso no es una tarea de 24 horas, sino pánico con grep por los repositorios. Notificar sin un SBOM es físicamente imposible, y por eso la fecha límite real para un inventario no es diciembre de 2027, sino septiembre de 2026.
Qué exige realmente el CRA de un SBOM
En torno al requisito han crecido dos mitos, y ambos son caros. El primero: «habrá que publicar el SBOM». No: el CRA (Anexo I, Parte II) coloca el SBOM en la documentación técnica, y solo se divulga a las autoridades de vigilancia del mercado mediante solicitud motivada. Es un artefacto de cumplimiento para el regulador, no un documento de marketing en el sitio web. El segundo mito: «hay que enumerar todo hasta la última dependencia transitiva». La ley exige el mínimo — las dependencias de primer nivel en un formato legible por máquina de uso común. Enumerar los subcomponentes anidados es buena ingeniería y la base de un verdadero seguimiento de vulnerabilidades, pero la profundidad es decisión suya, no la letra del reglamento.
La conclusión práctica: el formato es SPDX (ISO 5962) o CycloneDX (OWASP), ambos legibles por máquina y aceptados por la industria. CycloneDX se inclina hacia los escenarios de seguridad (incluye un modelo de vulnerabilidades y VEX), SPDX hacia la licencia y lo legal. La generación en sí es la parte resuelta: syft o trivy producen un SBOM a partir de una imagen con un solo comando.
Generar el SBOM es el 20% del trabajo
La tentación de cerrar la tarea con una sola línea en CI engaña. syft image:tag -o spdx-json es el 20% fácil. El 80% restante es operativo:
- Almacenamiento y vinculación. Un SBOM que queda como artefacto del job de CI es indescubrible desde el despliegue. Vincúlelo a la imagen como una attestation firmada (
cosign attest --type spdxjson) o llévelo de forma centralizada en Dependency-Track / GUAC. - Escaneo continuo. Un SBOM fija la composición en el momento de la compilación; las vulnerabilidades se divulgan después. Vuelva a escanear los SBOM almacenados (Grype, Trivy) de forma programada, no solo durante la compilación — así encontrará el producto afectado en 24 horas.
- VEX contra el ruido. Sin un Vulnerability Exploitability eXchange el backlog de seguridad se ahoga en falsos positivos, y la única CVE realmente explotada se pierde entre cientos de inaplicables. La anotación «no afectado porque el código no está en la ruta de ejecución» es lo que hace viable el informe de 24 horas.
Un SBOM es «qué hay dentro», pero el CRA también mira «cómo se construyó»
Un SBOM responde a la pregunta «de qué está construido el artefacto». Los requisitos de secure-by-design y resistencia a la manipulación empujan hacia una segunda pregunta — «cómo se construyó». Aquí actúa la provenance al estilo SLSA: una cadena verificable desde el commit hasta la imagen (quién, en qué commit, en qué builder, firmado con qué). SBOM y provenance se complementan — juntos aportan la transparencia de la cadena de suministro para la que se concibió el CRA. La buena noticia: OpenSSF y los reguladores avanzan hacia la unificación de los estándares de SBOM, de modo que invertir en el stack de la CNCF (Syft/Grype, Cosign, Sigstore) no es trabajo para el cajón, sino una apuesta alineada con la dirección común.
Qué hacer antes de septiembre de 2026
Reduzca la tarea a cuatro puntos verificables hoy. Primero, generación de SBOM en cada compilación como etapa obligatoria del pipeline, en formato CycloneDX o SPDX. Segundo, almacenamiento y attestation, para que el SBOM sea descubrible desde el despliegue y no muera en CI. Tercero, reescaneo continuo de los SBOM almacenados más VEX, para separar lo explotable del ruido. Cuarto, el proceso organizativo: quién recibe la señal sobre una CVE explotada activamente, quién comprueba la exposición en 24 horas y quién pulsa el botón de notificación en ENISA. Los tres primeros son herramientas que se montan en un sprint. El cuarto es un runbook, y suele ser el que se rezaga. Queda menos tiempo antes de septiembre de 2026 del que parece: «tenemos un SBOM» y «con el SBOM respondemos al regulador en un día» son niveles de preparación distintos.