Mantenimiento de la SBOM entre versiones del producto
Sytance · Actualizado
La SBOM debe mantenerse vinculada a la versión de software que describe. Una actualización de software puede cambiar los componentes, mientras que una corrección de la SBOM quizá solo corrija información sobre una versión sin cambios. Registrar ambas versiones permite determinar qué recibieron los clientes y qué inventario la describe con precisión.
El software que describe cada inventario
Elija un punto repetible del proceso de compilación o publicación para generar la SBOM. Conserve la revisión del código fuente, las dependencias resueltas, la configuración de compilación y la identidad del artefacto final necesarias para reproducir o investigar el inventario.
La guía de CycloneDX distingue los inventarios generados a partir del código fuente, durante una compilación y durante la operación. Estas etapas pueden contener software distinto. Indicar la etapa permite al destinatario saber si la SBOM describe dependencias declaradas, un resultado de compilación o software desplegado.
En el caso de una pasarela, combine la información de la compilación de la aplicación, la imagen base y los componentes de firmware suministrados. Mantenga el vínculo con la SBOM de cada proveedor. Un servicio en la nube utilizado por la pasarela puede necesitar un inventario independiente y su propio ciclo de publicación.
Cambios de componentes entre versiones
La comparación entre versiones muestra qué componentes se añadieron, eliminaron, actualizaron o reconstruyeron, junto con los cambios en las rutas de dependencia. El recuento de componentes por sí solo puede pasar por alto una sustitución: se puede eliminar una biblioteca y añadir otra sin cambiar el total.
Utilice identidades normalizadas para la comparación y conserve las versiones e identificadores originales. Si una herramienta empieza a reconocer paquetes que antes desconocía, distinga una mejor visibilidad de un cambio real en el software.
- Componentes añadidos o eliminados y sus rutas de dependencia ascendentes.
- Cambios de versión, parches posteriores y modificaciones de hashes de artefactos.
- Cambios en las declaraciones de licencia o en los productores de componentes.
- Nuevas lagunas, identificadores corregidos y revisiones de SBOM de proveedores.
Comprobaciones antes de la publicación
Valide el archivo con respecto a la versión del formato y, después, examine su significado. Confirme que se resuelven todas las referencias, que el producto raíz es la versión prevista y que el destinatario puede acceder a las SBOM de componentes vinculadas.
Realice comprobaciones de vulnerabilidades y licencias en la versión candidata y registre los resultados para esa versión. Un problema nuevo de alta prioridad requiere una decisión sobre su tratamiento. Revise una excepción antigua si han cambiado la versión del componente o las hipótesis operativas.
Archive juntos el artefacto aceptado, la SBOM, las referencias de compilación y el resultado de la revisión. Si se utilizan firmas, verifique la firma y confirme que corresponde al emisor esperado.
Correcciones de una SBOM existente
La guía conjunta sobre SBOM de 2026 pide una SBOM para cada versión o actualización del software y una SBOM revisada cuando se corrijan errores o se conozcan nuevos datos de componentes. También distingue entre información desconocida e información ocultada deliberadamente.
Por ejemplo, un proveedor corrige el productor de un componente, pero los bytes del firmware no cambian. Conserve la identidad del firmware, emita una nueva revisión de la SBOM, explique la corrección y archive el documento anterior. Así, los destinatarios pueden distinguir una corrección de datos de una actualización de software.
Publique la actualización por el canal de distribución acordado. Una página de destino estable puede señalar la revisión actual, mientras que los archivos inmutables conservan el historial. Confirme que los destinatarios pueden identificar qué revisión sustituye a una anterior.
Nuevas vulnerabilidades en versiones con soporte
Cuando se recibe un aviso, busque las identidades de los componentes en todas las versiones con soporte. Revise las compilaciones reales y el uso del producto antes de asignar un impacto. Mantenga el inventario de componentes separado de la evaluación de vulnerabilidades para poder reevaluar la misma SBOM cuando aparezca nueva información.
Si la versión 1.0 de una pasarela contiene una biblioteca afectada y la versión 1.1 la elimina, la nueva versión no cambia la composición de los dispositivos 1.0 ya instalados. El equipo sigue necesitando una respuesta para esos dispositivos y un registro preciso de las versiones cubiertas por un aviso o una declaración VEX.
Acuerde quién mantiene las actualizaciones de proveedores, quién evalúa el impacto, quién aprueba una respuesta y quién la comunica. Defina el calendario de revisión según las obligaciones de soporte del producto y la gravedad de la nueva información, en vez de depender únicamente de la siguiente versión programada.
Conservación de registros y traspaso
Al finalizar el soporte, conserve la correspondencia entre versiones y SBOM, así como las decisiones necesarias para explicar las entregas históricas. Restrinja los registros sensibles cuando corresponda y, a la vez, permita que los destinatarios autorizados obtengan la información que se les prometió.
Durante el traspaso, quien asuma el mantenimiento debe poder encontrar el inventario de una versión del producto, localizar un componente y consultar la evaluación de impacto más reciente. Revisar una versión con soporte ayuda a identificar registros o permisos de acceso que falten.