Reduce el riesgo de tu cadena de suministro con una lista de materiales de software (SBOM)
7 de junio de 2023
0 minutos de lecturaHoy nos entusiasma lanzar algunas funciones nuevas como parte de nuestros esfuerzos continuos en nuestra solución Software Supply Chain Security. Estas herramientas diseñadas primero para desarrolladores te ayudan a comprender mejor la cadena de suministro de tus aplicaciones, identificar posibles riesgos y tomar las medidas necesarias para anticiparte a ellos.
El auge de las SBOM como componente clave de la seguridad de la cadena de suministro
Las aplicaciones modernas se ensamblan más de lo que se construyen: el software libre y de código abierto representa más del 70 % del software moderno. Aunque usar código abierto en tu aplicación puede reducir el tiempo de comercialización, también puede introducir complejidades y riesgos en tu cadena de suministro.
En respuesta a las recientes directrices regulatorias diseñadas para ayudar a las organizaciones a protegerse, muchos equipos están incorporando la creación de listas de materiales de software (SBOM) a su SDLC.
A modo de recordatorio, una SBOM es un inventario de los componentes que conforman tu aplicación y sus dependencias. Puedes pensar en ella como el equivalente de la «lista de materiales» que se usa en la fabricación y que informa a los compradores sobre las piezas utilizadas en un producto específico. Los formatos estandarizados para SBOM, como CycloneDX y SPDX, permiten que este inventario sea legible para las personas y procesable por las herramientas posteriores.
Para los equipos de seguridad de aplicaciones (AppSec), esta visibilidad de la composición en toda la empresa es un paso importante para comprender y mitigar los riesgos de los ataques a la cadena de suministro, sin dejar de cumplir con los requisitos regulatorios.
Pero ¿cómo puedes adoptar estas prácticas? ¿Y qué impacto tienen en los flujos de trabajo de tus desarrolladores?
En el pasado, mejorar la postura de seguridad podía ralentizar a los equipos de desarrollo. Pero creemos firmemente que los desarrolladores no deberían tener que elegir entre innovación y seguridad. Snyk facilita la creación de una SBOM para tus aplicaciones y te da visibilidad sobre sus componentes básicos (por ejemplo, componentes de código abierto, bibliotecas y marcos de trabajo) y cómo funcionan en conjunto.
Ahora disponible de forma general, Snyk ofrece herramientas de CLI diseñadas primero para desarrolladores, que permiten generar SBOM en formato SPDX o CycloneDX de forma local o desde tus pipelines de CI/CD.
Con la API Project SBOM —también disponible de forma general— puedes generar una SBOM para cualquier proyecto de código abierto o contenedor que hayas importado a Snyk desde un único endpoint de API.
Ejemplo de un paquete dentro de una SBOM
Usa las SBOM para identificar riesgos y tomar medidas
Generar una SBOM es un paso importante para obtener visibilidad y cumplir con los requisitos, pero es solo una parte de la ecuación. Los artefactos SBOM a menudo no proporcionan información práctica a los consumidores posteriores.
Como desarrollador o profesional de AppSec, también necesitas probar las SBOM y su contenido para identificar posibles problemas y resolverlos más rápido. A medida que la generación de SBOM se adopte más ampliamente en tu organización y empieces a recibir SBOM de proveedores (por ejemplo, de SaaS), probablemente tendrás que probar distintos formatos generados por diferentes herramientas.
Incluso podrías querer crear una plataforma para administrar todo esto en los distintos equipos de tu empresa.
A principios del tercer trimestre, lanzaremos la versión beta de nuestra función de pruebas de SBOM. Con esta API, puedes analizar y probar SBOM en formato CycloneDX y SPDX para detectar vulnerabilidades conocidas y problemas de licencias en nuestra base de datos de vulnerabilidades líder.
Además, con la API Package Issues, ya disponible de forma general, te ofrecemos herramientas para consultar vulnerabilidades a nivel de paquete mediante la URL del paquete (purl), con compatibilidad con distintos ecosistemas de lenguajes y sistemas operativos. Una API detallada y de bajo nivel les da a los equipos la flexibilidad para adaptar las pruebas a sus necesidades.
Ejemplo de consulta de problemas de un paquete
Puedes consultar un solo paquete con una solicitud GET y una purl codificada como URL:
Ejemplo de vulnerabilidad devuelta (fragmento)
Amplía el valor de las SBOM
La transparencia sobre la composición de una aplicación tiene valor por sí sola, pero los artefactos SBOM suelen contener un conjunto limitado de información.
Aunque esa información sirve como entrada para las pruebas de vulnerabilidades, deja mucho que desear: quienes consumen los artefactos aún tienen que usar la SBOM para obtener la información que necesitan.
Si podemos crear SBOM y probarlas junto con sus componentes, ¿por qué no incluir esta información directamente en el artefacto? Con Parlay, la más reciente contribución de Snyk a la comunidad de código abierto, queremos resolver precisamente ese problema.
Los formatos líderes (CycloneDX y SPDX) ya permiten extender sus esquemas, lo que hace posible enriquecer una SBOM con metadatos adicionales, como vulnerabilidades y procedencia del código fuente.
Esto beneficia enormemente a los consumidores posteriores, como los equipos de AppSec, que reciben una instantánea de la aplicación en un momento determinado, junto con datos enriquecidos que ayudan a automatizar acciones o fundamentar la toma de decisiones.
Consulta este blog para obtener más información sobre las posibilidades que ofrece este proyecto y visita la grabación a pedido de SnykLaunch para conocer todos los detalles que te perdiste.
