COMENTARIO
Se acerca el SBOM y no hay vuelta atrás. Creado originalmente por la Administración Nacional de Información y Telecomunicaciones (NTIA), SBOM pasó de ser un nicho a obligatorio en un abrir y cerrar de ojos. Las agencias federales y los equipos de seguridad ahora exigen SBOM de proveedores externos como parte de sus procesos de auditoría y aprobación. Cada vez más empresas están agregando la generación SBOM a su lista de verificación de seguridad para todos los componentes incluidos, incluso para proveedores de software como servicio (SaaS). Es lógico. El aumento de ataques maliciosos a la cadena de suministro, como Log4j y xz, resalta la necesidad de SBOM.
Sin embargo, hasta la fecha, SBOM no ha cumplido sus promesas debido a estándares competitivos y diferentes métodos de implementación en una amplia variedad de herramientas. Estos problemas han convertido lo que se suponía era un estándar de oro para la transparencia en un ejercicio confuso en ETL y gestión de esquemas de datos. No es algo bueno. Los SBOM son esenciales para el futuro de la ciberseguridadEl mundo de la tecnología debe reconocer la importancia crítica de SBOM y adoptar un formato unificado e integral. Así es como podemos lograrlo.
Defensa de un estándar SBOM unificado
El concepto SBOM apareció a principios de la década de 2000 como un “catálogo de componentes” para software, inspirado en la industria manufacturera. La visión se expandió más allá de una simple lista para incluir un mecanismo programático para verificar automáticamente los componentes de software, sus versiones y sus estados de seguridad. Este sistema permitiría detectar Problemas como ataques tipográficos.donde los desarrolladores descargan inadvertidamente paquetes maliciosos y ataques más complejos como el incidente xz, donde los atacantes acceden a repositorios confiables y realizan cambios sutiles. Una SBOM permitiría identificar y rastrear rápidamente la exposición, una capacidad crítica destacada por el ataque log4jdonde los equipos lucharon por localizar la biblioteca vulnerable en sus sistemas.
Las tendencias de la última década han hecho que las SBOM sean más urgentes. El desarrollo de software ha pasado de bases de código patentadas monolíticas a una gran dependencia del código abierto, incluidas bibliotecas y módulos. Cada capa de la pila de software ahora presenta de manera destacada componentes de código abierto. Los microservicios y el movimiento de giro a la izquierda han agregado más componentes a la cadena de suministro de software, dividiendo las aplicaciones en partes más pequeñas y permitiendo a los equipos elegir sus componentes. Como resultado, una parte importante de las aplicaciones modernas son creadas y controladas por terceros, cuya confiabilidad y confiabilidad pueden variar.
Conciliar normas contrapuestas es costoso y lleva mucho tiempo
Han surgido dos estándares SBOM importantes, cada uno de ellos respaldado por grupos industriales influyentes. SPDX (Software Package Data Exchange), introducido en 2010 por la Fundación Linux, comunica información SBOM detallada, incluidos componentes, licencias, derechos de autor y credenciales de seguridad. CycloneDX, desarrollado por OWASP en 2017, es otro estándar SBOM diseñado para una fácil integración en herramientas y procesos de desarrollo existentes. En teoría, estos estándares son compatibles y pueden coexistir en la misma pila de seguridad empresarial. En la práctica, esto rara vez ocurre.
Las organizaciones a menudo enfrentan desafíos importantes al combinar o intercambiar datos entre los formatos SPDX y CycloneDX debido a sus diferentes estructuras, áreas de enfoque y niveles de detalle. SPDX, basado en el cumplimiento de licencias de código abierto, proporciona datos completos de componentes hasta detalles a nivel de archivo y fragmentos de código. Por el contrario, CycloneDX, de la comunidad de seguridad, está optimizado para la identificación y análisis de vulnerabilidades, con elementos sólidos como firmas digitales y datos de explotación de vulnerabilidades. Mapear campos y traducir información entre estos formatos puede ser complejo, especialmente para SBOM grandes y complejos. Cambiar los esquemas de datos puede interrumpir los esfuerzos de integración o confundir las herramientas posteriores, como las plataformas de cumplimiento, los sistemas SIEM o SOAR.
Además, las limitaciones de las herramientas, el control de versiones de formatos, las diferencias en la profundidad de la información y las preferencias organizacionales por formatos específicos complican aún más los esfuerzos de interoperabilidad. Aunque la versión de la NTIA promueve la coherencia entre los estándares SBOM, las diferencias inherentes entre SPDX y CycloneDX siguen siendo difíciles de conciliar. La naturaleza minimalista de los requisitos de SBOM deja mucho margen de interpretación, lo que lleva a implementaciones divergentes en todas las industrias, incluso si siguen los mismos componentes de software.
Cree un cuerpo de estándares e incline la balanza
Desde 5G hasta HTML y contenedores, los estándares únicos garantizan que la funcionalidad principal sea compatible y conforme. El primer paso para que esto suceda en el caso de las SBOM es reconocer su importancia crítica. Luego, se debe designar una única organización sectorial o colaborativa para unificar los estándares. Es probable que este proceso sea lento y complicado debido a la diversidad de intereses involucrados. Una buena analogía es el trabajo en curso del World Wide Web Consortium (W3C) en torno a los estándares web. Como primer paso, este esfuerzo debería reconciliar los orígenes en competencia de las principales SBOM en una visión más clara y una declaración distinta de lo que una SBOM debería lograr.
La participación de todo el sector es crucial, pero la implicación de los principales actores es esencial. Los hiperescaladores de la nube, las grandes empresas de ciberseguridad y los gigantes de las herramientas para desarrolladores (como GitHub, GitLab, Atlassian, Microsoft y Google) deben participar porque los desarrolladores, las operaciones de seguridad, DevOps y los equipos de plataforma son los principales consumidores y usuarios de cualquier formato SBOM unificado. La prueba definitiva es si el nuevo formato SBOM reduce la carga de trabajo y mejora la seguridad y la transparencia en comparación con los SBOM actuales. Los efectos de red y los estándares de cumplimiento, como SOC2 o ISO, que favorecen un nuevo estándar unificado influirían fuertemente en la adopción y podrían potencialmente inclinar la balanza hacia un enfoque unificado.
Un estándar SBOM unificado es esencial para aprovechar plenamente el potencial de los SBOM para mejorar la seguridad de la cadena de suministro de software. Al simplificar con un único estándar, los fabricantes de herramientas y los equipos de desarrollo podrían ahorrar esfuerzos y recursos considerables. Superar los desafíos que plantean los múltiples estándares y la fragmentación promovería la claridad, la coherencia, la interoperabilidad y, en última instancia, un ecosistema de software más seguro.
