Con la presión continua para mantener los sistemas seguros y sin que se reduzca el panorama general de las amenazas, una Software Bill of Materials (SBOM) legible por una máquina puede ayudar a los equipos a mantenerse al tanto de los problemas de seguridad en las librerías de las que dependan. Desde que la Executive Order original fue publicada, la industria ha ganado claridad y entendimiento de lo que es SBOM y cómo crear uno; el Instituto Nacional de Estádares y Tecnología (INET), por ejemplo, ahora tiene más consejos específicos sobre como seguir con la norma. Hemos tenido experiencia en producción utilizando SBOMs en proyectos que van desde pequeñas compañías hasta en grandes multinacionales e incluso en departamentos gubernamentales, y estamos convencidos de que ofrecen un beneficio. Muchas organizaciones y gobiernos deberían considerar exigir SBOMs para el software que utilizan. La tecnica será fortalecida por nuevas herramientas que continuan apareciendo, como Android Firebase BOM que automáticamente alinea las dependencias de las librerías de una aplicación con las que aparecen listadas en la BOM
Con la continua presión de mantener los sistemas seguros y sin reducción en el panorama general de amenazas, un machine-readable Software Bill of Materials (SBOM) puede ayudar a los equipos a estar al tanto de los problemas de seguridad de las librerías en las que confían. El más reciente, el día cero del exploit remoto Log4Shell fue critico y ampliamente conocido. Si los equipos hubieran tenido un SBOM listo, este hubiera escaneado y corregido rápidamente el mismo. Ahora hemos tenido experiencia en ambientes de producción usando SBOMs en proyectos que se encuentran tanto en compañías pequeñas como en grandes multinacionales, hasta en departamentos de gobierno, y estamos convencidos que proveen beneficios. Herramientas como Syft hacen fácil el uso de SBOM para detectar vulnerabilidades.
En mayo del 2021, la Casa Blanca de los Estados Unidos publicó la Orden Ejecutiva sobre la Mejora de la Ciberseguridad de la Nación. El documento propone varios mandatos técnicos que se relacionan a ítems que hemos presentado en Radares anteriores, como es la Arquitectura de Confianza Cero y el Escaneo Automatizado de Cumplimiento usando la política de seguridad como código. Gran parte del documento está dedicado a mejorar la seguridad del software de la cadena de suministro. Un ítem en particular que llamó nuestra atención fue el requerimiento de que el software del gobierno debería contener un lista de materiales de software (SBOM) legible por máquina, definido como “un registro formal conteniendo los detalles y las relaciones de la cadena de suministro de varios componentes utilizados en la construcción de software.” En otras palabras, debería detallar no solamente los componentes enviados sino también las herramientas y marcos utilizados para entregar el software. Esta orden ejecutiva tiene el potencial de marcar el comienzo de una nueva era de transparencia y apertura en el desarrollo de software. Esto indudablemente tendrá un impacto en aquellos de nosotros que producimos software como una forma de vida. Muchos, sino todos los productos de software producidos hoy contienen componentes open source o los utilizan en el proceso de desarrollo. A menudo, el consumidor no tiene forma de saber cuál versión de cuál paquete podría tener un impacto en la seguridad de su producto. En cambio, ellos deben confiar en las alertas de seguridad y parches proporcionados por el proveedor minorista. Esta orden ejecutiva asegurará que una descripción explícita de todos los componentes se ponga a disposición del consumidor, empoderándolos para implementar sus propios controles de seguridad, y como el SBOM es legible por máquina, esos controles pueden ser automatizados. Sentimos que este movimiento también representa un cambio hacia adoptar software open source y prácticamente considerando ambos, los riesgos y los beneficios de seguridad que este provee.
