12 de septiembre de 2026

SOCaaS

Centro de Operaciones de Seguridad como servicio

Construyendo un mejor SBOM



El software es una parte fundamental de todos los negocios en 2023. Y ya sea que lo esté creando o implementando, es absolutamente fundamental que sepa más sobre las vulnerabilidades en su cadena de suministro de software que los posibles atacantes.

El beneficio futuro de Listas de materiales de software (SBOM) depende de su capacidad para cumplir con los estándares, abordar todo el código base y habilitar la interoperabilidad a nivel empresarial, algo que nuestra industria ha luchado por lograr de manera unificada.

generar uno SBOM es relativamente fácil. Sin embargo, puede ser difícil crear un SBOM completo y preciso que se ajuste a las especificaciones estándar y permita a las organizaciones interactuar con ellas a escala. Por esta razón, acuñé el término «Full Monty SBOM» para describir una solución integral de SBOM que brinda el contenido y la interoperabilidad necesarios para su uso futuro con fines operativos, legales y de seguridad. A SBOM que carece de esta integridad podría dar como resultado una seguridad no válida o suposiciones operativas.

Estandarización

Para que los SBOM se intercambien universalmente y se lean automáticamente, su formato de intercambio debe cumplir con una especificación estándar.

Los dos estándares en los que se está enfocando la industria son SPDX y CycloneDX. El objetivo de estos estándares es establecer consistencia en la salida para que cuando se utilicen dos herramientas de generación de SBOM diferentes para crear un SBOM del mismo software, produzcan los mismos resultados. Estos formatos se pueden personalizar para incluir, excluir o asociar información específica, como licencias, derechos de autor y vulnerabilidades, según el caso de uso y la industria.

Es importante tener en cuenta que SPDX y CycloneDX son solo estándares que describen la estructura de un archivo SBOM. No se preocupan por la exactitud o la integridad. Si su herramienta o proceso de generación de SBOM inyecta basura en el archivo, se generará basura (bien formateada).

lo completo

En casi todas las aplicaciones de software, la mayor superficie de ataque son los componentes de código abierto. Estos forman uno un promedio del 76% de una aplicación de software y son desarrollados por personas de todo el mundo. log4j es un ejemplo de cómo una sola vulnerabilidad en un solo componente de código abierto puede tener un impacto global masivo. Para la mayoría de las organizaciones, una de las principales prioridades para proteger su cadena de suministro de software y su infraestructura de información es identificar y remediar rápidamente las vulnerabilidades en el software de código abierto.

Hay una reacción instintiva de muchos de que un SBOM es solo uno Software de código abierto (OSS) Inventario. La mayoría de los proveedores de análisis de composición de software (SCA) crean algún tipo de SBOM que enumera los componentes de OSS con diferentes niveles de dependencias transitivas. Sin embargo, un SBOM de OSS puro puede exponer a una empresa a vulnerabilidades en otros tipos de código que componen su cadena de suministro de software.

Pero un SBOM completo, o Monty completo, revela todas las partes de una aplicación, incluido el código personalizado, los componentes de código abierto y los componentes de terceros que no son OSS. Debido a que las vulnerabilidades pueden provenir de todo tipo de código, no solo de código abierto, esto es fundamental.

interoperabilidad

Los SBOM son documentos estáticos. Por lo tanto, tener uno de un proveedor de software tiene un valor limitado si todo lo que puede hacer es inspeccionarlo. El valor real radica en su capacidad para hacer algo con él, es decir, su interoperabilidad, e integrarlo con otros procesos de gestión de riesgos del ciclo de vida, como: B. Gestión de parches y evaluaciones de riesgo de implementación, todo a nivel empresarial.

Veamos tres cosas generales que los equipos pueden hacer con un SBOM interoperable: fusionar, consultar y monitorear.

  • unir: Los fabricantes de automóviles a menudo necesitan consolidar múltiples SBOM creados por múltiples proveedores de software diferentes que utilizan diferentes formatos estándar en un solo sistema SBOM.
  • Consulta: Si hay una nueva vulnerabilidad de día cero en un componente de software ampliamente implementado, debe consultar todos sus SBOM para determinar cuál de sus muchas aplicaciones de software contiene ese componente de software vulnerable específico. Esto puede ser técnicamente desalentador cuando tiene miles de aplicaciones que deben inspeccionarse en busca de alrededor de 60 CVE nuevos por día. La capacidad de consultar miles de SBOM desde una única interfaz es un elemento clave de la interoperabilidad y la gestión eficaz de riesgos de software.
  • Monitor: Con los SBOM diseñados para ser interoperables, los equipos pueden integrarlos con inteligencia de amenazas y sistemas de gestión de vulnerabilidades para que cuando surja una nueva vulnerabilidad de día cero, puedan escanear automáticamente todos sus SBOM existentes en busca de esa vulnerabilidad específica y notificar el ciclo de vida de su producto -Gestión del ciclo sistema de riesgo.

Sin bala de plata

Si bien un Monty SBOM completo es increíblemente importante, es solo una pequeña parte de la gestión de riesgos de la cadena de suministro de software (SSCRM). Otros factores incluyen garantizar que el código personalizado y el OSS estén libres de debilidades de seguridad y vulnerabilidades conocidas, que el software sea compatible y que la tubería de desarrollo sea segura y a prueba de manipulaciones. Espera que su cadena de suministro de alimentos no ponga en peligro su salud; Por ejemplo, no comería galletas que contienen ingredientes desconocidos y están hechas en una fábrica que está sujeta a contaminación cruzada y viola las normas de salud. Usted también necesita la seguridad de que su cadena de suministro de software es segura para su negocio.

Ya sean cookies o software, garantizar que el producto sea seguro para consumir es el resultado de muchos procesos de seguridad y pruebas regulares realizadas durante la fabricación, no solo la presencia de un SBOM.



Este contenido de ciberseguridad nos ha llegado de: DarkReading

Puedes encontrar la noticia original en el enlace que sigue: https://www.darkreading.com/application-security/building-a-better-sbom

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *