Crea una lista de materiales de software (SBOM) para proteger la cadena de suministro de código abierto
14 de marzo de 2022
0 minutos de lecturaHoy más que nunca, los desarrolladores crean 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 una lista de materiales de software (SBOM), no todos los desarrolladores ni las partes interesadas del negocio comprenden el impacto significativo que tiene incluir bibliotecas de terceros en la seguridad de la cadena de suministro de código abierto. Con esto en mente, exploremos la seguridad de las SBOM y la importancia de hacerles seguimiento en las aplicaciones que estás creando.
La seguridad de la cadena de suministro de software se ha convertido cada vez más en un dilema preocupante tanto para las organizaciones como para los gobiernos. Threat Landscape for Supply Chain Attacks, un informe publicado por la Agencia de la Unión Europea para la Ciberseguridad (ENISA), estimó un aumento del 400 % en los ataques a la cadena de suministro de software en 2021.
El amplio uso del software de código abierto disponible para los desarrolladores y la facilidad para importar componentes de software aumentan el nivel de riesgo por cuestiones de seguridad y legales para los desarrolladores y, en consecuencia, para las empresas. Por eso es importante capacitar a los desarrolladores y equipos de seguridad, y ofrecerles soluciones avanzadas de seguridad de la cadena de suministro.
Antes de profundizar, repasemos algunos conceptos básicos de las SBOM y aclaremos los términos técnicos que se usan en este artículo.
¿Qué es una lista de materiales de software?
Una lista de materiales de software, que suele abreviarse como SBOM, es una lista completa de todos los componentes de software que se utilizan en una organización. La lista de materiales de software incluye bibliotecas de código abierto de terceros, paquetes proporcionados por proveedores y artefactos propios creados por la organización.
¿Por qué necesito crear una SBOM?
Una SBOM es, en esencia, 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 creas o utilizas. Mantener una lista de materiales de software actualizada y compatible con el formato SBOM también es fundamental 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. Ofrece un inventario de todos los componentes de software propios y de terceros. La especificación es amplia y va más allá de las bibliotecas de software: incluye estándares como la lista de materiales de software como servicio (SaaSBOM), Vulnerability Exploitability Exchange (VEX) y otros. Es un proyecto de código abierto con licencia Apache 2.0 y está abierto a la colaboración en el siguiente repositorio de GitHub: https://github.com/CycloneDX/specification.
Problemas de seguridad que exigen que los desarrolladores mantengan una lista de materiales de software
El término «lista de materiales de software» no suele ser familiar para los desarrolladores. Esto se debe a que, tradicionalmente, ha sido una actividad reservada para los equipos de seguridad y evaluación de riesgos de una organización. Pero las cosas han cambiado debido al enorme crecimiento de los componentes de software de código abierto, como lo demuestra el registro de paquetes npm, que tiene más de 1.800.000 paquetes gratuitos y de código abierto.
Si eres desarrollador y dudas de por qué necesitas una SBOM para todos los componentes de software que usas, basta con recordarte algunos incidentes de seguridad de alto perfil ocurridos en los últimos años debido a bibliotecas de software de código abierto:
event-stream: El popular paquete de npm fue vulnerado para incluir código malicioso.
Log4Shell: Se descubrió que la popular biblioteca de registro de Java Log4j tenía una vulnerabilidad grave de ejecución remota de código. ¡Esta vulnerabilidad había existido durante siete años antes de que la descubrieran!
Cuando se descubren y ocurren estas vulnerabilidades o incidentes de seguridad, y tu aplicación usa una de las versiones vulnerables, ¿quién crees que es responsable de actualizar estas bibliotecas y publicar una nueva versión? Así es: los desarrolladores.
Aunque el equipo de seguridad haga lo suyo y mantenga por su cuenta la lista de materiales de software, cuando descubre estos problemas, da la alerta, avisa a los equipos correspondientes y busca a los desarrolladores para que actualicen las versiones vulnerables. Pero, en un mundo con flujos de trabajo tan avanzados, ¿no podemos automatizar todo este proceso e integrarlo de forma más natural en los flujos de trabajo de los desarrolladores? Claro que sí. De eso se trata Snyk, que es gratis.
¿Por qué deberían interesarles a los desarrolladores las implicaciones legales de su lista de materiales de software?
Hoy, probablemente los desarrolladores no piensan en los aspectos legales del software cuando experimentan con su código y crean aplicaciones. Sin embargo, hace un par de décadas no era así. Los desarrolladores y sus equipos prestaban mucha atención a la licencia específica de los componentes de software que incorporaban a su código. ¿Qué cambió? En aquel entonces, las licencias más comunes eran de tipo copyleft, como la Licencia Pública General de GNU (GPL), que imponía varias limitaciones a la distribución del software. En pocas palabras, la GPL tiene un efecto en cadena: cualquier código creado con un componente bajo licencia GPL pasa automáticamente a estar bajo esa misma licencia. Es algo que debes tener en cuenta al crear tu modelo de negocio.
Unos 20 años después, vimos un alejamiento importante de las licencias copyleft. Para 2015, la licencia más usada en los repositorios de código abierto creados en GitHub era la licencia MIT. Al igual que otras licencias, la MIT forma parte de las licencias permisivas, que eliminan muchas de las restricciones sobre el uso del software y, en cambio, dan más libertad a los desarrolladores que lo utilizan.
Estamos en un momento de la historia del software de código abierto en el que crecen enormemente tanto su adopción como la cantidad de software nuevo publicado con licencias muy permisivas. ¿Nos acostumbramos a usar el software de código abierto como opción predeterminada? ¿Damos por sentadas sus licencias?
Dos casos muy conocidos de problemas legales relacionados con la licencia de un proyecto han estado en el centro de la atención de los desarrolladores:
React, la popular biblioteca de vistas de JavaScript de código abierto, cambió su licencia: pasó de su propia versión de «BSD + concesión de patentes» a la permisiva licencia MIT, después de que la Apache Software Foundation prohibiera el proyecto React por considerar demasiado restrictiva la licencia de Facebook. También hubo presión de desarrolladores de todo el mundo, que habían considerado abandonar el proyecto por completo y pasarse a alternativas como Preact. Quincy Larson ofrece una cronología útil de los hechos en el siguiente artículo de freeCodeCamp.
Elastic, tanto la empresa como el proyecto de código abierto del mismo nombre, creador de la popular herramienta de búsqueda y de ELK Stack, también tuvo que afrontar cambios de licencia ante la creciente competencia de los proveedores de servicios en la nube y su impacto en el negocio de Elastic.
Como desarrollador que usa React, Elastic u otras bibliotecas de software de código abierto, lo más probable es que seas responsable de planificar la migración de un proyecto a otro cuando surjan problemas con las licencias.
Además, ¿qué pasa si terminas creando aplicaciones y distribuyendo software que incluye componentes anidados con una licencia copyleft? Los ecosistemas de JavaScript y Node.js son conocidos por la gran cantidad de paquetes npm que se instalan. El riesgo para la empresa es muy real y requiere que, como desarrollador, prestes atención para poder hacer un seguimiento y entender qué licencias de software se usan en tus proyectos.
Es probable que las aplicaciones que creas y el software que utilizas ya incluyan referencias a la licencia correspondiente. Por ejemplo, si estás creando un proyecto de JavaScript, la información de la licencia forma parte del archivo de manifiesto package.json:
La licencia descrita en este archivo package.json usa el formato común de SBOM conocido como SPDX para garantizar que cumpla con los estándares internacionales y de interoperabilidad entre herramientas.
¿Qué es SPDX?
Software Package Data Exchange (SPDX) es un proyecto colaborativo de la Linux Foundation que ofrece un estándar de formato común para registrar listas de materiales de software y facilita la creación de informes interoperables con diversas herramientas. En particular, la lista de licencias de SPDX proporciona un identificador común para cada licencia y una URL canónica.
La siguiente página web de la lista de licencias de SPDX contiene la lista completa de licencias y sus identificadores:
Snyk ofrece funciones de auditoría de código abierto que, al igual que en la tabla anterior, generan informes de listas de materiales de software para crear una auditoría integral del software, totalmente interactiva, con 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 de usar bibliotecas de código abierto de forma oportunista y ocasional a hacerlo de manera más deliberada y planificada en sus proyectos, siguiendo pautas y prácticas recomendadas.
Por ejemplo, los equipos de desarrollo de JavaScript querrían asegurarse de que los desarrolladores de distintos equipos estandaricen el uso de una sola dependencia para solicitudes HTTP, en lugar de depender de varias, como los paquetes npm request, axios, node-fetch y otros. El objetivo no es solo facilitar la administración de las dependencias de código abierto, sino también centralizar el conocimiento y la experiencia sobre las API, simplificar la resolución de problemas y más.
Para cualquier equipo de desarrollo, ¿puedes responder con seguridad estas preguntas?
¿Qué bibliotecas de código abierto uso más en todos los proyectos de mi organización de I+D?
¿Qué bibliotecas de código abierto que uso se marcaron como obsoletas?
¿Qué bibliotecas de código abierto de mis proyectos usan licencias copyleft, como GPL-2?
¿Qué bibliotecas de código abierto se publicaron hace más de 15 años y no recibieron ninguna actualización? ¿Deberías preocuparte por eso?
Mantener una lista de materiales de software (SBOM) te permite obtener toda esta información y mucho más. Snyk también ofrece información tan valiosa sobre el estado de los paquetes de código abierto como parte de las funciones de Snyk Open Source:
¿Por qué una SBOM acelera tu preparación para proteger la cadena de suministro?
¿Qué es la seguridad de la cadena de suministro de software?
Las preocupaciones tradicionales sobre la seguridad de las aplicaciones durante el ciclo de vida del desarrollo de software han pasado del código creado por los desarrolladores a toda la infraestructura de herramientas que interviene en la creación de software. Esto genera una superficie de ataque enorme, que abarca desde la herramienta de IDE que los desarrolladores usan para escribir código hasta los componentes de código abierto con los que crean sus aplicaciones, además de los pipelines de CI/CD y la infraestructura de implementación. De hecho, se podría argumentar que el riesgo para la seguridad de la cadena de suministro se extiende incluso a los chips de hardware de la computadora que usas como entorno de desarrollo.
El Departamento de Comercio de 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 de una lista de materiales de software (SBOM). Sigamos explorando la historia de la cadena de suministro para ver qué podemos aprender.
La cadena de suministro de software comprende todos los componentes que forman parte del flujo de trabajo completo con el que desarrollas software. Al principio, podrías pensar que la cadena de suministro de software consiste simplemente en las dependencias que agregas a tus proyectos. Es cierto, pero la cadena de suministro de software abarca mucho más que eso.
Tu IDE también es una parte fundamental de tu flujo de trabajo de desarrollo de software, ¿verdad? ¿Qué riesgo representaría para la empresa que tu IDE favorito tuviera puertas traseras o malware? ¿Y si alguna de sus extensiones o complementos tuviera vulnerabilidades graves o incluyera código malicioso?
Vulnerabilidades en las extensiones de VS Code
Las vulnerabilidades en las extensiones de VS Code no son una preocupación meramente teórica. En mayo de 2021, Snyk descubrió vulnerabilidades de seguridad en la cadena de suministro en extensiones de Visual Studio Code disponibles en el marketplace de extensiones de VS Code, que afectan a más de 2,000,000 de desarrolladores según el número 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, representan una amenaza real para los desarrolladores. Si un atacante engaña a un desarrollador para que haga clic en un enlace, podría introducir una vulnerabilidad de recorrido de rutas que permita acceder a archivos e información confidenciales en su entorno de desarrollo. En los casos más graves, basta con que los desarrolladores hagan clic en un enlace para que los atacantes puedan ejecutar comandos de forma remota.
En el siguiente video se muestra por qué la seguridad de la cadena de suministro de software y los SBOM son una preocupación fundamental para los desarrolladores. Se demuestra cómo se explota la extensión Instant Markdown de VS Code y cómo roba claves SSH confidenciales de un desarrollador:
Vulnerabilidades de seguridad que afectan a los IDE de Java
Si crees que la seguridad de la cadena de suministro está causando estragos en el ecosistema de JavaScript, quiero compartir contigo la cronología de ENISA de 24 incidentes de seguridad en la cadena de suministro ocurridos en apenas 18 meses (de enero de 2020 a julio de 2021). Entre ellos hay casos de incidentes maliciosos de seguridad en la cadena de suministro que afectaron a desarrolladores de Java a través del IDE NetBeans:
Cómo mantener un SBOM seguro de código abierto
Entonces, ¿cómo puedes mitigar los riesgos de seguridad de la cadena de suministro de software a lo largo de todo el ciclo de vida del desarrollo de software (SDLC)? Mantener un SBOM actualizado no solo es un buen comienzo, sino que además es un requisito de la orden ejecutiva del gobierno de Estados Unidos, debido al enorme panorama de amenazas que los componentes de software de código abierto representan para empresas y gobiernos por igual.
Un aspecto importante de la seguridad de la cadena de suministro de código abierto no es solo el panorama de amenazas derivado de vulnerabilidades de seguridad conocidas y posibles ataques de día cero, sino también el estado general de los paquetes. Las señales relacionadas con la frecuencia de confirmaciones y lanzamientos del proyecto, la cantidad de problemas abiertos y la comunidad general de colaboradores que participan en el proyecto contribuyen a la puntuación del estado general del paquete. Estas señales deben orientar la evaluación del mantenimiento general del proyecto y de su susceptibilidad a actividades maliciosas.
Snyk creó Snyk Advisor para resolver este problema específico relacionado con la evaluación del estado de los paquetes en la seguridad de la cadena de suministro de software de código abierto. Actualmente, ofrece metadatos de ecosistemas como JavaScript, Go y Python, además de imágenes de contenedores basadas en Docker. Te recomendamos ampliamente consultarlo al buscar bibliotecas de código abierto.
Cómo generar un SBOM de código abierto con Snyk
Snyk Open Source trabaja con manifiestos de paquetes y archivos de bloqueo para crear un grafo completo de dependencias, lo que ayuda a identificar vulnerabilidades en la jerarquía y otros problemas, como paquetes obsoletos. Sin embargo, eso por sí solo no constituye un SBOM.
Gareth Rushgrove, vicepresidente de producto en Snyk, escribió sobre cómo avanzar en los estándares de SBOM con Snyk y SPDX. En este artículo, Gareth cuenta que Snyk está explorando varias formas de trabajar con herramientas de la comunidad y destaca snyk2spdx, un proyecto de código abierto que convierte la salida de Snyk CLI al formato SPDX.
Si te gusta la API de Snyk, Gareth también destaca que puedes usarla para obtener el manifiesto del paquete subyacente y los detalles de vulnerabilidades como fuente de consumo, y luego convertirlos al formato SPDX.
En resumen, exigir un SBOM como parte del proceso de desarrollo y entrega de software es un aspecto importante de las preocupaciones actuales sobre la seguridad de la cadena de suministro. Ayuda a responder preguntas sobre todo, desde el inventario hasta la integridad y la procedencia.
Te recomendamos ampliamente los siguientes artículos para profundizar tus conocimientos sobre la seguridad de la cadena de suministro de software de código abierto y la lista de materiales de software:
Cómo entender los requisitos de seguridad de la cadena de suministro de software de la orden ejecutiva de ciberseguridad, por Daniel Berman
Para conocer en detalle la comparación de licencias, consulta la documentación sobre Licencias de código abierto: tipos y comparación
Cómo gestionar el cumplimiento de licencias en toda tu organización con las políticas de licencias de Snyk, por Josepha Riveros
Explora una gestión práctica de políticas de licencias en la plataforma Snyk en la documentación de Snyk
Protege tus dependencias de código abierto
Las herramientas de Snyk, diseñadas para desarrolladores, generan pull requests de corrección con un clic para dependencias vulnerables de código abierto y sus dependencias transitivas.