Explicación de la lista de materiales de software (SBOM): por qué es esencial para la ciberseguridad

Las SBOM son un recurso valioso para:

• El cumplimiento normativo

• La compatibilidad entre paquetes de software antiguos y actualizaciones de OSS

• La protección de los clientes ante ciberataques a la cadena de suministro de software

• Las medidas de seguridad en fusiones que involucran software y licencias

Diferencias entre SBOM y CBOM

La lista de materiales de ciberseguridad (CBOM) de 2018 abarca tanto el software como el hardware en una orden ejecutiva. La SBOM documenta únicamente los componentes de software del código, así como su historial de versiones, parches, licencias, actualizaciones y cambios.

¿Por qué son importantes las SBOM para la ciberseguridad?

Los ciberataques dirigidos a la cadena de suministro de software están aumentando. Más de la mitad de estos ataques provienen de grupos establecidos de ciberdelincuentes que realizan amenazas persistentes avanzadas (APT). Su objetivo es aprovechar la confianza de los usuarios y proveedores en sus sistemas.

La falta de transparencia en torno a los incidentes cibernéticos hace que la cadena de suministro sea vulnerable. En algunos casos, los desarrolladores desconocen las posibles vulnerabilidades y, por consiguiente, los usuarios también pueden estar expuestos. Las bibliotecas de código abierto dependen de otros componentes de software. Casos como la vulnerabilidad de Log4Shell son un ejemplo de un componente (en este caso, una biblioteca de registro) que muchos desarrolladores nunca se molestan en revisar porque no es una dependencia directa de software, sino una dependencia transitiva de la que dependen otros componentes.

Aunque los equipos de desarrollo ya reconocen la necesidad de la seguridad de las aplicaciones, las SBOM aportan más visibilidad a las cadenas de suministro de software y a las posibles vulnerabilidades. Cuando los usuarios saben dónde podrían ocultarse las vulnerabilidades en un producto de software —y conocen los componentes del software, especialmente si sonde código abierto—, están mejor preparados para implementar herramientas de seguridad que detecten y aborden posibles ataques.

Si ocurre un ciberataque, la SBOM puede ayudar a identificar qué software tiene componentes vulnerables y qué tipo de riesgo implica. Esto permite que los usuarios colaboren con los desarrolladores para crear un parche u otra solución de mitigación.

Orden ejecutiva 14028 sobre SBOM

Antes de Log4Shell, otros incidentes cibernéticos, como el ataque a la cadena de suministro de SolarWinds y el incidente de Equifax relacionado con Apache Struts, demostraron cuán vulnerables son las agencias gubernamentales, así como las grandes empresas y organizaciones, en toda la infraestructura crítica. También demostraron cuánto dependen todas las organizaciones de la cadena de suministro de software y cómo una sola vulnerabilidad explotada puede desencadenar un efecto en cascada de gran alcance.

La orden ejecutiva 14028 exige que las agencias gubernamentales, incluido el Instituto Nacional de Estándares y Tecnología (NIST), la Agencia de Seguridad Nacional (NSA), la Oficina de Administración y Presupuesto (OMB), la Agencia de Ciberseguridad y Seguridad de las Infraestructuras (CISA) y el Director de Inteligencia Nacional (DNI), desarrollen estándares y buenas prácticas para mejorar la seguridad de la cadena de suministro de software. Las pautas incluyen:

• Criterios para evaluar la seguridad del software

• Criterios para evaluar las prácticas de seguridad de los desarrolladores y proveedores

• Herramientas o métodos innovadores para demostrar el cumplimiento de prácticas seguras

Para febrero de 2022, el NIST y las demás agencias publicarán pautas sobre buenas prácticas para la cadena de suministro de software. Mientras tanto, consulta nuestra lista de buenas prácticas de seguridad para la cadena de suministro que puedes implementar hoy.

¿Cuándo deberías usar una lista de materiales de software?

Se debe crear una SBOM nueva para cada versión de un componente de software. Del mismo modo, cada vez que se modifique un componente, la SBOM debe actualizarse para reflejar los cambios.

La línea base de la NTIA para una SBOM exige la siguiente información:

• nombre del autor

• nombre del proveedor

• nombre del componente

• hash del componente

• cadena de versión

• identificador

• relación

Para cumplir los requisitos de la línea base, se desarrollaron estándares de SBOM que ofrecen un formato común compatible con varias herramientas. Estos estándares son:

• SPDX: Software Product Data Exchange es un estándar abierto para comunicar los componentes, las licencias y la información de seguridad de los paquetes de software. SPDX estandariza varios servicios, cada uno con su propia SBOM.

• SWID: Las etiquetas de identificación de software son estándares que definen un ciclo de vida. Las etiquetas se agregan al endpoint durante el proceso de instalación del software. Hay cuatro tipos de etiquetas: las etiquetas Corpus, que se usan en la fase previa a la instalación; las etiquetas primary, que proporcionan el nombre del producto y se consideran un identificador único global; las etiquetas patch, que describen los parches aplicados al software; y las etiquetas supplemental, que contienen información adicional.

• OWASP Cyclone DX: Un estándar ligero de SBOM que se usa para analizar los componentes de la cadena de suministro y la seguridad de las aplicaciones.

• VEX: Vulnerability Exploitability Exchange ofrece información adicional sobre el producto, en particular, identifica las vulnerabilidades encontradas en los componentes y recomienda medidas para corregirlas.

Las SBOM y la integridad del software

Las SBOM están diseñadas para determinar la integridad de la cadena de suministro de software y permitir evaluaciones de riesgos basadas en la información recopilada. A grandes rasgos, las SBOM sirven para inventariar los componentes de software de la cadena de suministro. Sin embargo, al aplicar los estándares, las SBOM permiten cumplir con los estándares de cumplimiento de OSS. Por ejemplo, el estándar SPDX identifica las licencias de esos componentes y se usa para garantizar el cumplimiento de las licencias.

Supply Chain Levels for Software Artifacts (SLSA) es un conjunto de estándares y controles que busca ayudar a mantener la integridad de los artefactos de software de código abierto en la cadena de suministro. Lanzado por Google, cumple con las recomendaciones del NIST sobre seguridad de la cadena de suministro. SLSA complementa las SBOM en su objetivo de proteger la gran cantidad de software de código abierto que se usa durante el proceso de desarrollo.

Cómo usar las SBOM para encontrar dependencias y vulnerabilidades

El principal objetivo de seguridad de las SBOM es identificar vulnerabilidades y riesgos en toda la cadena de suministro de software. La información sobre las vulnerabilidades cambia constantemente a medida que se agregan o modifican componentes, lo que puede introducir nuevos exploits. Las SBOM son básicamente estáticas, por lo que los datos que se usan para crearlas cambian y evolucionan continuamente.

Una SBOM es una herramienta para los clientes de software que quieren analizar las vulnerabilidades y comprobar si los desarrolladores actualizan las dependencias para reducir los riesgos. Sin embargo, no todas las vulnerabilidades presentan el mismo nivel de riesgo: algunas no representan ningún riesgo. Para abordar este problema, la NTIA propone dos pasos:

• Del lado del desarrollo y el suministro, se debe determinar el impacto de la vulnerabilidad, en particular si afectará o no áreas específicas del software.

• La información sobre la vulnerabilidad debe comunicarse claramente mediante los datos de la SBOM y se debe verificar que la vulnerabilidad no implique un riesgo adicional.

SBOM para la seguridad de la cadena de suministro

Las SBOM mejoran la seguridad de la cadena de suministro de software de las siguientes maneras:

• Mayor visibilidad de todo el producto de software, incluidas las relaciones entre sistemas

• Intercambio de información sobre vulnerabilidades

• Mejor comunicación en toda la cadena de suministro, desde el desarrollador hasta el usuario, para facilitar la identificación de riesgos de seguridad

• Registros detallados de estándares de cumplimiento y auditorías

La SBOM es una herramienta de seguridad en evolución que ofrece mayor protección y permite detectar riesgos en toda la cadena de suministro de software. Con información más precisa y detallada sobre cada componente del software, la SBOM ofrece oportunidades para descubrir vulnerabilidades en las primeras etapas del ciclo de producción del software y, a su vez, permite mitigarlas antes de que causen daños.

Snyk puede automatizar el proceso de creación de una SBOM, lo que permite a las organizaciones hacer un seguimiento más sencillo de los componentes de código abierto y las dependencias que usan. Snyk también puede analizar estos componentes de forma individual para encontrar posibles vulnerabilidades y ofrecer recomendaciones prácticas para corregirlas.