Una SBOM, o lista de componentes de software, es una lista de los componentes y las dependencias que conforman un producto de software concreto. Incluye todas las bibliotecas, módulos, marcos de trabajo y demás recursos externos necesarios para desarrollar el software, así como las relaciones entre ellos. En esencia, una SBOM representa la cadena de suministro digital de un sistema de software. Y ahora es un requisito obligatorio para todos los proveedores que vendan software al Gobierno federal. Cualquier otra persona que desarrolle o gestione software también puede beneficiarse de ello.
Las listas de materiales de seguridad (SBOM) forman parte de la comunidad de código abierto desde hace más de una década, pero han suscitado un mayor interés en los círculos de ciberseguridad desde la oleada de ataques a la cadena de suministro de software contra empresas y organismos gubernamentales estadounidenses en 2020 y 2021.
El ataque informático a SolarWinds —en concreto, el caso de «»—, en el que varias agencias federales, entre ellas el Departamento de Seguridad Nacional y el Departamento del Tesoro, habían implementado sin saberlo un componente infectado con un troyano que permitió a los atacantes acceder a los sistemas informáticos de las víctimas, dio lugar a una orden ejecutiva en May 2021 que exige que cualquier proveedor que venda software al Gobierno federal detalle sus componentes en una SBOM.
Debido a la complejidad de la cadena de suministro de software, un solo componente de software puede tener un impacto desproporcionado en su seguridad. Sin embargo, los usuarios tienen una visibilidad mínima de los componentes integrados en sus aplicaciones más críticas para el negocio. Disponer de una lista de los «ingredientes» de los productos puede ofrecerles una idea más clara de sus riesgos de seguridad y les proporciona una guía para detectar las vulnerabilidades antes de que provoquen una crisis.
¿Cuál es el origen de la SBOM?
El nuevo énfasis en las SBOM se deriva de la Orden Ejecutiva (OE) n.º 14028 del presidente Biden, « » (Mejorar la ciberseguridad de la nación) ( ), que encarga al Instituto Nacional de Estándares y Tecnología (NIST) y a otras agencias federales que mejoren la ciberseguridad mediante una variedad de iniciativas relacionadas con la seguridad y la integridad de la cadena de suministro de software, con el fin de proteger mejor las redes del Gobierno federal.
La orden ejecutiva fue, en gran medida, una respuesta al aumento de los ciberataques contra empresas estadounidenses y el Gobierno de los Estados Unidos en los años 2020 y ’21. Los ataques durante ese periodo fueron más frecuentes y más graves, y dos de los más perjudiciales —el de SolarWinds y el ataque de ransomware contra Colonial Pipeline, — impulsaron la emisión de la orden ejecutiva.
En el ataque a SolarWinds, un único componente infectado con un troyano del software Orion de esta empresa con sede en Texas —que se utiliza para supervisar y gestionar redes e infraestructuras de TI— permitió a los piratas informáticos acceder a los sistemas de miles de organizaciones, entre las que se incluyen empresas de la lista Fortune 500 , múltiples organismos del Gobierno federal e incluso la propia empresa de ciberseguridad estadounidense que, finalmente, detectó la filtración. Hasta 18,000 víctimas de , tanto del sector privado como del público, descargaron el software infectado, aunque el número de personas que resultaron afectadas posteriormente fue menor.
El ataque de ransomware contra Colonial Pipeline tuvo como objetivo una única organización, pero tuvo repercusiones de gran alcance en las infraestructuras del país. Cuando la empresa, que suministra aproximadamente el 45 % del combustible de la costa este, descubrió el ataque, se vio obligada a desconectar los sistemas informáticos críticos para contener la amenaza, lo que supuso, en la práctica, la paralización de sus operaciones. La escasez de combustible resultante provocó una oleada de compras motivadas por el pánico y un repunte en los precios de la gasolina.
[Lea también: Qué supone el decreto ejecutivo de Biden para los directivos del sector tecnológico]
La orden ejecutiva recoge las lecciones aprendidas de estos y otros incidentes de seguridad y tiene por objeto fomentar la colaboración entre el sector público y el privado para mitigar los ciberataques, cada vez más sofisticados. En concreto, en él se esbozan varios objetivos:
- Mejorar el intercambio de información —La Orden Ejecutiva ordena que se eliminen todas las barreras contractuales que impidan el intercambio de información sobre amenazas entre el Gobierno y el sector privado, y exige que los proveedores de servicios de tecnologías de la información compartan información sobre amenazas, vulnerabilidades e incidentes que puedan afectar al Gobierno federal.
- Modernizar la ciberseguridad del Gobierno —La orden ejecutiva encarga al Gobierno federal que establezca normas de ciberseguridad más estrictas y mejores prácticas. Entre ellas se incluyen la adopción de servicios en la nube seguros ,; la aplicación de un modelo de seguridad de «confianza cero» , ; y la implementación de la autenticación multifactorial (MFA) , , así como de rutinas de cifrado.
- Reforzar la seguridad de la cadena de suministro de software —El Gobierno va a establecer normas básicas de seguridad en el desarrollo de software para el software que adquiera a sus contratistas. El Departamento de Comercio y la Administración Nacional de Telecomunicaciones e Información (NTIA) deben publicar los elementos que componen una lista de materiales de software en la que se enumeren y detallen los componentes individuales que conforman un producto de software.
- Crear una comisión de revisión de la seguridad cibernética —El Gobierno creará una comisión de revisión de la seguridad cibernética ( ) , que estará copresidida por expertos del Gobierno y del sector privado y que se reunirá tras cualquier incidente significativo de ciberseguridad para analizar lo ocurrido y formular recomendaciones destinadas a mejorar la seguridad.
[Lea también: El plan de acción del Gobierno de EE. UU. para reforzar las cadenas de suministro]
- Elabore un manual de respuesta ante incidentes —Los responsables de TI del Gobierno deben desarrollar un manual estándar para responder a incidentes de seguridad, con el fin de garantizar que todas las agencias federales puedan responder de manera eficaz a los ciberataques y subsanar los daños causados.
- Mejorar la detección de incidentes —La Orden Ejecutiva exige que se implemente en todo el ámbito gubernamental un sistema de detección y respuesta en terminales (EDR) de y que se mejore el intercambio de información dentro del Gobierno federal para lograr una mejor detección de los incidentes de ciberseguridad.
- Mejorar la investigación y la corrección —El Gobierno establecerá requisitos relativos a los registros de incidentes de ciberseguridad para todas las agencias federales, con el fin de mejorar la investigación y la corrección de los incidentes de ciberseguridad en las redes del Gobierno federal.
El decreto ejecutivo estableció una serie de objetivos inmediatos que deben cumplir varios organismos gubernamentales, pero está teniendo un efecto en cadena en toda la cadena de suministro de la contratación pública federal. En concreto, el decreto ejecutivo afecta a tres grupos:
- Los organismos ejecutivos federales —: los organismos gubernamentales de alto nivel tienen la responsabilidad de modernizar su entorno tecnológico y sus prácticas de seguridad.
- Contratistas federales —Los contratistas que operan con el Gobierno de los Estados Unidos, incluidos los proveedores de software comercial listo para usar (COTS), pueden esperar que se incorporen nuevas normas de ciberseguridad en las condiciones contractuales. Asimismo, se les exige que faciliten más información sobre los incidentes cibernéticos.
- Empresas privadas —Las empresas privadas estarán sujetas a una nueva legislación en materia de ciberseguridad y a una aplicación más estricta de las leyes y políticas vigentes, con un mayor énfasis en la seguridad de la cadena de suministro de software y en la notificación de incidentes cibernéticos. Asimismo, se hace mayor hincapié en la transparencia mediante la propuesta de un etiquetado de seguridad para los consumidores en el software y los dispositivos del Internet de las cosas (IoT), lo que da lugar a nuevos requisitos de seguridad y normas de evaluación para estos proveedores.
¿Por qué son importantes hoy en día las SBOM?
Las listas de componentes de software (SBOM) son importantes porque pueden ayudar a las organizaciones a identificar y corregir cualquier vulnerabilidad que pueda existir en su software y en sus dependencias. Las aplicaciones modernas se desarrollan utilizando una cadena de suministro de componentes de software tan compleja como las que utilizan los fabricantes de productos físicos. Una aplicación típica se crea a partir de docenas de componentes, utilizando una combinación de código propio y componentes reutilizables de terceros. Si bien un desarrollador puede revisar cualquier código que haya escrito para detectar errores y fallos, tiene menos visibilidad sobre el código de terceros. Los atacantes son conscientes de ello y se aprovechan de esta circunstancia, dirigiendo sus ataques a componentes de terceros, sabiendo que es probable que así logren eludir la detección.
«. Cuando se descubre o se da a conocer una vulnerabilidad, las SBOM pueden ayudar a determinar en qué partes de la organización se está utilizando esa versión de software.»
Además del ya tristemente célebre incidente de SolarWinds, una serie de ataques a la cadena de suministro ocurridos en los últimos años ha puesto de manifiesto los efectos devastadores que este tipo de situaciones pueden acarrear. Los atacantes aprovecharon una vulnerabilidad crítica en el software de código abierto Apache Log4j , una biblioteca de registro de actividades prácticamente omnipresente que registra las actividades de millones de aplicaciones basadas en Java. Los piratas informáticos también aprovecharon cuatro vulnerabilidades «zero-day» distintas de en Microsoft Exchange Server para acceder a las redes de 30,000 organizaciones estadounidenses.
Una SBOM puede ayudar a una empresa a protegerse mejor contra este tipo de ataques a la cadena de suministro y a establecer prioridades en su gestión de riesgos. Por ejemplo, puede utilizar las SBOM para, en primer lugar, eliminar el uso de bibliotecas con vulnerabilidades conocidas y, a continuación, asegurarse de que utiliza la última versión de cada biblioteca de código abierto. Cuando se descubre o se da a conocer una vulnerabilidad, las SBOM pueden ayudar a determinar en qué partes de la organización se está utilizando esa versión del software. En términos más generales, las SBOM permiten a las organizaciones tomar decisiones mejor fundamentadas sobre el software que utilizan y animan a los proveedores de software a crear productos más seguros.
¿Cuáles son los componentes de una SBOM?
En July 2021, la NTIA publicó «Los elementos mínimos para una lista de materiales de software» (The Minimum Elements For a Software Bill of Materials), en la que se describen los requisitos del programa « » del Gobierno federal para una SBOM. Divide los componentes básicos de una SBOM en tres categorías: campos de datos, soporte para la automatización y prácticas y procesos. A continuación, analizaremos cada uno de ellos con más detalle.
Campos de datos:
Los campos de datos deben identificar de forma eficaz cada componente, de modo que pueda supervisarse a lo largo de la cadena de suministro de software y cotejarse con las bases de datos de vulnerabilidades y licencias. La NTIA especifica siete campos de datos:
- Nombre del proveedor: El nombre de la organización que crea e identifica el componente.
- Nombre del componente: . El nombre asignado a una unidad de software por el proveedor original.
- Versión del componente: . Los detalles de la compilación y la versión del componente utilizado en un producto de software.
- Otros identificadores únicos: Claves de búsqueda y otra información, como un identificador procedente de el Diccionario CPE del NIST, que puede utilizarse para identificar un componente.
- Relación de dependencia: Descripción de las dependencias entre el componente y otro software. Por ejemplo, el componente A está incluido en el software B.
- Autor de los datos del SBOM: El nombre de la organización que ha creado los datos del SBOM del componente.
- Marca de tiempo: La fecha y la hora en que se recopilaron los datos de la SBOM.
Compatibilidad con la automatización:, ,
. Dado que no resulta viable que los profesionales de la seguridad busquen manualmente los componentes comprometidos en cada SBOM, la NTIA exige que todas las SBOM sean compatibles con la automatización a través de uno de estos tres formatos legibles por máquina:
- Cyclone DX
- Intercambio de datos de paquetes de software (SPDX)
- Etiquetas de identificación de software (SWID)
[Read also: Here’s your security automation playbook for 2023]
Prácticas y procesos
Las prácticas y los procesos garantizan la exactitud de un documento SBOM a lo largo de todo el ciclo de vida de un producto de software. La NTIA enumera varios elementos mínimos que deben tenerse en cuenta, entre los que se incluyen:
- Frecuencia: . Cada vez que se actualice un componente de software con una nueva compilación o versión, deberá generarse una nueva SBOM que refleje la nueva versión del software. Esto incluye compilaciones de software destinadas a integrar un componente o una dependencia actualizados. Del mismo modo, si el proveedor desea corregir un error o actualizar la información contenida en los datos de la lista de materiales de fabricación (SBOM) existentes, deberá emitir una nueva SBOM revisada.
- Más información: Una SBOM debe incluir todos los componentes de nivel superior y enumerar sus dependencias.
- Lo que se sabe que se desconoce: En ocasiones, los desarrolladores reconocen que no conocen todas las relaciones de dependencia de un componente. En estos casos, la SBOM debe dejar claro que los datos están incompletos y explicar dónde podrían existir relaciones.
- Distribución y entrega: . Las listas de materiales de software (SBOM) deben estar a disposición de quienes las necesiten de forma oportuna y cuenten con los permisos de acceso y roles adecuados.
- Control de acceso: Las organizaciones que deseen mantener la confidencialidad de los datos de la SBOM deben especificar las condiciones, incluidas las excepciones y adaptaciones que permitan a los usuarios integrar dichos datos en sus herramientas de seguridad.
- Tolerancia ante los errores: Dado que la gestión de los datos de la SBOM es una práctica en constante evolución, los usuarios deben mostrarse tolerantes ante los errores fortuitos. Los proveedores deben facilitar datos actualizados a medida que se detecten problemas en las listas de materiales de software (SBOM) anteriores, y los usuarios deben acoger favorablemente estas actualizaciones y correcciones sin que ello suponga ninguna penalización, con el fin de fomentar la mejora continua.
Es probable que los requisitos de la SBOM sigan aumentando y evolucionando. Es posible que, con la actualización de las directrices, se incluyan más campos de datos y se añadan puntuaciones de seguridad, listas de vulnerabilidades y otra información. Si bien las organizaciones solo están obligadas a cumplir los requisitos mínimos de una SBOM, la inclusión de información adicional relevante sobre un producto de software demostrará un firme compromiso con la transparencia y la seguridad.
¿En qué consiste el ciclo de vida del desarrollo de la SBOM?
Lo ideal sería que las listas de componentes de software (SBOM) se generaran automáticamente cada vez que se implemente software e incluyeran un inventario lo más completo posible. El ciclo de vida de la SBOM contribuye a facilitar este proceso al ofrecer un procedimiento para identificar aplicaciones, crear SBOM y ponerlas a disposición de los usuarios finales.
«. Las SBOM deben generarse automáticamente cada vez que se implemente software e incluir un inventario lo más completo posible.»
Consta de las cinco fases siguientes:
- Detección de activos —La primera etapa consiste en localizar la aplicación para la que debe proporcionar una SBOM. Es recomendable utilizar una herramienta de detección de activos de para garantizar una visibilidad completa de todas sus aplicaciones.
- Análisis de los datos de la aplicación —Se recopilan los datos de la aplicación necesarios para la SBOM.
- Creación de la SBOM —Se crea el archivo SBOM, que incluye todos los datos relevantes de la aplicación. Esto debería realizarse cada vez que se publique una nueva versión de la aplicación, con el fin de garantizar que la SBOM se corresponda siempre con el estado actual del software.
- Almacenamiento de SBOM:. Las SBOM deben almacenarse de forma centralizada y segura mediante cifrado.
- Posibilidad de realizar búsquedas en la SBOM —La etapa final consiste en garantizar la funcionalidad de búsqueda en la SBOM, de modo que el usuario final pueda detectar cualquier posible vulnerabilidad.
¿Qué normas de SBOM existen?
Un estándar SBOM es un esquema que permite detallar la composición del software en un archivo legible por máquina que pueden utilizar otras herramientas, como los escáneres de vulnerabilidades y los sistemas de seguimiento de licencias de software. En la actualidad, existen tres normas principales para generar listas de materiales de software (SBOM) y compartirlas con los usuarios finales:
- SPDX —El estándar SPDX (Software Package Data Exchange), desarrollado por la Fundación Linux, es un formato ampliamente adoptado para comunicar datos de la lista de materiales de software (SBOM), tales como los componentes de una aplicación, las licencias, los derechos de autor y la información de seguridad, en múltiples formatos de archivo.
- CycloneDX —CycloneDX es otro estándar abierto, desarrollado por la comunidad OWASP. Se basa en el estándar SPDX, pero se ha simplificado para facilitar su implementación y uso
- SWID —Los SWID, abreviatura de «Software Identification Tags» (etiquetas de identificación de software), son un tipo de metadatos que pueden generarse automáticamente mediante numerosas aplicaciones para describir y contextualizar los componentes del software.
La NTIA ha seleccionado estas tres normas de SBOM como aceptables porque, además de ser legibles para las personas, también son legibles para las máquinas y permiten la automatización, lo que facilita a los usuarios finales el uso y la ampliación de las SBOM en toda su organización.
[Lea también: El futuro de la gestión de riesgos pasa por la automatización]
¿Cuáles son los retos que plantea la creación y el uso de una SBOM?
Al igual que ocurre con cualquier sistema nuevo, la creación y el uso de una SBOM plantean algunos retos.
Uno de los principales obstáculos es la falta de normalización. Es probable que las listas de materiales de seguridad (SBOM) resulten más eficaces cuando toda la cadena de suministro se ajuste a las mismas normas, procesos y herramientas. Sin embargo, en esta fase inicial apenas existe consenso sobre ninguno de estos aspectos, y es inevitable que haya una falta de uniformidad entre los proveedores de software y los usuarios finales. Esto puede suponer una inversión adicional de tiempo en analizar y adaptar las SBOM según las necesidades.
«Es probable que las SBOM resulten más eficaces cuando toda la cadena de suministro se adhiera a las mismas normas, procesos y herramientas. Sin embargo, en esta fase inicial apenas existe consenso sobre ninguno de estos temas.»
Otro reto es la necesidad de adaptar continuamente las listas de materiales de software (SBOM). Cada vez que se lanza una nueva versión de una aplicación, esta debe incluir una nueva SBOM que refleje el estado actual de la aplicación. Por ello, resulta fundamental adoptar herramientas de gestión de SBOM que permitan integrar la generación de SBOM en el ciclo de vida del desarrollo de software.
Ampliar las SBOM a medida que se incorporan más socios a la cadena de suministro también puede suponer un problema si se utilizan métodos tradicionales para generarlas, como hojas de cálculo y correo electrónico. Además, estos métodos manuales requieren mucho tiempo, son propensos a errores y pueden dificultar el seguimiento de las relaciones jerárquicas entre los componentes.
¿Cuáles son algunas de las mejores prácticas para crear una SBOM eficaz?
Las siguientes prácticas recomendadas pueden ayudarle a crear SBOM eficaces:
- Utilice un formato coherente:. Es importante seguir un formato estándar a la hora de estructurar los datos de la SBOM. SPDX, CycloneDX y SWID son los más habituales, pero, en última instancia, la elección del formato importa menos que utilizarlo de forma coherente.
- Automatice la creación de la SBOM —La generación automática de SBOM como parte de su proceso de entrega de software ofrece varias ventajas. En primer lugar, supondrá un ahorro de tiempo para los desarrolladores, ya que no tendrán que elaborar cada SBOM manualmente. Además, aumenta la probabilidad de que las SBOM pasen a formar parte habitual de su ciclo de entrega de software. Por último, le permite cumplir los requisitos establecidos por el decreto ejecutivo de Biden para la prestación de servicios de tecnologías de la información al Gobierno federal.
- Actualice las listas de materiales de software (SBOM) con cada versión:. Una lista de materiales de software (SBOM) debe ser específica para cada versión del software, incluso cada vez que se actualice una aplicación. La automatización es fundamental en este caso; si los desarrolladores tienen que actualizar manualmente su SBOM con cada actualización de la aplicación, es mucho menos probable que lo hagan.
- Incluya metadatos completos —Aunque no existen normas universales para las SBOM, debería acostumbrarse a incluir tantos metadatos como sea posible en cada SBOM. De este modo, se reducirá la cantidad de información que sus usuarios finales tendrán que consultar manualmente y se pondrá de manifiesto su compromiso con la seguridad y la transparencia. Además, facilita la actualización.
