Seleccionar el SBOM adecuado para su empresa

Si pregunta: "¿Qué es un SBOM?" tendrás que ponerte al día rápidamente. Una lista de materiales de software es la primera línea de defensa contra las vulnerabilidades de software que pueden acechar, 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, de modo que, en caso de problema, los desarrolladores puedan 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 sobre amenazas para mantener redes más resilientes.

Dos años después de que una banda de ransomware obstaculizara las entregas de combustible en Estados Unidos al atacar a un operador de oleoductos, los ataques a la cadena de suministro siguen siendo un importante 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 mientras los profesionales de la seguridad luchan por prevenir futuros ataques.

La supremacía de las 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 promovido el uso de SBOM, particularmente desde que la Orden Ejecutiva 14028 y el memorando M-22-18 de la Oficina de Administración y Presupuesto requirieron el desarrollo de un formulario de informes para los desarrolladores de software que prestan servicios al gobierno federal. CISA celebra reuniones SBOM-a-Rama que reúnen tipos de industrias para apoyar el desarrollo de CBOM.

El documento CISA fue el resultado de un esfuerzo grupal iniciado en 2018 y, como muchos esfuerzos grupales, puede volverse difícil de manejar. La introducción del documento lo reconoce y afirma: "Dadas las diferentes formas en que se pueden recopilar datos SBOM, los resultados de las herramientas pueden variar y proporcionar valor en diferentes casos de uso". Teniendo esto en cuenta, vale la pena desglosar los tipos de SBOM disponibles y algunos casos de uso potenciales para ayudar a aclarar cuáles pueden ser más útiles para una organización.

Decodificando los 6 tipos principales de SBOM

Hay seis tipos principales de SBOM que se utilizan hoy en día a medida que avanzan por 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 existir o no. Por lo general, se desarrolla en base a una RFP, un concepto o especificaciones. Si bien es teóricamente posible, es difícil imaginar cómo esto podría ayudar y cómo podría generar un documento legible por máquina que cumpliera con los estándares que respalda el gobierno federal.

    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 al equipo obtener los mejores componentes de código abierto desde una perspectiva empresarial.

  • • 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 construir un artefacto, pero excluye la herramienta de compilación del proceso. Generalmente 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 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 corregir vulnerabilidades conocidas en la fuente en las primeras etapas del proceso de desarrollo.

    La desventaja es que puede carecer de algunos de los detalles de otros tipos de SBOM, incluido el tiempo de ejecución, los complementos o los componentes dinámicos, como las bibliotecas del servidor de aplicaciones.

• • • 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 fuente, dependencias, componentes construidos, datos efímeros del proceso de construcción y SBOM de origen y diseño previo. 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 analizan los archivos reales, este tipo de SBOM crea un registro más completo con datos ricos sobre cada archivo, como su hash y su 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 compilación, que en ocasiones puede necesitar cambios para producirlo.

  • • Analizado: A veces esto se denomina “SBOM de terceros” o SCA binaria. 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 los datos de SBOM de otras fuentes para encontrar dependencias ocultas que las herramientas de creación de SBOM pasaron por alto.

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

    El lado negativo es que 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 crean SBOM que a menudo se pasan por alto.

• • Implementado: Como sugiere su nombre, se trata de un inventario del software implementado en el sistema, generalmente generado al compilar 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 del software, incluidas las otras configuraciones y componentes del sistema que ejecutan una aplicación.

  Generar este tipo de SBOM puede requerir cambiar los procesos de instalación e implementación, y es posible que no siempre refleje el entorno de ejecución del artefacto, ya que es posible que no se pueda acceder a algunos componentes. Sin embargo, 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 cargados 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. Sin embargo, aumenta 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 utilizar 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 generadora de SBOM disponible para fines de cumplimiento.

Dado el apoyo del gobierno federal, la SBOM sin duda llegó para quedarse. Puede establecer una base sólida e introducir orden en el proceso ocasionalmente caótico de proteger productos de software.