Desde nuestro primer blip sobre Software Bill of Materials (SBOM) en 2021, la generaci¨®n de SBOM ha pasado de ser una pr¨¢ctica emergente a una pr¨¢ctica por defecto en nuestros proyectos. El ecosistema ha madurado significativamente, ofreciendo un conjunto de herramientas robusto y una integraci¨®n fluida con CI/CD. Herramientas como Syft, Trivy y Snyk permiten la generaci¨®n integral de SBOM, desde el c¨®digo fuente hasta las im¨¢genes de contenedores, adem¨¢s de escaneo de vulnerabilidades. Plataformas como FOSSA y Chainloop mejoran la gesti¨®n de riesgos de seguridad al integrarse con los flujos de desarrollo y reforzar pol¨ªticas de seguridad. Aunque un est¨¢ndar universal para SBOM sigue en evoluci¨®n, el amplio soporte para y CycloneDX ha reducido los desaf¨ªos de adopci¨®n. Los sistemas de IA tambi¨¦n requieren SBOM, como lo demuestran el del gobierno del Reino Unido y el de CISA. Seguiremos monitoreando los avances en este ¨¢mbito.
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 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 °Õ±ð³¦²Ô´Ç±ô´Ç²µ¨ª²¹ (INET), por ejemplo, ahora tiene m¨¢s 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 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 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 . 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.
