Selección del SBOM adecuado para su empresa

Si está preguntando, «¿Qué es un SBOM?» tendrás que ponerte al día rápido. Una lista de materiales de software es la primera línea de defensa contra las vulnerabilidades de software que pueden estar al acecho, como puertas traseras desbloqueadas en su red, listas para dejar entrar a los piratas informáticos.

Un SBOM, como cualquier lista de materiales, enumera los componentes del producto terminado, por lo que, en caso de problemas, los desarrolladores pueden concentrarse en la causa y abordarla con la menor interrupción posible. Los SBOM son la piedra angular de la seguridad de la cadena de suministro, ya que permiten DevOps más seguros y una mejor inteligencia de amenazas para mantener redes más resistentes.

Dos años después de que una banda de ransomware obstaculizara las entregas de combustible de EE. UU. al atacar a un operador de oleoductos, los ataques a la cadena de suministro siguen siendo un motivo de irritación para los profesionales de la seguridad. A raíz del ataque y el descubrimiento de la vulnerabilidad Log4J, los SBOM se han generalizado a medida que los profesionales de la seguridad luchan por prevenir futuros ataques.

La ascendencia de los SBOM y la orientación federal

Los SBOM están teniendo un momento. Durante la reciente conferencia RSA, la Agencia de Seguridad de Infraestructura y Ciberseguridad (CISA) del gobierno federal publicó una guía sobre los diferentes tipos de SBOM disponibles y su uso.

CISA ha sido un promotor del uso de SBOM, particularmente desde Orden Ejecutiva 14028 y la Oficina de Gerencia y Presupuesto nota M-22-18 que requirió el desarrollo de un formulario de informes para los desarrolladores de software que prestan servicios al gobierno federal. CISA tiene SBOM-a-Rama reuniones que reúnen a tipos de industrias para apoyar el desarrollo de CBOM.

El documento CISA fue el resultado de un esfuerzo grupal que comenzó en 2018 y, como muchos esfuerzos grupales, puede volverse difícil de manejar. La introducción del documento reconoce tanto, afirmando: «Dadas las diferentes formas en que se pueden recopilar los datos SBOM, los resultados de la herramienta pueden variar y proporcionar valor en diferentes casos de uso». Con eso en mente, vale la pena desglosar los tipos de SBOM disponibles y algunos posibles casos de uso para ayudar a aclarar cuál puede ser más útil para una organización.

Decodificación de los 6 tipos principales de SBOM

Hay seis tipos principales de SBOM en uso hoy en día a medida que avanzan a lo largo de las etapas del ciclo de vida del desarrollo de software:

• • Diseño: Un SBOM de este tipo se crea para software prospectivo o planificado e incluye componentes que pueden o no existir. Por lo general, se desarrolla en base a una RFP, concepto o especificaciones. Si bien es teóricamente posible, es difícil imaginar cómo podría ayudar esto y cómo podría generar un documento legible por máquina que cumpliera con los normas el gobierno federal está respaldando.

  Un posible caso de uso para este tipo de SBOM es alertar a los desarrolladores sobre problemas de licencia que podrían surgir al considerar el uso de ciertos componentes que afectarían la propiedad intelectual o la distribución del producto terminado. Este SBOM puede ayudar al equipo de desarrollo a identificar elementos incompatibles antes de comprarlos y definir una lista de componentes aprobados y recomendados. Este tipo de SBOM también puede permitir que el equipo obtenga los mejores componentes de código abierto desde una perspectiva comercial.

• • Fuente: Muy similar al SBOM de tipo compilación, este se genera en el entorno de desarrollo e incluye todos los archivos fuente y las dependencias necesarias para compilar un artefacto, pero excluye la herramienta de compilación del proceso. Por lo general, lo produce la herramienta de análisis de composición de software (SCA), con algunas aclaraciones agregadas manualmente.

  Es difícil ver el caso de uso para este tipo en lugar del SBOM de tipo de compilación más común. Aún así, este SBOM puede detectar componentes vulnerables que nunca se ejecutan después de la implementación, lo que le brinda al equipo una vista del árbol de dependencia de los componentes incluidos. Por lo tanto, permite la reparación de vulnerabilidades conocidas en la fuente al principio del proceso de desarrollo.

  En el lado negativo, puede carecer de algunos de los detalles de otros tipos de SBOM, incluido el tiempo de ejecución, el complemento o los componentes dinámicos, como las bibliotecas del servidor de aplicaciones.




ANUNCIO



• • Construir: El tipo de SBOM más utilizado, es un inventario más completo generado como parte del proceso de creación del software que ejecutará el artefacto final. Este enfoque utiliza datos como archivos de origen, dependencias, componentes construidos, datos efímeros del proceso de construcción y SBOM anteriores de diseño y origen. Se basa en resolver todas las dependencias en el sistema de compilación y escanearlas en la máquina de compilación.

  Debido a que se escanean los archivos reales, este tipo de SBOM crea un registro más completo con datos enriquecidos sobre cada archivo, como su hash y fuente. Proporcionar más visibilidad más allá de lo que está disponible en el código fuente genera confianza en que el SBOM representa con precisión el proceso de desarrollo. Esta confianza surge de la integración del SBOM y el producto terminado en el mismo flujo de trabajo.

  La desventaja es que este SBOM depende mucho del entorno de construcción, que a veces puede necesitar cambios para producir el SBOM.

• • Analizado: Esto a veces se denomina «SBOM de terceros» o SCA binario. Se basa en escanear el artefacto tal como se entrega para determinar sus componentes; y utiliza herramientas de terceros para analizar artefactos como paquetes, contenedores e imágenes de máquinas virtuales. No necesita acceso al entorno de compilación y puede verificar dos veces los datos de SBOM de otras fuentes para encontrar dependencias ocultas que las herramientas de creación de SBOM no detectaron.

  Dado que esencialmente realiza ingeniería inversa de los componentes del artefacto, puede ser una herramienta útil para los consumidores de software que no tienen un SBOM disponible o que pueden corroborar un SBOM existente.

  En el lado negativo, este tipo de SBOM a menudo se basa en heurísticas más flexibles o factores de riesgo basados ​​en el contexto para probar los componentes. Por lo tanto, las pruebas pueden producir algunos resultados falsos positivos. Pero también es más probable encontrar bibliotecas vinculadas desde el entorno sin que el equipo de desarrollo se dé cuenta, como OpenSSL libc u otras que compilan SBOM a menudo pasan por alto.





• • Desplegada: Como sugiere su nombre, se trata de un inventario del software desplegado en el sistema, generalmente generado mediante la compilación de los SBOM y la información de configuración de los artefactos instalados. Puede combinar el análisis de las opciones de configuración y el examen del comportamiento de ejecución en un entorno implementado. Es útil examinar los componentes de software, incluidas otras configuraciones y componentes del sistema que ejecutan una aplicación.

  La generación de este tipo de SBOM puede requerir cambios en los procesos de instalación e implementación, y es posible que no siempre refleje el entorno de tiempo de ejecución del artefacto, ya que es posible que no se pueda acceder a algunos componentes. Pero el amplio alcance de este tipo de SBOM lo convierte en una opción atractiva.

• • Tiempo de ejecución: A veces llamado SBOM «instrumentado» o «dinámico», este tipo resuelve el punto ciego en los SBOM desplegados. En este caso, las herramientas interactúan con el sistema y registran los artefactos utilizados en un entorno en ejecución y los que se cargan en la memoria durante la ejecución. Este proceso ayuda a evitar falsos positivos de componentes no utilizados.

  Este tipo de SBOM brinda a los desarrolladores visibilidad de los componentes cargados dinámicamente y las conexiones externas y puede brindarles detalles sobre qué componentes están activos y qué partes están en uso. Se suma a la sobrecarga de la red porque el sistema debe analizarse mientras se ejecuta. Debido a que tiene que estar ejecutándose durante algún tiempo para usar su funcionalidad completa, puede llevar algún tiempo recopilar información detallada.

Reflexiones finales sobre la selección de SBOM

Teniendo en cuenta estos detalles, seleccionar el tipo o combinación correctos de SBOM para satisfacer las necesidades de su organización implica más consideración que simplemente optar por la primera herramienta de generación de SBOM disponible para fines de cumplimiento.

Dado el apoyo del gobierno federal, el SBOM sin duda llegó para quedarse y puede establecer una base sólida, introduciendo orden en el proceso ocasionalmente caótico de asegurar los productos de software.