Los días del desarrollo de aplicaciones monolíticas están o en fase final o casi han terminado. La necesidad universal por innovar (como factor diferencial), así como la reducción de costes en la creación de funcionalidad innovadora basado en la reutilización de código existente (librerías de código), hace que el uso de componentes creadas por terceros se haya convertido en elemento esencial del desarrollo moderno.
La importancia del Open Source
Cuando hablamos de estas “terceras personas”, generalmente hablamos de comunidades opensource (OSS) que trabajan en sus proyectos, pero aquí es importante tener en cuenta las magnitudes de lo que hablamos: en el año 2021, las comunidades que trabajaron en los repositorios más populares (Java, JavaScript, Python y .NET) crearon más de 6,3 millones de versiones de librerías, y más de 720.00 nuevos proyectos según datos de Sonatype en su análisis “State of the Software Supply Chain”.
Si a esto añadimos que sobre todos estos repositorios se realizaron más de 2,2 trillones de peticiones de descargas, entonces entendemos más aún la importancia de lo que estamos hablando.
Seguridad en las comunidades OpenSource
Existen problemáticas que afectan a este modelo, y que surgen bien a través de un mal diseño de estos componentes, o por carencias no detectadas durante las fases de prueba, o por acciones intencionadas (los chicos malos…) que introducen modificaciones que hacen que estos componentes sean vulnerables frente a posteriores ataques.
Por ello, estamos obligados a disponer de mecanismos que nos permitan controlar estos riesgos, pues en total, durante el año 2021 se incrementaron en un 650% los ataques que hacían uso de componentes provenientes de estas fuentes y que estaban afectados por este tipo de problemáticas.
Existe lógicamente un interés creciente por conocer el estado en el que se encuentran las aplicaciones propias y/o de terceros en relación a las librerías o componentes OSS que incorporan, sobre todo si tenemos en cuenta las últimas noticias relacionadas con librerías java en las que se han encontrado importantes vulnerabilidades (log4Shell y SpringShell).
Cuando se hace pública una noticia como esta, lo primera duda que nos asalte probablemente sea ¿cómo me afecta esto? De ahí la importancia de disponer de un inventario que nos permita saber qué componentes OSS utilizamos, sus versiones, si están sujetos a algún tipo de licenciamiento, y por supuesto, si están afectados por algún tipo de vulnerabilidad.
El inventario SBOM
Para poder enender de forma claro la necesidad del SBOM (Software Bill of Materials), estos serían ejemplos de casos de uso:
• Declaración de estado frente al lo establecido en el licenciamiento de las dependencias.
• Declaración de estado frente a la exposición de vulnerabilidades de seguridad.
• Declaración de estado frente a las listas de exclusión de los componentes a emplear.
• Visibilidad transversal de los anteriores apartados (licenciamiento, seguridad,…) para todas las aplicaciones.
• Proactividad de cara a identificar alternativas para componentes que van a dejar de ser utilizados.
Gartner destaca como especialmente importante el incluir este SBOM dentro de nuestro ciclo de vida del desarrollo del SW. Según la misma fuente, actualmente solo el 30% de las herramientas de SCA gestionan (es decir, generan y verifican) un SBOM, porcentaje que se estima crecerá hasta un 90% en 2024.
El éxito de los SBOM depende de cuatro factores clave:
• el intercambio de datos
• la automatización del flujo de trabajo
• la estandarización del intercambio de datos
• la adaptabilidad a las nuevas arquitecturas de aplicación
Estándares SBOM
La falta de formatos estandarizados de intercambio de datos impide compartir los SBOM entre equipos, socios, proveedores y clientes, y surgen una serie de estándares enumerados a a continuación (incluyendo fabricantes que lo han adoptado):
• Software Package Data Exchange [SPDX]: Sonatype, Synopsys, GitLab.
• Software Identification [SWID]: GitLab.
• CycloneDX: Veracode, GitLab y Synopsis
Con SBOM se alcanza el máximo valor cuando todos los participantes en la cadena de suministro se adhieren a las normas acordadas.
Lograr este consenso puede llevar un tiempo, debido al gran volumen de software y herramientas que ya se utilizan o que están surgiendo, pero es importante tener en cuenta que ya existen normativas relacionadas con este SBOM y que nos pueden obligar, como la reciente U.S. Cybersecurity Executive Order o la propuesta UK Government Cyber Security Strategy: 2022 to 2030.
Nuestras recomendaciones como expertos
Desde atSistemas os hacemos dos recomendaciones fundamentales:
• La primera: asegurar que disponemos de un SBOM para cada una de las aplicaciones.
• La segunda: reforzar los mecanismos de gestión de dependencias, de modo que podamos mantener bajo control el estado en el que nos encontramos frente a incumplimientos, vulnerabilidades, o componentes que estén sujetos a algún tipo de riesgo.