[26/07/2022] Para asegurar realmente el software, es necesario saber qué hay dentro de su código. Por eso, la lista de materiales de software es esencial hoy en día. Antes no nos preocupábamos tanto por la seguridad de nuestro código. Los binarios malos, claro. ¿El código en sí? No tanto. Éramos muy tontos.
Entonces llegó una bofetada de seguridad tras otra: El ataque a la cadena de suministro de software de SolarWinds, la actual vulnerabilidad de Log4j, y el código de protesta del mantenedor de npm que salió mal, han dejado claro que debemos limpiar nuestra cadena de suministro de software. Eso es imposible de hacer con el software propietario, ya que sus creadores no permiten saber lo que hay dentro de un programa. Pero con los programas de código abierto, esto puede hacerse con una lista de materiales de software (SBOM), que se pronuncia "s-bomb".
[Reciba lo último de CIO Perú suscribiéndose a nuestro newsletter semanal]
De hecho, los SBOM ya no son solo una buena idea; son un mandato federal. Según la Orden Ejecutiva del presidente Joe Biden del 12 de julio del 2021 sobre la mejora de la ciberseguridad de la nación, son un requisito. La orden define un SBOM como "un registro formal que contiene los detalles y las relaciones de la cadena de suministro de varios componentes utilizados en la construcción de software". Es una cuestión especialmente importante con el software de código abierto, ya que "los desarrolladores y proveedores de software suelen crear productos ensamblando componentes de software comercial y de código abierto existentes".
¿Es eso cierto? Sí. Todos sabemos que el software de código abierto se utiliza en todas partes para todo. Pero ¿sabía que la empresa de código abierto gestionado Tidelift cuenta con un 92% de aplicaciones que contienen componentes de código abierto? De hecho, el programa moderno medio comprende un 70% de software de código abierto.
Está claro que hay que hacer algo. La respuesta, según la Fundación Linux, la Fundación de Seguridad de Código Abierto (OpenSSF) y OpenChain, son los SBOM. Stephen Hendrick, vicepresidente de investigación de la Fundación Linux, define los SBOM como "metadatos formales y legibles por máquina que identifican de forma exclusiva un paquete de software y su contenido; pueden incluir otra información sobre su contenido, incluidos los derechos de autor y los datos de la licencia". Los SBOM están diseñados para ser compartidos por todas las organizaciones, y son especialmente útiles para dar transparencia a los componentes entregados por los participantes en una cadena de suministro de software".
Mejores prácticas de los SBOM
Un SBOM debe incluir:
- Las bibliotecas de código abierto de la aplicación
- Los plugins, extensiones y otros complementos del programa
- El código fuente personalizado escrito internamente por los desarrolladores
- Información sobre las versiones de estos componentes, el estado de las licencias y el estado de los parches
- Firma y verificación criptográfica automática de los componentes
- Escaneo automático para producir SBOMs como parte de su pipeline de integración continua/despliegue continuo (CI/CD)
El SBOM también debe utilizar un formato coherente. Los formatos de SBOM más populares incluyen el Intercambio de Datos de Paquetes de Software (SPDX, por sus siglas en inglés), el Etiquetado de Identificación de Software (SWID, por sus siglas en inglés) y OWASP CycloneDX. Aunque todos ellos son estándares, la orden ejecutiva del 2021 no impone un formato específico de SBOM. Hasta ahora, ninguno de los tres ha surgido de los otros para establecer un estándar de facto en la industria.
Para que los SBOM resulten prácticos, existe un impulso no solo para automatizar la creación de SBOM, sino para que forme parte de su canal de CI/CD. Como dice la Administración Nacional de Telecomunicaciones e Información (NTIA, por sus siglas en inglés), el objetivo final es la generación de SBOM a "velocidad de máquina".
Casos de uso de SBOM
Los SBOM también tienen tres casos de uso diferentes. A grandes rasgos, son los siguientes
- Los productores de software utilizan los SBOM para ayudar a construir y mantener el software que suministran.
- Los compradores de software utilizan los SBOM para informar sobre la garantía previa a la compra, negociar descuentos y planificar estrategias de implementación.
- Los operadores de software utilizan los SBOM para informar sobre la gestión de la vulnerabilidad y la gestión de activos, para gestionar las licencias y el cumplimiento, y para identificar rápidamente las dependencias del software y los componentes y los riesgos de la cadena de suministro.
Estos son bastante diferentes. Un desarrollador quiere herramientas que funcionen en su canalización CI/CD, como CircleCI, Jenkins o Travis CI. Un operador, o cliente, puede que ni siquiera sepa lo que es un pipeline de CI/CD, pero puede preocuparse mucho por la gestión de activos y las actualizaciones de parches de seguridad.
Gartner estima que, para el 2025, el 60% de las organizaciones que construyen o adquieren software de infraestructuras críticas exigirán y estandarizarán los SBOM. Hoy en día, es menos del 20%.
Principales programas de SBOM
Con tres formatos diferentes de SBOM y una amplia variedad de metadatos para rastrear dentro de un SBOM, no es de extrañar que no haya un programa de SBOM superior. Con el tiempo, lo habrá, pero aún no hemos llegado a ese punto.
Muchos programas de SBOM, aunque no todos, incluyen escáneres de seguridad de códigos y otros programas. El que los quiera depende de sus necesidades. Gartner recomienda utilizar herramientas con las siguientes capacidades
- Crear SBOMs durante el proceso de construcción.
- Analizar el código fuente y los binarios (como las imágenes de contenedores).
- Generar SBOMs para esos artefactos.
- Editar las SBOM.
- Ver, comparar, importar y validar los SBOM en un formato legible para el ser humano.
- Combinar y traducir el contenido de los SBOM de un formato o tipo de archivo a otro.
- Apoyar el uso de la manipulación de SBOM en otras herramientas a través de APIs y bibliotecas.
Ninguno de los siguientes programas cumple con todas estas recomendaciones. Incluso los más maduros de estos programas -Anchore, FOSSA y Rezillion- son todavía trabajos en curso.
Le aconsejo que pruebe la mayoría de estos programas, si no todos, y vea cuál funciona mejor para usted y su caso de uso específico. A continuación, comunique a los proveedores y desarrolladores su opinión. Si hacemos esto de aquí al 2025, probablemente tendremos un claro mejor programa para todos nuestros diferentes usos.
Aquí hay ocho programas de SBOM que merecen su atención:
Anchore: Anchore lleva seis años en el negocio del SBOM. Su base está construida sobre dos proyectos de código abierto. Estos son Syft, una herramienta de interfaz de línea de comandos (CLI) y una biblioteca para generar SBOMs a partir de imágenes de contenedores y sistemas de archivos; y Grype, una herramienta de escaneo de vulnerabilidades fácil de integrar para imágenes de contenedores y sistemas de archivos.
Juntos, puede utilizarlos para generar SBOMs en cada etapa del proceso de desarrollo, desde los repositorios de código fuente y los pipelines CI/CD, hasta los registros de contenedores y los tiempos de ejecución. Estos SBOM se mantienen en un repositorio centralizado para una visibilidad completa y una supervisión continua, incluso después de la implantación. Es compatible con CycloneDX, SPDX y el propio formato SBOM de Syft.
Anchore incluye su funcionalidad SBOM en la plataforma de software SCM (gestión de la cadena de suministro) Anchore Enterprise 4.0. El objetivo de Anchore es ser su empresa de software de cadena de suministro y seguridad SBOM todo en uno. Van por buen camino.
FOSSA: Los programas estrella de FOSSA son un gestor de cumplimiento de licencias de código abierto y un escáner de vulnerabilidad de código abierto. Si lo piensa, SBOM encaja de forma bastante natural con estos programas.
En el enfoque de FOSSA, puede integrar su herramienta SBOM con su sistema de control de versiones favorito como GitHub, BitBucket o GitLab. O puede usar su CLI y ejecutarlo localmente o integrarlo como parte de su pipeline CI/CD.
De cualquier manera, cuando escanee sus proyectos, FOSSA identificará automáticamente tanto las dependencias directas como las profundas para su base de código objetivo. Estos problemas de código profundo, como las dependencias indirectas que llaman a Log4j, pueden esconderse dentro de los programas y seguir siendo utilizados por los hackers para causar estragos.
Mend: Antes conocido como WhiteSource, Mend ofrece una variedad de herramientas de análisis de composición de software (SCA). SBOM está incorporado dentro de su herramienta Mend SCA. Como tal, Mend no es tanto un programa para desarrolladores o una herramienta CI/CD como un mecanismo de seguridad y licencia de código abierto para programadores.
Así, Mend puede utilizarse para rastrear cada componente, incluidas las dependencias directas y transitivas, identificar las vulnerabilidades, proporcionar una ruta de remediación y actualizar los registros de SBOM automáticamente a medida que los componentes cambian. La empresa afirma que su análisis patentado de la ruta de acceso le muestra qué vulnerabilidades pueden ignorarse con seguridad, ya sea porque las bibliotecas no son utilizadas por su aplicación, o porque no se utilizan de una manera que exponga las vulnerabilidades.
Rezilion: La empresa de DevSecOps Rezilion utiliza SBOM como parte de sus sistemas holísticos de seguridad de software y vulnerabilidades. Su Dynamic SBOM utiliza el análisis dinámico en tiempo de ejecución para rastrear la superficie de ataque de su software a medida que su código cambia. Así, busca constantemente los puntos débiles conocidos de los componentes de su código. En otras palabras, es un enfoque de dos por uno para rastrear y asegurar su código.
Además de proporcionar un inventario en vivo de todos los componentes de software en sus entornos de CI/CD, staging y producción, actualiza constantemente su SBOM. Puede exportar su SBOM como en CycloneDX y una hoja de cálculo de Excel.
SPDX SBOM Generator: SPDX SBOM Generator es una herramienta independiente de código abierto que hace justo lo que dice su nombre: crea SBOMs de SPDX a partir de sus gestores de paquetes o sistemas de compilación actuales. Puede utilizar su CLI para generar datos SBOM a partir de su código. Informa sobre los componentes, licencias, derechos de autor y referencias de seguridad de su código. Estos datos se exportan en la especificación SPDX v2.2. Si todo lo que necesita es lo básico, le funcionará bien.
Tern Proyect: Otro proyecto SBOM de código abierto, Tern podría emparejarse bien con el generador SPDX SBOM. En lugar de trabajar con gestores de paquetes o sistemas de construcción, esta herramienta SCA y la biblioteca Python generan un SBOM para imágenes de contenedores y archivos Docker. También produce SBOMs en SPDX.
TauruSeer: Este programa SBOM se ofrece como software como servicio (SaaS). Basándose en una metodología patentada de integración centrada en la aplicación, TauruSeer combina su escaneo de seguridad Cognition Engine con su SBOM. El paquete le ayudará a asegurar y rastrear su código para sus desarrolladores y clientes.
Vigilant Ops: Vigilant Ops es una empresa de ciberseguridad de dispositivos médicos que, con su plataforma InSight, ha centrado su atención en el SBOM. Su plataforma SaaS genera, mantiene y comparte de forma autenticada los SBOM certificados. Incorpora la seguridad mediante la supervisión continua de las vulnerabilidades y las alertas. Su certificación de SBOM utiliza algoritmos patentados para garantizar la validación de todos los componentes y la vinculación de las vulnerabilidades.
Sus características de seguridad también pueden utilizarse con los SBOM generados por otros programas. Estos se cifran tanto en reposo como en tránsito.
Basado en el artículo de Steven J. Vaughan-Nichols (CSO) y editado por CIO Perú
Puede ver también: