ClickCease Maximizar la seguridad del software con SBOM

Tabla de contenidos

Únase a nuestro popular boletín

Únase a más de 4.500 profesionales de Linux y el código abierto.

2 veces al mes. Sin spam.

Entender las SBOM

Artem Karasev

12 de diciembre de 2023 - Director de marketing de productos

En los últimos años, la adopción de software de código abierto en el desarrollo ha crecido vertiginosamente. hasta el 90% de lo que se construye. Su popularidad entre las empresas de todo el mundo se debe al ahorro de costes y a la aceleración del plazo de comercialización de los productos. Sin embargo, hay que tener en cuenta un aspecto crucial a la hora de integrar componentes de software de código abierto. Synopsys informa que el 84% de las bases de código comerciales y propietarias incluyen al menos una vulnerabilidad de código abierto conocida. Esto pone de relieve la creciente importancia de garantizar la seguridad de los componentes de código abierto que se utilizan. Y aquí es donde resulta útil una lista de materiales de software (SBOM).

 

¿Qué es un SBOM?

 

Los componentes de código abierto y el código de terceros pueden ser complejos, con muchas capas. Al igual que las muñecas rusas, estas piezas encajan unas dentro de otras, y cada capa puede tener sus propias reglas. Para asegurarse de que su software es seguro, las empresas necesitan saber exactamente qué contiene.

Un SBOM proporciona información detallada sobre cada componente. Es como una etiqueta de software, que enumera todas las piezas y sus relaciones, como una mezcla de piezas de código abierto, piezas de terceros y código propio de la empresa. Ofrece detalles técnicos sobre cada pieza, como su nombre, versión y licencia. Los SBOM también pueden incluir información sobre problemas de seguridad, dependencias transitivas, origen de los componentes y otros datos.

Por ejemplo, en la industria del automóvil, los fabricantes elaboran especificaciones detalladas para cada vehículo, incluidas las piezas fabricadas por ellos y las procedentes de proveedores externos. Si se descubre que una pieza es defectuosa, el fabricante sabe rápidamente qué vehículos están afectados. Esto les permite informar a los propietarios sobre las reparaciones o sustituciones necesarias. Este tipo de registro claro es importante para saber de dónde proceden los defectos y cómo solucionarlos eficazmente.

 

Requisitos mínimos de datos 

 

En Estados Unidos, los desarrolladores de software adoptan cada vez más la lista de materiales de software (SBOM), influidos por las nuevas políticas gubernamentales de seguridad de la información, que exigen medidas de seguridad del software más estrictas.

La Orden Ejecutiva Presidencial Nº 14028emitida el 12 de mayo de 2021, destinada a "Mejorar la ciberseguridad de la nación", establece normas específicas para los sistemas de información federales. Un aspecto clave de esta orden, detallado en la Sección 4, implica la formulación de directrices para el desarrollo de software seguro y prácticas de adquisición. El documento reconoce el SBOM como un elemento crucial para garantizar la integridad del software y gestionar los riesgos asociados a la cadena de suministro de software.

En línea con la Orden Ejecutiva nº 14028, el Departamento de Comercio de EE.UU. y la Administración Nacional de Telecomunicaciones e Información (NTIA) han esbozado unos requisitos mínimos de datos para los componentes de software, clasificados en tres grupos principales:

  1. Campos de datos incluyen información esencial sobre cada componente de software, como:
    • Nombre del proveedor: Nombre de una entidad que crea, define e identifica componentes.
    • Nombre del componente: Designación asignada a una unidad de software definida por el proveedor original.
    • Versión del componente: Identificador utilizado por el proveedor para especificar un cambio en el software con respecto a una versión previamente identificada.
  • Otros identificadores únicos: Otros identificadores que se utilizan para identificar un componente, o sirven como clave de búsqueda para las bases de datos pertinentes.
  • Relación de dependencia: Caracterizar la relación que un componente ascendente X está incluido en el software Y.
  • Autor de SBOM Data: Nombre de la entidad que crea los datos SBOM para este componente.
  • Marca de tiempo: Registro de la fecha y hora del ensamblaje de datos SBOM.

 

  1. Soporte de automatización facilita la generación automática de SBOM y la legibilidad por máquina para permitir la ampliación a todo el ecosistema de software. Además, los SBOM deben generarse en uno de los tres formatos siguientes:

 

  • Intercambio de datos de paquetes de software (SPDX)
  • CycloneDX
  • Etiquetas de identificación de software (SWID)

 

Intercambio de datos de paquetes de software (SPDX)

 

Este formato se utiliza ampliamente para documentar información sobre licencias y componentes de software. Desarrollado por la Fundación Linux, SPDX normaliza la forma en que las organizaciones comunican los componentes de software y las licencias utilizadas en sus productos, simplificando así el cumplimiento de la normativa.

 

CycloneDX

 

Centrado principalmente en la seguridad, CycloneDX es un formato SBOM ligero diseñado para su uso en contextos de seguridad de aplicaciones y análisis de componentes de la cadena de suministro. Proporciona una forma estándar de representar los componentes, bibliotecas y módulos de una aplicación, junto con sus riesgos de seguridad y licencias asociados.

 

Etiquetas de identificación de software (SWID)

 

Desarrolladas por la Organización Internacional de Normalización (ISO), las etiquetas SWID son estructuras XML que proporcionan una identificación única para los productos de software. Ayudan a gestionar el inventario de software y a garantizar el cumplimiento de las licencias. Las etiquetas SWID son especialmente útiles para la gestión de activos de software y la ciberseguridad.

 

  • Prácticas y procesos que deben seguirse para integrar SBOM en el ciclo de vida del desarrollo seguro. Estos incluyen el establecimiento de una frecuencia para las actualizaciones de SBOM, la definición de la profundidad de los árboles de dependencia, el manejo de elementos SBOM con información de dependencia incierta o incompleta, y el establecimiento de políticas para la distribución, entrega y control de acceso.

 

Casos prácticos de SBOM

 

Los casos de uso del SBOM pueden dividirse a grandes rasgos en tres categorías principales:

  • Detección y gestión de vulnerabilidades: SBOM ayuda a realizar un seguimiento de todos los componentes del código. Cuando se detecta una vulnerabilidad crítica, los equipos de seguridad pueden utilizar rápidamente el SBOM para localizar el problema en el código, comprender su impacto y priorizar su solución. Por ejemplo, TuxCare SecureChain para Java de TuxCare proporciona un SBOM detallado para cada paquete Java examinado y parcheado por el servicio, garantizando una transparencia total para una toma de decisiones informada.
  • Gestión de licencias de software: Con un SBOM, las empresas pueden realizar fácilmente un seguimiento de las licencias de software de terceros y de código abierto. Las licencias cambian a menudo, por lo que es necesario realizar comprobaciones periódicas. Esto ayuda a garantizar que la empresa no incumple ningún acuerdo de licencia o derecho de propiedad intelectual, evitando problemas legales y riesgos financieros.
  • Mejora del ciclo de vida del desarrollo de software (SDLC): El SBOM hace más eficiente todo el proceso de creación, despliegue y mantenimiento del software. Por ejemplo, los desarrolladores enumeran todas las dependencias del software en un SBOM inicial a medida que escriben el código. Este SBOM se actualiza durante las fases de prueba y despliegue a medida que se descubren nuevas vulnerabilidades y dependencias. También alerta a los desarrolladores de cualquier problema que surja después de que el software esté en uso, garantizando actualizaciones y mejoras continuas.

El futuro de SBOM

 

El SBOM es especialmente crucial para las empresas que suministran software a entidades gubernamentales, sobre todo en sectores como el de defensa y el aeroespacial. Sin embargo, su relevancia se extiende también a otras empresas.

El reciente repunte de los ataques a la cadena de suministroque a menudo aprovechan vulnerabilidades de código abierto, subraya la importancia de examinar rigurosamente los componentes, bibliotecas y marcos de trabajo de código abierto de terceros. Estos ataques pueden permitir a agentes malintencionados hacerse con el control total de los sistemas de una empresa, alterar la funcionalidad de los productos, introducir programas maliciosos e incluso propagar virus a clientes y otras organizaciones que interactúen. El impacto impredecible y potencialmente extenso de estos ataques los convierte en una amenaza significativa.

Gartner predice que, para 2025, el 60% de las organizaciones incorporarán el SBOM a sus sistemas de seguridad. Sin embargo, aunque útil, el SBOM no es una panacea para los retos de la cadena de suministro y la garantía del software, como reconoce la NTIA. Es una de muchas herramientas, no una solución que lo abarque todo. La eficacia de los SBOM depende de su adopción generalizada, que aún está en curso, con normas y requisitos en evolución. Lograr un uso universal llevará tiempo, dada la variedad de herramientas y normas que se están desarrollando actualmente.

 

Resumen
Entender las SBOM
Nombre del artículo
Entender las SBOM
Descripción
Explore en nuestra guía el papel del SBOM en la mejora de la seguridad de los programas informáticos, su conformidad con las políticas estadounidenses, los casos de uso clave y las tendencias futuras.
Autor
Nombre del editor
TuxCare
Logotipo de la editorial

¿Desea automatizar la aplicación de parches de vulnerabilidad sin reiniciar el núcleo, dejar el sistema fuera de servicio o programar ventanas de mantenimiento?

Más información sobre Live Patching con TuxCare

Conviértete en escritor invitado de TuxCare

Empezar

Correo

Únete a

4,500

Profesionales de Linux y código abierto

Suscríbase a
nuestro boletín