Creación de una SBOM (lista de materiales de software) para la seguridad de la cadena de suministro de código abierto

Ahora más que nunca, los desarrolladores construyen aplicaciones web sobre la base de bibliotecas de software de código abierto. Sin embargo, aunque estas bibliotecas forman parte del inventario de componentes de la SBOM, no todos los desarrolladores y las partes interesadas de la empresa comprenden el importante impacto que tiene la inclusión de bibliotecas de terceros en la seguridad de la cadena de suministro de código abierto. Con esto en mente, vamos a explorar el tema de la seguridad de las SBOM y la importancia de rastrearlas para las aplicaciones que estás construyendo.

La seguridad de la cadena de suministro de software es un dilema cada vez más preocupante tanto para las organizaciones como para los gobiernos. Threat Landscape for Supply Chain Attacks (Panorama de amenazas a la cadena de suministro), un informe publicado por la ENISA (Agencia de la Unión Europea para la Ciberseguridad), estimó un aumento del 400 % en los ataques a la cadena de suministro de software en 2021.

El amplio uso de software de código abierto a disposición de los desarrolladores hoy en día y la facilidad para importar componentes de software contribuyen a aumentar el factor de riesgo debido a las preocupaciones legales y de seguridad para un desarrollador y, posteriormente, para la empresa. Por eso es importante educar a los desarrolladores y a los equipos de seguridad y proporcionarles soluciones avanzadas de seguridad para la cadena de suministro.

Antes de avanzar demasiado, vamos a echar un vistazo a algunos conceptos básicos de SBOM y a aclarar los términos técnicos que se utilizan a lo largo de este artículo.

¿Qué es una lista de materiales de software?

Una lista de materiales de software, a menudo abreviada como SBOM, es una lista completa de todos los componentes de software utilizados en una organización. La lista de materiales de software se compone de bibliotecas de código abierto de terceros, paquetes proporcionados por proveedores y artefactos de origen propio creados por la organización.

¿Por qué tengo que crear una SBOM?

Una SBOM es esencialmente un inventario de todos los componentes de software que utilizas en tus aplicaciones. Sin ella, no tienes visibilidad de los riesgos de licencias y seguridad asociados al software que estás creando o consumiendo. Mantener una lista de materiales de software actualizada y compatible con el formato SBOM es crucial para seguir el ritmo del rápido desarrollo de software, en el que los componentes y sus versiones cambian rápidamente.

¿Qué es CycloneDX?

OWASP CycloneDX es un estándar de lista de materiales de software (SBOM) diseñado para contextos de seguridad de aplicaciones y análisis de componentes de la cadena de suministro, que proporciona un inventario de todos los componentes de software de origen propio y de terceros. La especificación es rica y va más allá de las bibliotecas de software, para abarcar estándares como la lista de materiales de software como servicio (SaaSBOM), el intercambio de vulnerabilidades (VEX) y más. El estándar es un proyecto de código abierto con licencia Apache 2.0 y está abierto a la colaboración en el siguiente repositorio GitHub de código abierto: https://github.com/CycloneDX/specification.

Preocupaciones de seguridad que exigen a los desarrolladores mantener una lista de materiales de software

Una lista de materiales de software no es un término que resuene entre los desarrolladores. Esto se debe a que tradicionalmente era una actividad reservada a los equipos de seguridad y evaluación de riesgos de una organización. Sin embargo, las cosas cambiaron debido al tremendo auge de los componentes de software de código abierto, como pone de manifiesto el registro de paquetes npm, que abarca más de 1 800 000 paquetes gratuitos y de código abierto.

Si eres desarrollador y tienes dudas de que necesites una SBOM para todos los componentes de software que utilizas, solo tenemos que recordarte varios incidentes de seguridad de gran repercusión que se produjeron en los últimos años debido a las bibliotecas de software de código abierto:

1. event-stream: el popular paquete npm fue vulnerado para incluir código malicioso.

2. Log4Shell: se descubrió que la popular biblioteca de registro de Java Log4j tiene una vulnerabilidad de ejecución remota de código de alta gravedad. ¡Esta vulnerabilidad existía desde siete años antes de que se descubriera!

Cuando se descubren y se producen estas vulnerabilidades o incidentes de seguridad, y tu aplicación utiliza una de estas versiones vulnerables, ¿quién crees que es el responsable de actualizar estas bibliotecas y publicar una nueva versión? Así es, los desarrolladores.

Incluso si el equipo de seguridad hace lo suyo y mantiene la lista de materiales del software por su cuenta, cuando descubren problemas de este tipo, dan la alarma, avisan a los equipos necesarios y buscan desarrolladores que actualicen las versiones vulnerables. Pero, en este mundo de gestión avanzada de flujos de trabajo, ¿no podemos automatizar todo este proceso para que se integre de forma más nativa en los flujos de trabajo de los desarrolladores? Claro que sí. De eso se ocupa Snyk, que es de uso gratuito.

¿Por qué deberían los desarrolladores preocuparse por el impacto legal de su lista de materiales de software?

Hoy en día, es probable que los desarrolladores no piensen en los aspectos legales del uso de software cuando retocan su código y crean aplicaciones. Sin embargo, hace un par de décadas no era así. Los desarrolladores y su personal eran muy sensibles a la licencia específica de los componentes de software que incorporaban en su código. ¿Qué cambió? Pues bien, por aquel entonces, las licencias más utilizadas eran las de tipo copyleft, como la GPL (Licencia Pública General) de GNU, que había establecido varias limitaciones a la distribución de software. En resumen, la licencia GPL tiene un efecto en cascada, de modo que cualquier código creado a partir de un componente con licencia GPL se convierte automáticamente en un componente con licencia GPL. Es algo para tener en cuenta al elaborar un modelo de negocios.

Unos 20 años más tarde, se produjo un enorme alejamiento de las licencias copyleft. En 2015, la licencia más utilizada en los repositorios de código abierto creados en GitHub es una licencia MIT. Junto con otras licencias, la MIT pertenece a una familia de licencias permisivas, que se deshacen de muchas de las limitaciones sobre cómo debe utilizarse el software y, en su lugar, aumentan las libertades que tienen los desarrolladores al utilizar dicho software licenciado.

Nos encontramos en un momento de la historia del software de código abierto en el que se está produciendo un inmenso crecimiento de la adopción y de las nuevas aportaciones de software con licencias muy permisivas. ¿Nos acostumbramos a utilizar software de código abierto por defecto? ¿Estamos dando por sentadas las licencias de software de código abierto?

Dos casos, muy populares, de problemas legales del software que tienen que ver con el uso de la licencia propia del proyecto se encuentran en el centro de los desarrolladores:

1. React, la inmensamente popular biblioteca de vista JavaScript de código abierto tuvo su cambio de licencia de su propia versión de “BSD + concesión de patentes” a la permisiva licencia MIT, debido a que la Apache Software Foundation prohibió el proyecto React, condenando la licencia de Facebook como demasiado restrictiva. Esto también fue objeto de presiones por parte de desarrolladores de todo el mundo, que habían considerado abandonar el proyecto por completo y pasarse a otras alternativas, como el proyecto Preact. Quincy Larson ofrece una útil cronología de los acontecimientos en el siguiente artículo de freecodecamp.

2. Elastic, la empresa y proyecto de código abierto del mismo nombre, de la popular herramienta de búsqueda y ELK Stack, también tuvo que lidiar con los cambios de licencia debido a la creciente competencia de los proveedores de la nube y su impacto en el negocio de Elastic.

Como desarrollador que utiliza React, Elastic u otras bibliotecas de software de código abierto, lo más probable es que seas responsable de factorizar la migración de un proyecto a otro cuando surgen problemas de licencia.

Además, ¿qué ocurre si acabas creando aplicaciones y distribuyendo software en el que uno de sus componentes anidados tiene una licencia copyleft? Los ecosistemas JavaScript y Node.js son bien conocidos por el elevado número de paquetes npm que se instalan. El riesgo para la empresa es muy real, y exige tu atención, como desarrollador, para poder rastrear y comprender qué licencias de software se utilizan en tus proyectos.

Las aplicaciones que construyes y el software que consumes probablemente ya incluyen referencias para la licencia que se está utilizando. Por ejemplo, si estás creando un proyecto JavaScript, la información de licencia forma parte del archivo de manifiesto package.json:

1{
2  "name": "snyk",
3  "version": "1.0.0-monorepo",
4  "description": "snyk library and cli utility",
5  "files": [
6    "help/cli-commands",
7    "dist",
8    "bin",
9    "pysrc",
10    "config.default.json",
11    "SECURITY.md",
12    "LICENSE",
13    "README.md"
14  ],
15  "author": "snyk.io",
16  "license": "Apache-2.0",

La licencia descrita en este archivo package.json utiliza el formato SBOM común denominado SPDX para garantizar su conformidad con los estándares internacionales y de interoperabilidad entre herramientas.

¿Qué es SPDX?

SPDX (intercambio de datos de paquetes de software) es un proyecto de colaboración de la Fundación Linux que proporciona un estándar de formato SBOM común para el seguimiento de la lista de materiales de software, lo que facilita la creación de informes de interoperabilidad por parte de diversas herramientas. En concreto, la lista de licencias SPDX proporciona un identificador común de la lista de licencias junto con una URL canónica para cada licencia.

La página web SPDX License List (Lista de licencias de SPDX) proporciona la lista completa de todas las licencias y sus identificadores:

Snyk proporciona capacidades de auditoría de código abierto que, de forma similar a la tabla anterior, generan informes de la lista de materiales de software para establecer una auditoría de software completa, totalmente interactiva, con capacidad de búsqueda y filtros.

Estandarización del uso de bibliotecas de código abierto por parte de los desarrolladores

Las organizaciones de ingeniería maduras pasan del uso oportunista y ocasional de bibliotecas de código abierto a un uso más intencionado y planificado de bibliotecas de código abierto en sus proyectos, que siguen directrices y prácticas recomendadas.

Por ejemplo, los equipos de desarrollo de JavaScript querrían asegurarse de que los desarrolladores de los distintos equipos se estandarizan en el uso de una única dependencia de solicitudes HTTP elegida, en lugar de valerse de una multitud de dependencias, como request, axios, node-fetch, y otras de paquete npm. El razonamiento no es solo una gestión más sencilla de las dependencias de código abierto, sino también centralizar la experiencia y el conocimiento de las API, facilitar la resolución de problemas y mucho más.

Para cualquier equipo de desarrollo, ¿pueden responder de forma realista a las siguientes preguntas?

• ¿Qué bibliotecas de código abierto utilizo más en todos los proyectos de mi organización de I+D?

• ¿Qué bibliotecas de código abierto que utilizo se marcaron como obsoletas?

• ¿Qué bibliotecas de código abierto de mis proyectos utilizan licencias copyleft como la GPL-2?

• ¿Qué bibliotecas de código abierto se publicaron hace más de 15 años y no se actualizaron? ¿Deberían preocuparse por eso?

Todo esto y mucho más son ventajas que se obtienen al mantener una lista de materiales de software, una SBOM. Snyk también pone a disposición esta valiosa información sobre la salud de los paquetes de código abierto como parte de las funciones de Snyk Open Source:

¿Por qué la SBOM acelera la preparación de tu cadena de suministro en materia de seguridad?

¿Qué es la seguridad de la cadena de suministro de software?

Las preocupaciones tradicionales sobre la seguridad de las aplicaciones en el ciclo de vida de la seguridad del desarrollo de software evolucionaron desde el propio código del desarrollador a toda la infraestructura de herramientas de desarrollo que conforma la construcción del software. Como tal, se crea una superficie de ataque de amenazas increíblemente grande desde el primer paso de la herramienta del IDE real que los desarrolladores utilizan para escribir código, pasando por los componentes de código abierto con los que construyen sus aplicaciones, y hasta pipelines CI/CD, y la configuración de la infraestructura de implementación. De hecho, se podría argumentar que el riesgo para la seguridad de la cadena de suministro se extiende a los chips de hardware de la computadora que utilizas como entorno de desarrollo.

El Departamento de Comercio de los Estados Unidos publicó un documento en cumplimiento de la Orden Ejecutiva 14028 sobre la mejora de la ciberseguridad de la nación, en el que cita Los elementos mínimos para una lista de materiales de software (SBOM). Desarrollemos un poco más la historia de la cadena de suministro y veamos qué podemos aprender de ella.

La cadena de suministro de software son esencialmente todos y cada uno de los componentes que forman parte del flujo de trabajo completo a través del cual se construye el software. Al principio, se podría pensar en la cadena de suministro de software simplemente como las dependencias que se agregan a los proyectos. Es cierto, pero la cadena de suministro de software va mucho más allá.

Tu IDE también es una parte crucial de tu flujo de trabajo de desarrollo de software, ¿verdad? ¿Qué riesgo supondría para la empresa que tu IDE favorito tuviera puertas traseras o malware? ¿Y si una de esas extensiones o complementos del IDE tuviera vulnerabilidades graves o directamente incluyera código malicioso?

Vulnerabilidades en las extensiones de VS Code

Las extensiones vulnerables de VS Code no son solo una preocupación teórica. En mayo de 2021, Snyk descubrió vulnerabilidades de seguridad en la cadena de suministro de las extensiones de Visual Studio Code en el marketplace de extensiones de VS Code que afectan a más de 2 000 000 de desarrolladores según su recuento de descargas.

Estas extensiones de VS Code, como Open in Default Browser, con más de 520 000 descargas, o Instant Markdown, con más de 120 000 descargas, suponen una amenaza real y genuina para los desarrolladores. Si un atacante engaña a los desarrolladores para que hagan clic en un vínculo, podrían incorporar una vulnerabilidad de recorrido de directorios que expone el acceso a archivos e información confidenciales en su entorno de desarrollo. En casos más graves de las vulnerabilidades, una completa ejecución remota de comandos se pone a disposición de los atacantes simplemente porque los desarrolladores hacen clic en un vínculo.

El siguiente video demuestra por qué la seguridad de la SBOM de las cadenas de suministro de software es una preocupación crucial de los desarrolladores, ya que muestra una explotación de la extensión de VS Code Instant Markdown y cómo roba claves SSH sensibles de un desarrollador:

Vulnerabilidades de seguridad que afectan al IDE de Java

Si crees que la seguridad de la cadena de suministro está causando estragos en el ecosistema de JavaScript, permíteme compartir contigo la cronología de ENISA de 24 incidentes de seguridad de la cadena de suministro solo en el lapso de 18 meses (de enero de 2020 a julio de 2021), que incluye casos de incidentes maliciosos de seguridad de la cadena de suministro que afectan a los desarrolladores de Java a través del IDE NetBeans:

Mantener una SBOM de código abierto segura

Entonces, ¿cómo mitigar los problemas de seguridad de la cadena de suministro de software a lo largo de todo el SDLC (ciclo de vida del desarrollo de software)? Mantener una SBOM actualizada no solo es un buen comienzo, sino una exigencia de la orden ejecutiva del gobierno de EE. UU. debido al increíble panorama de amenazas que los componentes de software de código abierto suponen tanto para las empresas como para los gobiernos.

Un aspecto importante de la seguridad de la cadena de suministro de código abierto no es solo el panorama de las amenazas a la seguridad derivadas de las vulnerabilidades de seguridad conocidas y los posibles días cero de actos maliciosos, sino también la salud general del paquete. Las señales relacionadas con la cadencia de commits y releases del proyecto, el recuento de incidencias abiertas y la comunidad general de colaboradores implicados en el proyecto contribuyen a la puntuación general de la salud del paquete y deberían proporcionar orientación sobre el mantenimiento general del proyecto y si es susceptible de actividades maliciosas.

Snyk desarrolló Snyk Advisor a fin de resolver este problema exacto para las consideraciones de seguridad de la cadena de suministro de software de código abierto en relación con las puntuaciones de salud de los paquetes. Actualmente admite metadatos para ecosistemas como JavaScript, Go, Python e imágenes de contenedores basadas en Docker, y recomendamos encarecidamente su consulta en la búsqueda de bibliotecas de código abierto.

Generación de una SBOM de código abierto con Snyk

Snyk Open Source trabaja con manifiestos de paquetes y archivos de bloqueo para construir un gráfico de dependencias completo, que resulta útil para localizar vulnerabilidades en la jerarquía u otros problemas, como paquetes obsoletos. Sin embargo, eso en sí mismo no es una SBOM.

Gareth Rushgrove, vicepresidente de Producto de Snyk, escribió sobre el avance de los estándares SBOM con Snyk y SPDX. En este artículo, Gareth habla de cómo Snyk explora varias formas de trabajar con herramientas de la comunidad, y llama la atención sobre snyk2spdx, que es un proyecto de código abierto que convierte la salida CLI de Snyk a formato SPDX.

Si eres un fan de la API de Snyk, Gareth también recomienda utilizarla para obtener el manifiesto del paquete subyacente y los detalles de vulnerabilidad como fuente de consumo, que luego puedes convertir a SPDX.

En resumen, la obligatoriedad de la SBOM como parte del proceso de desarrollo y entrega de software es un aspecto importante en la actual preocupación por la seguridad de la cadena de suministro. Ayuda a responder a cualquier cuestión, desde el inventario hasta la integridad y la procedencia.

Te recomendamos que leas los siguientes artículos para seguir avanzando en tus conocimientos sobre la seguridad de la cadena de suministro en el código abierto y la lista de materiales de software:

• Comprender los requisitos de seguridad de la cadena de suministro de software en la Orden Ejecutiva sobre ciberseguridad, por Daniel Berman

• Para obtener más información sobre la comparación de licencias, consulta la documentación sobre licencias de código abierto: tipos y comparación

• Gestión del cumplimiento de licencias en toda la organización con las políticas de licencias de Snyk, por Josepha Riveros

• Explora una gestión práctica de la política de licencias en la plataforma Snyk a través de la documentación de Snyk