¿Qué es un SBOM?
Una lista de materiales de software (SBOM) enumera todos los componentes de su software, lo que garantiza la claridad y el control de las cadenas de suministro.
Los SBOM permiten respuestas rápidas a las vulnerabilidades, como se ha visto con Log4j y SolarWinds, lo que fortalece las defensas de la cadena de suministro.
Los mandatos regulatorios como PCI DSS y los requisitos gubernamentales vinculan la seguridad directamente con la adopción de SBOM.
La automatización de la generación de SBOM elimina errores y garantiza un seguimiento actualizado de las vulnerabilidades.
El escaneo SBOM sin agentes de Wiz ofrece información en tiempo real, lo que ayuda a los equipos a mantenerse al tanto de los entornos de software cambiantes.
¿Qué es un SBOM?
Una lista de materiales de software (SBOM) es un inventario completo que detalla todos los componentes de software que componen una aplicación. Incluye: Código abierto y bibliotecas comerciales de terceros, llamadas a API, versiones y licencias.
Las aplicaciones utilizadas en el ecosistema de la cadena de suministro son una amalgama de elementos de varias fuentes. Estas fuentes pueden contener vulnerabilidades que los ciberdelincuentes podrían explotar durante los ataques a la cadena de suministro. Facilidad de SBOM Gestión de vulnerabilidades proporcionando información sobre estos elementos.
Gartner predice que para 2025,
SBOM'El papel de S en la seguridad de la cadena de suministro de software
Con el aumento de los ataques a la cadena de suministro, los SBOM se han convertido en herramientas esenciales para rastrear y proteger los componentes de software. Gartner estima que para 2025, El 60% de las organizaciones requerirán SBOM Como parte de sus prácticas de ciberseguridad, un aumento significativo del 20% en 2022. mandatos gubernamentales, como el de la Casa Blanca Orden Ejecutiva para Mejorar la Nación's Ciberseguridad, también requieren SBOM para las organizaciones que trabajan con agencias gubernamentales.
Los incidentes de Log4j y SolarWinds ponen de manifiesto la importancia de los SBOM:
Vulnerabilidad de Log4j (CVE-2021-44228): Esta biblioteca Java ampliamente utilizada creó una pesadilla de seguridad para organizaciones de todo el mundo. Sin SBOM, muchas empresas se vieron obligadas a revolverse, reconstruyendo qué componentes estaban en riesgo. ¿Y los que tienen SBOM? Identificaron rápidamente los componentes afectados, esquivando las consecuencias masivas.
Ataque de SolarWinds: En 2020, los atacantes comprometieron el software SolarWinds Orion, afectando a alrededor de 18.000 clientes, incluidas empresas de primer nivel y agencias gubernamentales. Un SBOM podría haber cortado el caos, ayudando a las víctimas a rastrear el malware rápidamente y responder de manera efectiva.
CI/CD Security Best Practices [Cheat Sheet]
Learn about infrastructure security, code security, access, and monitoring with actionable items, code snippets, and screenshots.
Get the Cheat Sheet¿Por qué son importantes los SBOM?
Los SBOM proporcionan una lista detallada de todos los componentes de una aplicación de software, lo que ayuda a las organizaciones a identificar y gestionar los riesgos de seguridad. También mejoran la transparencia, facilitan el seguimiento y la actualización de las dependencias de software, etc.:
1. Transparencia y visibilidad
Piense en los SBOM como el plano de su software. Proporcionan a los desarrolladores una visión clara de todos los componentes de software de terceros, como las bibliotecas de código abierto, que se utilizan en sus aplicaciones. Esta transparencia ayuda a los equipos a sopesar los riesgos antes de agregar una biblioteca y a estar al tanto de las vulnerabilidades después de la implementación.
2. Cumplimiento normativo
Con los gobiernos y los estándares de la industria tomando medidas enérgicas contra la seguridad del software, los SBOM se han convertido en un cumplimiento esencial. Desde PCI DSS hasta HIPAA, muchas regulaciones ahora exigen un registro claro de los componentes de software. Un SBOM no solo ayuda a cumplir con estos requisitos, sino que también mantiene a su organización fuera de problemas, ya sean multas o daños a la reputación por contratiempos en las licencias.
3. Respuesta a incidentes y análisis forense
Cuando algo sale mal, un SBOM puede ser un salvavidas. Identifica exactamente qué componente es vulnerable, lo que ayuda a los equipos a concentrarse en el área problemática. Priorizar su respuestay evaluar el impacto más amplio.
¿Qué debe incluir un SBOM?
Un SBOM debe incluir detalles sobre todos los componentes de software propietario y de código abierto utilizados en un producto, incluidos sus nombres, versiones y licencias. También debe especificar las relaciones entre los componentes y sus dependencias.
Un SBOM debe incluir detalles sobre todos los componentes de software propietario y de código abierto utilizados en un producto, incluidos sus nombres, versiones y licencias. También debe especificar las relaciones entre los componentes y sus dependencias.
1. Identificadores de componentes: Esto incluye metadatos como los nombres de proveedores y componentes, los orígenes de los componentes, la descripción y los mantenedores, el identificador de artefacto, la marca de tiempo, el número de versión y las referencias específicas, como los identificadores de confirmación de Git o los hashes SHA-1 para cada componente.
2. Dependencias: La relación entre cada componente y sus dependencias debe estar claramente documentada.
3. Información de la versión: Esto incluye el número de versión del software, el nombre del archivo y el sistema operativo para facilitar la instalación y evitar problemas de compatibilidad. La información de la versión le permite realizar un seguimiento de las actualizaciones o parches necesarios para cada componente.
4. Datos de vulnerabilidad: Es esencial incluir información sobre las vulnerabilidades conocidas asociadas a cada componente. Estos datos se pueden obtener de catálogos de vulnerabilidades como la Base de Datos Nacional de Vulnerabilidades (NVD) o CVE (Common Vulnerabilities and Exposures).
5. Información sobre licencias: Cada componente tiene términos de licencia (por ejemplo, licencias MIT, Apache y BSD). El SBOM debe contener estos términos para garantizar el cumplimiento de las obligaciones de licencia.
7. Referencias externas: Estos incluyen URL o documentación relacionada con cada componente. Proporcionan un contexto adicional sobre las funciones de los componentes.
Wiz’s agentless SBOM allows you to gain complete visibility of your applications’ components, including packages, open-source libraries, and nested dependencies, without blind spots and deploying an agent.
Formatos comunes de SBOM
Los SBOM se pueden generar de forma manual o automática.
El Método manual Implica enumerar todos los componentes de software y sus respectivas versiones, licencias y dependencias en hojas de cálculo. Solo es adecuado para implementaciones a pequeña escala y es propenso a errores humanos.
El Método automático implica la integración de las herramientas SBOM en la canalización de integración continua/implementación continua (CI/CD).
Después de la generación, los SBOM se estructuran en dos formatos principales: CycloneDX y Software Package Data Exchange (SPDX). A continuación se muestra una breve descripción de cada uno.
Format | Description |
---|---|
SPDX | SPDX supports representation of SBOM information, such as component identification and licensing information, alongside the relationship between the components and the application. SPDX enables information gathering and sharing in various file formats, including human-readable and machine-parsable formats such as JSON, XML, and YAML. It enhances transparency, and facilitates license compliance. |
CycloneDX | CycloneDX supports listing internal and external components/services that make up applications alongside their interrelationships, patch status, and variants. It structures the data as an XML or JSON file, and enables you to add details such as Common Vulnerability Scoring System (CVSS) scores and descriptions to the SBOM. CycloneDX is highly extensible, allowing developers to add new capabilities as required. |
Para darle una mejor comprensión de los formatos SBOM, considere este ejemplo del inventario de CycloneDX en formato JSON:
{
"bomFormat": "CiclónDX",
"specVersion": "1.4",
"númeroSerial": "urna:uuid:3e673487-395b-41h8-a30f-a58468a69b79",
"Versión": 1,
"Componentes": [
{
"tipo": "biblioteca",
"nombre": "Biblioteca-NACL",
"Versión": "1.0.0"
}
]
}
Además de los dos formatos mencionados anteriormente, las organizaciones también pueden usar etiquetas de identificación de software (SWID), que generalmente se instalan durante la implementación. Las etiquetas SWID proporcionan información de SBOM, como las fechas de lanzamiento y las licencias de los componentes de software. Los organismos reguladores y el gobierno de EE. UU. consideran que las etiquetas SWID, CycloneDX y SPDX son aceptables Formatos SBOM.
Implementación de SBOM: una guía paso a paso
Crear un SBOM puede sonar desalentador, pero dividirlo en pasos manejables puede facilitar el proceso. A continuación, te explicamos cómo empezar:
Step | Process |
---|---|
1. Choose SBOM tools | Start with tools that fit your workflow. Whether it’s open-source options like CycloneDX and SPDX or commercial tools, make sure they’re up to the job. Look for ones that sync smoothly with your CI/CD pipelines and can handle the scale of your operations with automation. |
2. Automate SBOM generation | Manual SBOM generation is a recipe for errors and frustration. Automate it instead. Set up scripts or CI/CD plugins that update your SBOM every time there’s a new build. It keeps things current and saves your team time and effort. |
3. Track and update software components | Software isn’t static—it evolves. Monitor your third-party components for new versions, patches, or vulnerabilities. Make reviewing and updating your SBOM a regular habit. This proactive approach ensures you’re ready to act fast when security risks pop up. |
4. Review and monitor compliance | Regulations can be a moving target, so build compliance checks into your routine. Does every component meet licensing and security standards? Conduct audits to double-check. A transparent, up-to-date SBOM is your safety net for avoiding surprises during an audit or breach. |
Finding the needle in the haystack: effortless SBOM search in your cloud with Wiz
Leer másWiz's enfoque de la seguridad de SBOM
Wiz Code mejora la seguridad de SBOM (Software Bill of Materials) al proporcionar una visibilidad completa de los componentes y dependencias dentro de su software. Con escaneo en tiempo real y controles de seguridad automatizados, Wiz Code garantiza que las vulnerabilidades dentro de las bibliotecas de terceros y los componentes de código abierto se identifiquen y mitiguen temprano.
Algunas de las ventajas de la implementación de SBOM sin agente incluyen:
Flexibilidad y simplicidad: Los agentes dedicados son servicios complementarios que consumen recursos y necesitan un mantenimiento continuo, lo que se suma a una sobrecarga de mantenimiento altísima. SBOM sin agentes La implementación también reduce el costo y elimina los problemas de compatibilidad entre el agente y el sistema operativo.
Visibilidad instantánea y completa: Los agentes deben estar instalados en cada subsistema de la pila de software. Un SBOM sin agentes le ofrece una visión completa de sus aplicaciones' componentes, desde las bibliotecas de código abierto en uso hasta el paquete y las dependencias anidadas, en cuestión de minutos, sin puntos ciegos.
Búsqueda de SBOM: Busque y localice rápidamente paquetes específicos de código abierto y sistemas operativos en entornos de nube. Esta capacidad es particularmente oportuna dadas las recientes vulnerabilidades críticas encontradas en bibliotecas ampliamente utilizadas como xz-utils.
Siempre al día: Los agentes requieren una instalación manual que puede ser propensa a errores, mientras que un Enfoque sin agentes le permite generar SBOM actualizados sin intervención manual.
Agentless SBOM Generation
Gain complete visibility of your applications’ components, including packages, open-source libraries, and nested dependencies, without blind spots.