Sobre SBOMs, BitBucket y OWASP Dependency Track

Tutoriales

El museo de arquitecturas antiguas y nuevas con el que estoy involucrado me obligó a investigar cómo protegerlas. Por ejemplo, una antigua dependencia puede volverse CVE o un sólido proyecto de código abierto puede volverse comercial. Es aquí donde surge el concepto de un Registro de Materiales de Software (SBOM) para catalogar la licencia y el ecosistema de dependencias de los sistemas. Este artefacto de construcción, a su vez, se analiza para determinar si los componentes que lo constituyen son:

  1. Vulnerables a la explotación, o
  2. Con licencias en condiciones desfavorables, como ser demasiado comerciales o demasiado predatorias.

Este artículo explicará cómo controlar dicha vulnerabilidad utilizando:

  1. BitBucket pipes para la generación de SBOM, y 
  2. Cómo OWASP’s Dependency Track puede analizarlo. 

Conoce tu riesgo

No saber lo que acecha en tu código y contenedores es una bendición, pero peligroso. Sin embargo, pasar todos tus componentes por un analizador de dependencias puede dar una retroalimentación abrumadora. Es mejor tener un panel de control e inculcar en la cultura del equipo que la cantidad de problemas de dependencias siempre debe ser menor hoy que ayer.

Wikipedia afirma que: “El Proyecto Abierto Mundial de Seguridad de Aplicaciones Web (OWASP) es una comunidad en línea que produce artículos, metodologías, documentación, herramientas y tecnologías de forma gratuita en los campos de IoT, software de sistema y seguridad de aplicaciones web.” Por lo tanto, no es sorprendente que proporcionen una plataforma para rastrear y analizar vulnerabilidades en sistemas. Su característica más llamativa es su panel principal:

El gráfico más grande en el medio muestra el número de vulnerabilidades para todos los proyectos que se están rastreando. Las métricas sobre vulnerabilidades críticas, medias y bajas se muestran justo debajo. Dependency Track recupera vulnerabilidades conocidas de una o más fuentes. La más notable de estas es la lista de Vulnerabilidades y Exposiciones Comunes (CVE) de la Base de Datos Nacional de Vulnerabilidades de Estados Unidos. A cada CVE se le asigna un nivel de criticidad que va desde desconocido y bajo hasta crítico. Este análisis de riesgo es realizado por Dependency Track a intervalos regulares en segundo plano utilizando el Software Bill of Material (SBOM) relevante como entrada.

La sección directamente debajo del gráfico más grande detalla las violaciones de políticas, con políticas configuradas de acuerdo a lo que uno considera importante. Se pueden registrar ciertas dependencias como no deseadas, o se puede exigir que ciertas licencias o incluso grupos de licencias se muestren en el panel y se informen. Este mecanismo de retroalimentación es configurable por política.

La sección superior luego muestra las vulnerabilidades de la cartera, proyectos en riesgo, componentes vulnerables y una puntuación de riesgo a lo largo del tiempo.

Hay más vistas, gráficos y estadísticas como el progreso en la auditoría, vulnerabilidades por proyecto a lo largo del tiempo y vulnerabilidades por componente a lo largo del tiempo, entre otros, pero prefiramos centrarnos en cómo BitBucket puede generar y enviar el SBOM a Dependency Track.

BitBucket Prepara el SBOM

La preparación del SBOM ocurre en el pipeline CI/CD de BitBucket que se ejecuta después de que se fusionan las solicitudes de extracción en la rama principal. Esto asegura que los paneles de control estén siempre actualizados con el estado de los asuntos. 

Usé un pipe de BitBucket que envuelve syft para generar un SBOM CycloneDX. Los comandos de syft para las interrogaciones de código y contenedores difieren ligeramente.

Análisis de Código

El comando de syft para analizar el código desde la raíz de tu proyecto es el siguiente:  

syft --output cyclonedx-json=code-cdx-sbom.json -v --java-use-network true .

Este comando genera el SBOM en un archivo llamado code-cdx-sbom.json y utiliza la red para obtener información de licencias desde internet; por ejemplo, desde los repositorios Maven centrales.

El tubo de BitBucket de syft de shiftleftcyber (¡gracias!) luego se configura en el bloque de script del pipeline de BitBucket para envolver este comando syft de la siguiente manera:

YAML

 

El readme del proyecto syft enumera una impresionante variedad de lenguajes compatibles, pero solo lo usé en Java y JavaScript con un proyecto de Python en la lista de pendientes.

¿Qué acecha en tus contenedores?

Para escanear un contenedor desde tu registro, se ejecuta el siguiente comando dentro del alcance de un “docker login”:

syft --output cyclonedx-json=container-cdx-sbom.json docker.s2c.co.za/container:latest --from registry

El tubo correspondiente de BitBucket es:

YAML

 

El interruptor all-layers instruye a syft a inspeccionar todas las capas de la imagen del contenedor y no solo el producto final.

BitBucket como el Medio de Depósito

Todo lo que queda es para Dependency Track para ingerir el SBOM. Usé el tubo hermano del tubo de BitBucket que generó el SBOM:

YAML

 

Especifiqué tres parámetros de entrada:

  1. URL de la instancia de Dependency Track
  2. El ID del proyecto de Dependency Track para cargar el SBOM
  3. La clave API para autorizar la carga

El ID del proyecto se puede encontrar fácilmente haciendo clic en “Ver detalles” desde la vista del proyecto:

Seguido de copiar el Identificador de Objeto en la parte inferior:

La clave API se encuentra en el campo de entrada con el mismo nombre del equipo de Automatización, accesible desde el menú Administración del panel izquierdo:

Conclusión

Los incidentes pasados enseñaron que la explotación de vulnerabilidades tiende a resultar en interrupciones del servicio que pueden afectar a sistemas o industrias vecinas. Esto causa gastos inesperados y inconvenientes. Recuperarse de ello desviará a los desarrolladores y recursos de los objetivos del equipo.

La licencia de un proyecto abierto, además, puede volverse comercial y resultar en que una organización se vea obligada a pagar tarifas de licencia retroactivas. Por otro lado, se pueden hacer demandas para abrir la propiedad intelectual crítica utilizada para obtener una ventaja competitiva debido a condiciones de licencia depredadoras.

Por lo tanto, es responsabilidad de cada desarrollador implementar y apoyar estrategias activas para contrarrestar estos riesgos. Si tu código está en BitBucket, el enfoque descrito anteriormente puede ayudar a tu(s) sistema(s) a alinearse con el programa. Sin embargo, la API de Dependency Track no limita el acceso exclusivamente a BitBucket y debe haber formas de obtener la Factura de Materiales de Software desde otras tecnologías de pipeline CI/CD.

Source:
https://dzone.com/articles/on-sboms-bitbucket-and-owasp-dependency-track