Llegamos a ustedes gracias a:



Reportajes y análisis

¿Qué es un SBOM? Explicación de la lista de materiales del software

[15/08/2022] Un SBOM es un registro formal y estructurado, que no solo detalla los componentes de un producto de software, sino que también describe su relación con la cadena de abastecimiento. Un SBOM describe qué paquetes y bibliotecas entraron en su aplicación, así como la relación entre esos paquetes y bibliotecas, además de otros proyectos ascendentes -algo que es de particular importancia cuando se trata de código reutilizado y código abierto.

[Reciba lo último de CIO Perú suscribiéndose a nuestro newsletter semanal]

Es posible que esté familiarizado con una lista de materiales para un automóvil. Este es un documento que entra en gran detalle acerca de cada componente que hace que su auto nuevo funcione. La cadena de abastecimiento de automóviles es notoriamente compleja y, aunque su automóvil fue ensamblado por Toyota o General Motors, muchos de sus componentes fueron fabricados por subcontratistas de todo el mundo. La lista de materiales le indica de dónde proviene cada una de esas partes, y ese conocimiento no es solo una curiosidad interesante. Si se ha retirado una producción determinada de bolsas de aire, los fabricantes de automóviles necesitan una forma rápida de saber dónde terminaron esas bolsas de aire particulares.

Escribir software no es exactamente como fabricar un automóvil, pero con el uso cada vez mayor de bibliotecas de código abierto de terceros para crear aplicaciones distribuidas en contenedores, los dos procesos tienen más en común de lo que usted podría pensar. Es por eso por lo que los SBOM se están volviendo cada vez más comunes.

Tanto los desarrolladores como los usuarios pueden usar un SBOM para comprender qué se incluye exactamente en el software que distribuyen y usan. Eso tiene una serie de implicaciones importantes, especialmente para la seguridad.

¿Por qué necesita un SBOM?

Los días de las bases de código, monolíticas y patentadas, de software han quedado atrás. Las aplicaciones modernas a menudo se crean sobre la base de una amplia reutilización de código, a menudo utilizando bibliotecas de código abierto. Estas aplicaciones también se dividen cada vez más en componentes de funcionalidad autónomos más pequeños, conocidos como contenedores, que son administrados por plataformas de orquestación de contenedores como Kubernetes y se ejecutan localmente o en la nube.

En general, estos cambios han sido una bendición para el desarrollo de software y ciertamente han aumentado la productividad del desarrollador y reducido los costos. Pero, en muchos sentidos, han sido una pesadilla para la seguridad. Al depender en gran medida del código de terceros, sin estar completamente familiarizados con el funcionamiento interno del mismo, los desarrolladores han creado una cadena de abastecimiento de componentes de software tan compleja como las que utilizan los fabricantes físicos. Y debido a que una aplicación es tan segura como su componente menos seguro, el software creado de esta manera tiene vulnerabilidades únicas con las que la industria está lidiando profundamente.

Hasta ahora, la década del 2020 ha estado marcada por una serie de ataques a la cadena de abastecimiento de software que han sido noticia. A fines del 2020, los hackers afiliados a la inteligencia rusa lograron colocar backdoors en una plataforma de monitoreo de red de SolarWinds -una plataforma que, a su vez, es utilizada por otros productos de seguridad, todos los cuales terminaron comprometidos. Y a fines del 2021, se descubrió una vulnerabilidad grave en Apache Log4j, una biblioteca de Java utilizada para registrar eventos del sistema, lo que suena aburrido hasta que uno se da cuenta de que casi todas las aplicaciones de Java usan Log4j de alguna manera, convirtiéndolas a todas en blancos.

Estas crisis de seguridad ilustran el papel que puede desempeñar un SBOM en el panorama de la seguridad. Es posible que muchos usuarios hayan oído hablar de estas vulnerabilidades, pero no sabían que estaban ejecutando Log4j o cualquier componente de SolarWinds. Con un SBOM adecuado, sabrá exactamente qué paquetes ha implementado y, más concretamente, qué versión de esos paquetes. Esto le permitirá actualizar según sea necesario para mantenerse seguro.

Los SBOM también pueden ir más allá de la seguridad. Por ejemplo, pueden ayudar a los desarrolladores a realizar un seguimiento de las licencias de código abierto para sus diversos componentes de software, lo cual es importante cuando se trata de distribuir su aplicación.

Orden ejecutiva de la lista de materiales de software

En particular, el hackeo de SolarWinds alarmó al gobierno de Estados Unidos, ya que muchas agencias federales habían implementado el componente comprometido. Es por eso por lo que, en mayo, se emitió una importante orden ejecutiva de ciberseguridad que incluía directivas para los SBOM. Específicamente, se ordenó al Departamento de Comercio que publicara una línea base de elementos mínimos para los SBOM, que luego se convertiría en un requisito para cualquier proveedor que le venda al gobierno federal.

Aunque la orden se aplica específicamente a aquellos que tienen relaciones directas con los federales, la naturaleza expansiva del gobierno de Estados Unidos y las muchas empresas ansiosas por trabajar con éste, tendrán efectos colaterales. Después de todo, los productos que se venden al gobierno, que ahora vienen con un SBOM que detalla sus componentes, en su mayor parte también se venden a otras empresas y organizaciones. Muchos fabricantes de software esperan que, a pesar de que el gobierno los ha empujado en esta dirección, sus clientes del sector privado también verán los SBOM como un valor agregado.

Además, la contratación federal es, en sí misma, una cadena de abastecimiento. "Hay un número limitado de empresas que hacen negocios directamente con el gobierno federal, y obviamente se verán directamente afectadas, le comentó Sounil Yu, exjefe científico de seguridad de Bank of America -actualmente CISO y jefe de investigación de JupiterOne- a CSO cuando se implementó la orden ejecutiva. "El efecto de segundo orden, aquellas empresas que venden a aquellas empresas que venden al gobierno federal, es mucho mayor.

¿Qué se debe incluir en un SBOM?

En julio del 2021, en respuesta a la orden ejecutiva, la Administración Nacional de Telecomunicaciones e Información (NTIA, por sus siglas en inglés) publicó "Los Elementos Mínimos para una Lista de Materiales de Software, que describía lo que un SBOM necesitaría para cumplir con los requisitos del gobierno federal. Nuevamente, debido a la posición dominante que tiene la contratación federal dentro de la economía, se esperaba que este documento se convirtiera en un estándar de facto para los SBOM en toda la industria. La NTIA estableció siete campos de datos que cualquier SBOM debería tener:

  • Nombre del proveedor: El nombre de una entidad que crea, define e identifica un componente.
  • Nombre del componente: La designación asignada a una unidad de software definida por el proveedor original.
  • Versión del componente: Un identificador utilizado por el proveedor para especificar un cambio en el software de una versión previamente identificada.
  • Otros identificadores únicos: Otros identificadores que se utilizan para identificar un componente o sirven como clave de búsqueda para bases de datos relevantes. Por ejemplo, podría ser un identificador del Diccionario CPE de NIST.
  • Relación de dependencia: Caracteriza la relación en la que un componente aguas arriba X está incluido en el software Y. Esto es particularmente importante para los proyectos de código abierto.
  • Autor de datos SBOM: El nombre de la entidad que crea los datos SBOM para este componente.
  • Timestamp: Registro de la fecha y hora del montaje de datos SBOM.

Los SBOM también deben cumplir con estos requisitos:

  • El SBOM estará en uno de los tres formatos estandarizados: SPDX, CycloneDX o etiquetas SWID -para que pueda ser legible por máquina.
  • Se debe generar un nuevo SBOM con cada nueva versión del software, asegurándose de que estén actualizados.
  • Además de incluir las relaciones de dependencia, el SBOM debe explicar dónde es probable que existan tales relaciones, pero sean desconocidas para organización que elabora el SBOM.

Cómo generar un SBOM

Al leer este artículo, es posible que encuentre la posibilidad de generar un SBOM bastante desalentadora. Después de todo, rastrear manualmente todas esas cosas tiene que ser una pesadilla, ¿verdad? Bueno, afortunadamente, eso no es algo que se espera que haga. En la mayoría de los casos, los SBOM se generan automáticamente mediante herramientas de análisis de composición de software (SCA, por sus siglas en inglés). Las herramientas SCA se usan con frecuencia dentro de las canalizaciones de DevSecOps y, a menudo, desempeñan funciones más allá de la creación de un SBOM.

En busca de paquetes, las herramientas SCA escanearán sus directorios de código y los compararán con bases de datos en línea para también compararlos con bibliotecas conocidas. También existen otras alternativas: por ejemplo, hay algunas herramientas que simplemente crearán un SBOM como parte del proceso de creación del software.

La OWASP Foundation, la venerable organización especializada en seguridad que desarrolló el estándar CycloneDX, ha reunido una lista bastante completa de herramientas SCA. Esta lista es instructiva porque abarca toda la gama, desde herramientas básicas de línea de comandos de código abierto hasta productos comerciales llamativos. Si desea profundizar más en este espacio de productos, el artículo "7 principales herramientas de seguridad de la cadena de abastecimiento de software, se centra en las herramientas para generar SBOMs y proporciona una discusión relativamente profunda de nuestra recomendación.

Si está construyendo software distribuido, se está volviendo cada vez más importante que integre los SBOM en su práctica de desarrollo. Es posible que no tenga un contrato con el gobierno federal (o que aún no tenga un contrato con ellos), pero es casi seguro que tenga que preocuparse por los ataques a la cadena de abastecimiento, y los SBOM ofrecen un vistazo a la caja negra, que es el código reutilizado de terceros.

Puede ver también: