El Reglamento de Ciberresiliencia exige una lista de materiales de software, pero deja los detalles técnicos en manos de terceros. El Anexo I, Parte II, punto (1) requiere un SBOM legible por máquina que cubra al menos las dependencias de primer nivel del producto, y ahí termina, en términos generales, la especificidad del reglamento. Sin lista de campos. Sin versión mínima de formato. Sin esquema de avisos. La Oficina Federal Alemana de Seguridad de la Información (BSI, por sus siglas en alemán) ha llenado ese vacío con BSI TR-03183, una guía técnica en tres partes que nombra versiones de formato exactas, enumera todos los campos obligatorios y vincula la generación del SBOM con la publicación de avisos de vulnerabilidad. Trátala como la especificación práctica que subyace a la obligación legal, no como una regulación paralela.
Resumen
- BSI TR-03183 se publica en tres partes: Parte 1 (requisitos generales de ciberresiliencia del CRA), Parte 2 (SBOM) y Parte 3 (notificaciones e informes de vulnerabilidad). La Parte 2 v2.1.0 se publicó el 20 de agosto de 2025 y es la guía SBOM vigente.
- El §4 de la Parte 2 exige CycloneDX versión 1.6 o superior, o SPDX versión 3.0.1 o superior. Otros formatos no son conformes.
- La especificación organiza los campos de datos en tres categorías: Obligatorio (siempre requerido), Adicional (obligatorio cuando el dato existe) y Opcional. En la v2.1.0 no existen niveles denominados "Basic", "Standard" ni "Comprehensive".
- CSAF 2.0 es el formato recomendado para avisos de vulnerabilidad según el §8.1.14 de la Parte 2. El §4.2.8 de la Parte 3 exige la etiqueta
CSAF:en tusecurity.txtcuando publiques documentos CSAF. VEX nunca es obligatorio; solo se describe como un perfil CSAF. - El §1 de la Parte 1 indica que la guía quedará supersedida en cuanto el contenido quede cubierto por las normas armonizadas de CEN/CENELEC bajo el mandato de normalización del CRA. TR-03183 es el mejor sustituto disponible hasta que esas normas se publiquen.
- Los puntos de referencia de conformidad son: CycloneDX 1.6 como mínimo, hashes SHA-512 para cada componente desplegable, metadatos de creador y marca de tiempo a nivel de SBOM, y un flujo de avisos CSAF según la Parte 3.
Qué es BSI TR-03183
BSI es la agencia nacional de ciberseguridad de Alemania. Su Guía Técnica TR-03183 lleva el título completo Cyber Resilience Requirements for Manufacturers and Products, con partes numeradas y versionadas de forma independiente. La guía está dirigida a los fabricantes que se preparan para el Reglamento de Ciberresiliencia de la UE, y traduce las obligaciones del Anexo I del CRA en requisitos técnicos concretos y verificables.
Las tres partes del documento, con las versiones vigentes en el momento de redactar este artículo:
| Parte | Versión | Publicada | Alcance |
|---|---|---|---|
| Parte 1 | v0.10.0 | 2025-09-12 | Requisitos generales de ciberresiliencia del CRA, derivados del Anexo I, el Anexo II y el Anexo VII |
| Parte 2 | v2.1.0 | 2025-08-20 | Lista de materiales de software (SBOM): formatos, campos, generación y actualizaciones |
| Parte 3 | v1.0.0 | 2025-08-20 | Notificaciones e informes de vulnerabilidad, incluidas la divulgación coordinada de vulnerabilidades (CVD), security.txt y los avisos CSAF |
El §1 de la Parte 1 enmarca la guía como un artefacto transitorio:
"This Technical Guideline will be superseded in the current form as soon as its content is covered by the corresponding standardisation deliverables under the aforementioned standardisation request."
Esta oración determina cómo debes interpretar TR-03183. Es la lectura del BSI sobre cómo debería ser un programa de SBOM y vulnerabilidades conforme con el CRA mientras las normas armonizadas de CEN/CENELEC siguen en fase de borrador. Cuando esas normas lleguen, tendrán precedencia; hasta entonces, TR-03183 es la especificación más detallada disponible públicamente alineada con el Anexo I del CRA.
graph LR
A[BSI TR-03183]
A --- P1[Parte 1
Requisitos generales
de ciberresiliencia]
A --- P2[Parte 2
SBOM]
A --- P3[Parte 3
Informes de
vulnerabilidades]
P2 --- F1[CycloneDX 1.6
o SPDX 3.0.1]
P2 --- F2[Campos obligatorios, adicionales
y opcionales]
P3 --- C1[CSAF 2.0
avisos de seguridad]
P3 --- C2[security.txt
etiqueta CSAF]
style A fill:#008080,stroke:#005f5f,color:#fff
style P1 fill:#e8f4f8,stroke:#008080,color:#333
style P2 fill:#e8f4f8,stroke:#008080,color:#333
style P3 fill:#e8f4f8,stroke:#008080,color:#333
style F1 fill:#f8fafc,stroke:#008080,color:#333
style F2 fill:#f8fafc,stroke:#008080,color:#333
style C1 fill:#f8fafc,stroke:#008080,color:#333
style C2 fill:#f8fafc,stroke:#008080,color:#333
Los vacíos del CRA que TR-03183 rellena
Puedes leer las cláusulas del SBOM del CRA de principio a fin sin descubrir qué campos debe contener tu documento, qué versión de formato cumple la obligación, ni cómo publicar los avisos resultantes. TR-03183 rellena tres vacíos concretos.
| Vacío en el texto del CRA | Lo que especifica TR-03183 |
|---|---|
| El Anexo I, Parte II, punto (1) exige un SBOM pero no enumera campos de datos | El §5.2 de la Parte 2 enumera los campos Obligatorios, Adicionales y Opcionales tanto para el documento SBOM como para cada componente |
| El CRA dice que los formatos deben ser "de uso común y legibles por máquina" sin nombrar ninguno | El §4 de la Parte 2 establece: "CycloneDX, versión 1.6 o superior" o "System Package Data Exchange (SPDX), versión 3.0.1 o superior" |
| El artículo 14 exige notificar a ENISA las vulnerabilidades explotadas activamente sin especificar un formato de aviso público | El §4.2.8 y el §5.1.6 de la Parte 3 alinean los avisos con CSAF 2.0 y hacen referencia a ISO/IEC 20153:2025 |
Para conocer el detalle del CRA sobre esas obligaciones, consulta Requisitos SBOM del CRA. Para el contexto de plazos y sanciones que enmarca la urgencia, consulta Plazos de cumplimiento del SBOM y sanciones.
Campos obligatorios, adicionales y opcionales en la Parte 2
La v2.1.0 de la Parte 2 no usa las palabras "Basic", "Standard" ni "Comprehensive". Cualquier diagrama o resumen de un proveedor que presente tres "niveles de calidad" con esos nombres está introduciendo una estructura que la especificación no contiene. El modelo de conformidad en la v2.1.0 es binario a nivel de campo: un campo es Obligatorio (siempre presente), Adicional (obligatorio cuando el dato existe) u Opcional.
Las tres categorías, mapeadas a las secciones de la especificación:
| Categoría | Sección de la spec | Qué significa | Ejemplos |
|---|---|---|---|
| Obligatorio para el propio SBOM | §5.2.1 | Campos a nivel de documento que DEBEN estar siempre presentes | Creador del SBOM, marca de tiempo |
| Obligatorio para cada componente | §5.2.2 | Campos a nivel de componente que DEBEN estar siempre presentes | Nombre del componente, versión del componente, licencias de distribución, hash (SHA-512), dependencias de otros componentes, nombre de archivo, propiedad ejecutable, propiedad de archivo comprimido, propiedad estructurada, creador del componente |
| Adicional para cada componente | §5.2.4 | Obligatorio si el dato existe; se omite en caso contrario | URI del código fuente, URI de la forma desplegable del componente, otros identificadores únicos (CPE, purl), licencias originales |
| Opcional para cada componente | §5.2.5 | PUEDE incluirse | Licencia efectiva, hash del código fuente, URL del security.txt |
La Parte 2 también impone un requisito de resolución recursiva en el §5.1: la resolución de dependencias DEBE realizarse para cada componente incluido en el alcance de la entrega. Es la respuesta de la especificación al vago umbral de "dependencias de primer nivel" del CRA en el Anexo I, Parte II, punto (1): TR-03183 espera que recorras el árbol completo, no que te detengas en las dependencias inmediatas.
Resúmenes públicos anteriores (incluidos algunos en las propias comunicaciones antiguas del BSI) presentaban TR-03183 como si definiera tres niveles de calidad con esos nombres. La v2.1.0 no usa esa taxonomía. Si tu lista de comprobación de auditoría hace referencia a "Nivel 1", "nivel Comprehensive" o similar, está referenciando un modelo que ya no coincide con la especificación publicada. Actualiza a las categorías Obligatorio / Adicional / Opcional.
Requisitos campo a campo
El mapeo completo de los campos candidatos sobre los que más preguntan los equipos, frente a las secciones de la especificación v2.1.0.
| Campo | Categoría | Sección de la spec | Notas |
|---|---|---|---|
| Creador del SBOM | Obligatorio (nivel SBOM) | §5.2.1 | Email o URL del productor |
| Marca de tiempo | Obligatorio (nivel SBOM) | §5.2.1 | ISO 8601 |
| Nombre del componente | Obligatorio | §5.2.2 | Siempre presente en cada entrada |
| Versión del componente | Obligatorio | §5.2.2 | Versión exacta, no un rango |
| Creador del componente | Obligatorio | §5.2.2 | Equivale a "Supplier" en terminología anterior |
| Nombre de archivo del componente | Obligatorio | §5.2.2 | A menudo ausente en la salida por defecto de las herramientas |
| Dependencias de otros componentes | Obligatorio | §5.2.2 | Recursivo según el §5.1 |
| Licencias de distribución | Obligatorio | §5.2.2 | Licencias tal como se distribuyen |
| Hash del componente desplegable | Obligatorio | §5.2.2 | SHA-512 |
| Propiedad ejecutable | Obligatorio | §5.2.2 | Booleano: ¿es ejecutable el componente? |
| Propiedad de archivo comprimido | Obligatorio | §5.2.2 | Booleano: ¿es el componente un archivo comprimido? |
| Propiedad estructurada | Obligatorio | §5.2.2 | Booleano: indicador de carga útil estructurada |
| URI del código fuente | Adicional | §5.2.4 | Obligatorio cuando se conoce |
| URI del componente desplegable | Adicional | §5.2.4 | Obligatorio cuando se conoce |
| Otros identificadores únicos (CPE, purl) | Adicional | §5.2.4 | Obligatorio cuando está disponible; no es incondicionalmente requerido |
| Licencias originales | Adicional | §5.2.4 | Licencia upstream anterior a la distribución |
| Licencia efectiva | Opcional | §5.2.5 | Resultado de la conciliación de licencias |
| Hash del código fuente | Opcional | §5.2.5 | Hash del código fuente previo a la compilación |
URL del security.txt |
Opcional | §5.2.5 | Enlace al punto de entrada de divulgación de vulnerabilidades |
La fila que más sorprende a muchos equipos es Otros identificadores únicos (CPE, purl). Los equipos suelen tratar las package URL como la clave primaria de un SBOM. Bajo la Parte 2 de TR-03183 v2.1.0, purl queda en la categoría Adicional, obligatorio solo cuando el dato existe. El identificador de componente incondicional es el hash SHA-512 del artefacto desplegable, combinado con el nombre y la versión. Si tus herramientas no pueden calcular un purl para una biblioteca interna privada, eso no rompe la conformidad. Si no pueden calcular el SHA-512, sí lo hace. Consulta errores habituales en el SBOM para ver otros vacíos de campos relacionados.
Compatibilidad con CycloneDX y SPDX
El §4 de la Parte 2 nombra los formatos aceptados y las versiones mínimas:
"A newly generated or updated SBOM MUST be in JSON- or XML-format and a valid SBOM according to one of the following specifications in one of the specified versions: CycloneDX, version 1.6 or higher"
En español: un SBOM recién generado o actualizado DEBE estar en formato JSON o XML y ser un SBOM válido según una de las siguientes especificaciones en una de las versiones indicadas: CycloneDX, versión 1.6 o superior.
"System Package Data Exchange (SPDX), version 3.0.1 or higher"
En español: System Package Data Exchange (SPDX), versión 3.0.1 o superior.
Las notas de la versión v2.1.0 también documentan la ruta de actualización: la v2.0.0 (2024-09-20) elevó CycloneDX de la 1.4 a la 1.5 y SPDX de versiones anteriores a la 2.2.1. La v2.1.0 (2025-08-20) elevó CycloneDX de la 1.5 a la 1.6 y SPDX de la 2.2.1 a la 3.0.1.
La implicación práctica es que las herramientas que generan salidas CycloneDX 1.4 por defecto (todavía habituales en configuraciones CI antiguas) no son conformes con la v2.1.0. CycloneDX 1.6 introdujo soporte refinado para activos criptográficos y ML BOM; SPDX 3.0.1 es una revisión mayor con un nuevo modelo de carga útil. Tu línea de base de CI necesita un indicador explícito --spec-version 1.6 o equivalente. Para una comparación de los dos formatos y la madurez de las herramientas, consulta CycloneDX vs SPDX.
Un esqueleto CycloneDX 1.6 alineado con TR-03183, con los campos Obligatorios a nivel de documento completados:
{
"bomFormat": "CycloneDX",
"specVersion": "1.6",
"serialNumber": "urn:uuid:3e671687-395b-41f5-a30f-a58921a69b79",
"version": 1,
"metadata": {
"timestamp": "2027-01-15T10:00:00Z",
"tools": [
{ "vendor": "Example", "name": "syft", "version": "1.10.0" }
],
"authors": [
{ "name": "Example GmbH security team", "email": "security@example.de" }
],
"component": {
"type": "firmware",
"name": "SmartSensor Pro",
"version": "2.4.1",
"supplier": { "name": "Example GmbH", "url": ["https://example.de"] },
"purl": "pkg:firmware/example/smartsensor-pro@2.4.1"
}
},
"components": [
{
"type": "library",
"name": "openssl",
"version": "3.0.12",
"purl": "pkg:generic/openssl@3.0.12",
"licenses": [{ "license": { "id": "Apache-2.0" } }],
"hashes": [
{ "alg": "SHA-512", "content": "ddaf35a193617aba..." }
],
"supplier": { "name": "OpenSSL Software Foundation" },
"properties": [
{ "name": "executable", "value": "true" },
{ "name": "archive", "value": "false" }
]
}
],
"dependencies": [
{
"ref": "pkg:firmware/example/smartsensor-pro@2.4.1",
"dependsOn": ["pkg:generic/openssl@3.0.12"]
}
]
}
Las entradas authors, timestamp y hashes con SHA-512 son los campos Obligatorios a nivel de documento y de componente que con más frecuencia faltan en los valores por defecto de CI. Valídalos con cyclonedx-cli validate --input-version 1.6 antes de considerar una salida como conforme con TR-03183.
Cómo se relaciona TR-03183 con CSAF y VEX
TR-03183 divide la mecánica del SBOM y los avisos de vulnerabilidad entre la Parte 2 y la Parte 3. La regla principal es simple: CSAF es recomendado en la Parte 2 y operativamente obligatorio para la publicación del security.txt en la Parte 3. VEX nunca es obligatorio.
| Mecanismo | Ubicación en TR-03183 | Fuerza | Qué significa |
|---|---|---|---|
| CSAF 2.0 como formato de aviso | Parte 2 §8.1.14 | Recomendado | "El formato recomendado para distribuir información de vulnerabilidad es CSAF (incluyendo también VEX como perfil)" |
Etiqueta CSAF en security.txt |
Parte 3 §4.2.8 (b) | DEBE | La declaración en security.txt que hace referencia a documentos CSAF debe comenzar con la etiqueta CSAF: |
| URI de metadatos del proveedor | Parte 3 §4.2.8 (a) | DEBERÍA | El fabricante DEBERÍA proporcionar el URI del provider-metadata.json para los documentos CSAF |
| ISO/IEC 20153:2025 | Parte 3 §5.1.6 | Referencia | La forma de norma internacional de CSAF v2.0 |
| VEX | Parte 2 §1 y §8.1.14 | Informativo | VEX aparece como perfil CSAF y como uno de los varios canales "recomendados" para información de vulnerabilidad |
CSAF (Common Security Advisory Framework) versión 2.0 es una norma OASIS publicada el 18 de noviembre de 2022, con la Errata 01 emitida el 26 de enero de 2024. Define un esquema JSON para avisos de seguridad legibles por máquina. Los CERT alemanes (BSI-CERT, CERT-Bund) publican y consumen CSAF por defecto, y el editor Secvisogram junto con el validador OASIS CSAF son las herramientas estándar.
La conexión con el artículo 14 es más sutil de lo que algunos comentarios sugieren. El artículo 14 del CRA establece los plazos de notificación a ENISA y al CSIRT coordinador (24 horas para el aviso temprano, 72 horas para la notificación de vulnerabilidad y 14 días para el informe final). No especifica un formato de aviso público. La Parte 3 de TR-03183 llena ese vacío: una vez que has notificado a ENISA, el documento CSAF que publiques bajo tu security.txt es el artefacto operativo que los clientes consumen. Sin herramientas CSAF implantadas antes del 11 de septiembre de 2026, aún puedes satisfacer el artículo 14, pero no cumplirás el lenguaje de contratación y las expectativas del security.txt que derivan de TR-03183.
VEX merece una nota aparte. El §8.1.14 de la Parte 2 menciona VEX como perfil CSAF, y el §1 de la Parte 2 lo menciona como uno de los posibles canales para el "intercambio de información de vulnerabilidad". La Parte 3 no menciona VEX en absoluto. Desde la perspectiva del CRA, VEX es útil para declaraciones not_affected a nivel de componente que evitan la fatiga de alertas cuando un SBOM contiene una biblioteca con un CVE conocido que en realidad no es accesible desde tu código. No es una obligación de TR-03183. Úsalo donde aporte valor real.
¿Se aplica TR-03183 fuera de Alemania?
TR-03183 es una guía técnica nacional alemana emitida por BSI, no una regulación de toda la UE. Ninguna de sus tres partes afirma aplicabilidad fuera de Alemania. El §1 de la Parte 1 anticipa explícitamente ser supersedida por las normas armonizadas de CEN/CENELEC a medida que estas se publiquen bajo el mandato de normalización del CRA.
En la práctica, tres factores hacen que TR-03183 sea relevante para los fabricantes con sede fuera de Alemania.
En primer lugar, el mercado alemán es el más grande de la UE, y la contratación empresarial alemana hace referencia a TR-03183 de forma cada vez más explícita. Si vendes a un cliente alemán, espera encontrar el lenguaje de TR-03183 en sus cuestionarios de seguridad y contratos de proveedor.
En segundo lugar, no existe ninguna especificación alternativa alineada con el CRA con un nivel de detalle comparable en el momento de redactar este artículo. Las normas armonizadas de CEN/CENELEC bajo el mandato de normalización del CRA siguen en fase de borrador. TR-03183 es el mejor sustituto disponible.
En tercer lugar, la Parte 1 de TR-03183 se mapea explícitamente sobre el Anexo I, el Anexo II y el Anexo VII del CRA. Un fabricante que construya su documentación sobre TR-03183 producirá contenido del Anexo VII (en particular los SBOM de los puntos 2(b) y 8) que cualquier autoridad de vigilancia del mercado de la UE puede leer. Consulta Documentación técnica del Anexo VII para ver la lista completa de contenidos.
Implementar TR-03183 de forma voluntaria es una decisión de ingeniería justificable, pero no es un requisito legal fuera de Alemania. Si tus productos no incluyen un componente hardware, ahí termina la cuestión. Si lo incluyen, el mismo documento puede contener tus entradas HBOM junto a los componentes de software.
Preguntas frecuentes
¿Cuáles son los elementos mínimos de la NTIA?
Los Minimum Elements For a Software Bill of Materials (SBOM) de la NTIA, publicados el 12 de julio de 2021 por el Departamento de Comercio de EE. UU., definen una línea de base que la mayoría de los SBOM alineados con el CRA superan con holgura. Los siete campos de datos (Data Fields) son: nombre del proveedor, nombre del componente, versión del componente, otros identificadores únicos, relación de dependencia, autor de los datos del SBOM y marca de tiempo. El documento también define tres categorías de nivel superior: Campos de datos (Data Fields), Soporte de automatización (Automation Support) y Prácticas y procesos (Practices and Processes), que contiene "Incógnitas conocidas" (Known Unknowns) como subelemento, no como categoría de nivel superior. La Parte 2 de TR-03183 v2.1.0 añade hashing SHA-512, nombre de archivo y las propiedades Ejecutable, Archivo comprimido y Estructurada sobre los siete elementos de la NTIA, más la resolución de dependencias obligatoria según el §5.1. La conformidad con la NTIA por sí sola no satisface TR-03183.
¿Qué es CSAF 2.0?
CSAF (Common Security Advisory Framework) versión 2.0 es una norma OASIS publicada el 18 de noviembre de 2022, con la Errata 01 emitida el 26 de enero de 2024. Define un esquema JSON para avisos de seguridad legibles por máquina: qué versiones de producto están afectadas, cuáles están corregidas, qué mitigaciones existen y cómo deben responder los clientes. El §8.1.14 de la Parte 2 de TR-03183 recomienda CSAF para distribuir información de vulnerabilidad, y el §4.2.8 de la Parte 3 exige la etiqueta CSAF: en tu security.txt cuando publiques documentos CSAF. El §5.1.6 de la Parte 3 hace referencia a ISO/IEC 20153:2025, que estandariza CSAF 2.0. El editor Secvisogram y el validador OASIS CSAF son las herramientas estándar. Los CERT alemanes publican y consumen CSAF por defecto, por lo que para cualquier fabricante con clientes alemanes, CSAF es operativamente obligatorio, no opcional.
¿Necesito VEX para cada CVE?
No. TR-03183 no exige VEX. El §8.1.14 de la Parte 2 encuadra VEX como un perfil CSAF y trata ambos como un canal recomendado (no obligatorio) para información de vulnerabilidad. La Parte 3 no menciona VEX en absoluto. Desde la perspectiva del CRA, VEX es útil para declaraciones not_affected a nivel de componente que evitan la fatiga de alertas cuando un SBOM contiene una biblioteca con un CVE conocido que en realidad no es accesible desde tu código. CycloneDX 1.6 admite aserciones VEX en línea dentro del documento SBOM, por lo que no necesitas un archivo separado por cada CVE. Emitir VEX donde aporte claridad demuestra diligencia debida bajo el artículo 13(5) del CRA. Emitir VEX para cada CVE de tu SBOM no es una obligación de TR-03183 y raramente es un buen uso del tiempo de los analistas.
¿Se aplica TR-03183 fuera de Alemania?
Legalmente, no. TR-03183 es una guía técnica nacional alemana emitida por BSI, y ninguna de las Partes 1, 2 o 3 afirma aplicabilidad fuera de Alemania. El §1 de la Parte 1 indica explícitamente que la guía quedará supersedida en cuanto las normas armonizadas de CEN/CENELEC bajo el mandato de normalización del CRA sean publicadas. En la práctica, tres factores la hacen relevante en toda la UE: el mercado alemán es el más grande de la UE, el lenguaje de contratación alemán hace referencia a TR-03183 directamente, y no existe ninguna especificación alternativa alineada con el CRA con un detalle comparable en este momento. Implementar TR-03183 de forma voluntaria es una decisión de ingeniería justificable, pero no es un requisito legal fuera de Alemania. Trátala como el mejor sustituto disponible de las normas armonizadas del CRA que aún no han llegado.