{"id":14804,"date":"2026-08-04T01:01:36","date_gmt":"2026-08-04T08:01:36","guid":{"rendered":"https:\/\/omnitrust.com\/blog\/cbom-lens-emite-el-registro-criptografico-de-cyclonedx-1-7\/"},"modified":"2026-09-21T01:53:20","modified_gmt":"2026-09-21T08:53:20","slug":"cbom-lens-emite-el-registro-criptografico-de-cyclonedx-1-7","status":"publish","type":"post","link":"https:\/\/omnitrust.com\/es\/blog\/cbom-lens-emite-el-registro-criptografico-de-cyclonedx-1-7\/","title":{"rendered":"CBOM Lens emite el registro criptogr\u00e1fico de CycloneDX 1.7"},"content":{"rendered":" \n

Resumen:<\/strong> CBOM Lens 1.1.0 emite el registro criptogr\u00e1fico de CycloneDX 1.7. Hasta donde sabemos, es el primer productor de CBOM que lo hace. Tambi\u00e9n incorpor\u00f3 un esc\u00e1ner del Registro de Windows y validaci\u00f3n de esquemas completamente sin conexi\u00f3n.<\/p> \n\r\n

\u00a0<\/div>\r\n\r\n
\n

En una enumeraci\u00f3n cerrada, un solo valor incorrecto invalida todo el documento. Por eso CBOM Lens omite lo que no puede demostrar en lugar de adivinar para aparentar estar completo.<\/p> \n<\/div>\r\n\r\n

\u00a0<\/div>\r\n \n

Una lista de materiales criptogr\u00e1ficos solo es \u00fatil si es fiable. Supongamos que el inventario informa de una curva cuando un servicio utiliza en realidad otra. Entonces cualquier plan de migraci\u00f3n construido sobre ese inventario ser\u00e1 incorrecto. Por eso la pregunta interesante sobre una herramienta CBOM no es cu\u00e1nto informa, sino c\u00f3mo se comporta cuando no sabe algo.<\/p> \n \n

CycloneDX 1.7 hizo esa pregunta m\u00e1s exigente. CycloneDX<\/a> a\u00f1adi\u00f3 dos campos respaldados por registro a algorithmProperties<\/code>: algorithmFamily<\/code> y ellipticCurve<\/code>. Ambos son enumeraciones cerradas: 93 familias y 246 curvas. Por consiguiente, un valor fuera del vocabulario no degrada el documento; lo invalida.<\/p> \n \n

CBOM Lens<\/a> 1.1.0 escribe ambos campos. Hasta donde hemos podido determinar, es el primer productor de CBOM que emite el registro criptogr\u00e1fico de 1.7. La evidencia de esa afirmaci\u00f3n est\u00e1 en el ap\u00e9ndice de adopci\u00f3n del registro del repositorio, junto con el m\u00e9todo para refutarla. Y si encuentra un productor anterior, queremos saberlo.<\/p> \n\r\n

\u00a0<\/div>\r\n \n

Por qu\u00e9 el registro cambia la disciplina<\/h2> \n \n

Antes de 1.7, la familia y la curva de un algoritmo eran texto libre. Un productor pod\u00eda escribir cualquier cosa y seguir siendo v\u00e1lido seg\u00fan el esquema. Eso facilitaba generar documentos, pero dificultaba compararlos. Por ejemplo, dos herramientas pod\u00edan describir la misma clave de tres maneras distintas.<\/p> \n \n

Los campos respaldados por registro resuelven el problema de comparaci\u00f3n. Sin embargo, tambi\u00e9n aumentan el costo de equivocarse. Un productor que transfiera directamente una cadena escaneada terminar\u00e1 emitiendo un valor fuera del vocabulario. Como consecuencia, todo el documento fallar\u00e1 la validaci\u00f3n.<\/p> \n \n

Por eso CBOM Lens asigna los valores mediante tablas completas y omite el campo si no hay coincidencia. Nada se transfiere sin comprobar. En la pr\u00e1ctica, algunos campos quedan vac\u00edos donde una herramienta menos cuidadosa mostrar\u00eda un valor. Aun as\u00ed, consideramos que es la decisi\u00f3n correcta.<\/p> \n \n

El ejemplo m\u00e1s claro son las curvas que solo podr\u00edan inferirse. Pensemos en una curva deducida a partir del resumen de una firma o tomada de otro certificado en el mismo puerto. Ambas posibilidades son plausibles y ambas se dejan deliberadamente sin asignar. Las dos conjeturas son plausibles. Ninguna es evidencia.<\/p> \n\r\n

\u00a0<\/div>\r\n \n

Los algoritmos poscu\u00e1nticos se detectan, no se suponen<\/h2> \n \n

La misma disciplina rige los informes poscu\u00e1nticos. En concreto, es ah\u00ed donde las herramientas de inventario tienen mayor tentaci\u00f3n de exagerar.<\/p> \n \n

CBOM Lens reconoce seis familias a partir de sus identificadores de objeto. Son ML-DSA (FIPS 204), SLH-DSA (FIPS 205, los doce conjuntos de par\u00e1metros), ML-KEM (FIPS 203), XMSS, XMSS-MT y HSS-LMS. Cada una incluye tama\u00f1os de clave, tama\u00f1os de firma y categor\u00edas de seguridad de NIST transcritas de las normas. Adem\u00e1s, la cita se encuentra junto al valor en el c\u00f3digo fuente.<\/p> \n \n

Dos omisiones muestran que la regla funciona. Las firmas con estado basadas en hash no incluyen nivel de seguridad cu\u00e1ntica porque SP 800-208 no les asigna ninguno. Y HQC y FN-DSA no se declaran en absoluto porque todav\u00eda no se les ha asignado ning\u00fan identificador de objeto. Una herramienta que los informara de todos modos estar\u00eda inventando la detecci\u00f3n.<\/p> \n \n

\n
\n

Cuando no existe una fuente autorizada, el campo se omite en lugar de inventarse.<\/p> \n<\/blockquote> \n<\/figure> \n\r\n

\u00a0<\/div>\r\n \n

Qu\u00e9 m\u00e1s lleg\u00f3 en 1.1.0<\/h2> \n \n

Otros dos cambios son importantes desde el punto de vista operativo.<\/p> \n \n

Primero, un esc\u00e1ner del Registro de Windows. Los esc\u00e1neres de sistema de archivos, contenedores y red ya cubr\u00edan bien un entorno Linux. Sin embargo, la configuraci\u00f3n criptogr\u00e1fica de Windows suele residir en el registro en lugar de en archivos. Escanearlo cierra una brecha real de visibilidad en entornos mixtos.<\/p> \n \n

Segundo, la validaci\u00f3n es ahora completamente sin conexi\u00f3n y estricta. Los subesquemas SPDX y JSF est\u00e1n integrados, por lo que un documento se valida sin acceso a la red. Esto importa para escaneos en redes aisladas. Tambi\u00e9n elimina un modo de fallo en el que la validaci\u00f3n se degradaba silenciosamente porque un esquema remoto no era accesible.<\/p> \n \n

\n \n \n \n \n \n \n \n \n \n
Capacidad<\/th> \nDetalle<\/th> \n<\/tr> \n<\/thead> \n
Objetivos de escaneo<\/td> \nSistema de archivos, im\u00e1genes de contenedor de Docker o Podman, puertos de red mediante nmap con detecci\u00f3n de TLS y SSH, y ahora el Registro de Windows<\/td> \n<\/tr> \n
Salida<\/td> \nCycloneDX CBOM 1.6 o 1.7; 1.6 sigue siendo el formato predeterminado y de compatibilidad<\/td> \n<\/tr> \n
Correlaci\u00f3n<\/td> \nIdentificadores bom-ref<\/code> basados en contenido, para que el mismo activo coincida entre distintas fuentes<\/td> \n<\/tr> \n
Modos de funcionamiento<\/td> \nEjecuciones manuales puntuales, modo temporizador con cron o duraciones ISO-8601, y descubrimiento gestionado por ILM Core<\/td> \n<\/tr> \n
Destino<\/td> \nCarga opcional a un Repositorio CBOM o consumo por otra aplicaci\u00f3n<\/td> \n<\/tr> \n<\/tbody> \n<\/table> \n
Capacidades de CBOM Lens a partir de la versi\u00f3n 1.1.0.<\/figcaption> \n<\/figure> \n \n

Seleccionar 1.7 es un cambio de configuraci\u00f3n: establezca la versi\u00f3n de CBOM en 1.7<\/code>. Como 1.6 sigue siendo la predeterminada, actualizar la herramienta no cambia su formato de salida hasta que usted lo indique.<\/p> \n\r\n

\u00a0<\/div>\r\n \n

D\u00f3nde encaja esto con ILM<\/h2> \n \n

CBOM Lens produce inventario. Un Repositorio CBOM lo almacena y permite buscarlo. ILM lo consume. Porque un inventario solo se vuelve accionable junto a los certificados y claves que describe.<\/p> \n \n

Ambas herramientas son de c\u00f3digo abierto y ambas funcionan de forma independiente. Ejecute CBOM Lens por s\u00ed solo, ap\u00fantelo a un repositorio y no utilice nunca el resto de la plataforma. Aun as\u00ed, es en la combinaci\u00f3n donde el inventario deja de ser un informe y empieza a impulsar decisiones.<\/p> \n \n

Publicamos esto en parte para aumentar la visibilidad y en parte para invitar al escrutinio. El registro 1.7 es nuevo y su adopci\u00f3n es limitada. Adem\u00e1s, una enumeraci\u00f3n cerrada recompensa a las herramientas cuidadosas y castiga a las que muestran exceso de confianza. Si est\u00e1 creando un productor de CBOM, vale la pena debatir las tablas de asignaci\u00f3n y las reglas de omisi\u00f3n.<\/p> \n\r\n

\u00a0<\/div>\r\n
\r\n
\u00a0<\/div>\r\n\r\n
\n

Puntos clave<\/h3> \n\r\n\r\n \n