Las aplicaciones modernas ya no son monolitos gigantes, sino una colección de microservicios, componentes de código abierto y herramientas de terceros. Pero esto hace que sea muy difícil comprender realmente el interior de nuestras aplicaciones, sobre todo si tenemos en cuenta que nuestras dependencias de código abierto también tienen dependencias de código abierto.
La lista de materiales de software (SBOM) desempeña aquí un papel clave. La SBOM proporciona un inventario detallado de todos los componentes del software. Esto no solo nos ayuda a entender nuestro software, sino que también nos permite identificar riesgos y cumplir nuestros requisitos de conformidad y gobernanza.
Para que los SBOM funcionen bien, deben estar estandarizados y ser fáciles de compartir entre varios sistemas y herramientas. Aquí es donde las normas SBOM se vuelven vitales.
Comprender las normas SBOM
Las normas SBOM establecen un formato común para crear y compartir datos SBOM. Ofrecen un lenguaje unificado que garantiza una comunicación coherente entre distintas organizaciones y herramientas.
La normalización es necesaria porque los SBOM pueden ser extensos y estar repletos de detalles sobre componentes, versiones, licencias y dependencias. Sin un formato estándar, la interpretación y el uso de los datos de las listas de materiales puede resultar complicada para las distintas entidades.
En la actualidad, tres normas principales de SBOM son populares en la industria:
- CycloneDX: norma ligera centrada en la seguridad que admite varios tipos de listas de materiales, incluidos software, hardware y servicios.
- SPDX (Intercambio de datos de paquetes de software): La única norma SBOM reconocida por ISO, conocida por su enfoque integral de los datos de componentes y sus orígenes en la concesión de licencias de software.
- Etiquetas SWID (identificación de software): Centradas en la identificación de software, ayudan al seguimiento del software instalado para la gestión de activos.
Cada norma tiene puntos fuertes y casos de uso específicos, que analizaremos más adelante.
CycloneDX de un vistazo
- Construido específicamente para casos de uso de seguridad (por ejemplo, rastreo de vulnerabilidades, soporte VEX, hash de componentes).
- Soporta de forma nativa VEX (Vulnerability Exploitability eXchange) y árboles de dependencias.
- Compatible con las modernas canalizaciones DevSecOps y herramientas como OWASP Dependency-Check, Anchore, GitHub Advanced Security.
- Más fácil de integrar en entornos CI/CD (ligero, compatible con JSON).
CycloneDX destaca por su eficacia y sus sólidas funciones de seguridad. Su diseño permite una rápida integración, por lo que es ideal para equipos que valoran la agilidad y la seguridad. CycloneDX cubre software, hardware y materiales relacionados con el servicio, lo que lo hace versátil para diferentes entornos tecnológicos.
CycloneDX admite múltiples formatos de datos, incluidos XML, JSON y protobuf, lo que garantiza la compatibilidad con diversas herramientas. Bajo el paraguas de OWASP, CycloneDX evoluciona continuamente para hacer frente a los retos de seguridad actuales en las cadenas de suministro de software.
Ejemplo de formato CycloneDX
{
"bomFormat": "CycloneDX",
"specVersion": "1.5",
"version": 1,
"components": [
{
"type": "library",
"name": "example-lib",
"version": "1.0.0",
"purl": "pkg:npm/example-lib@1.0.0",
"licenses": [{ "license": { "id": "MIT" } }]
}
]
}
Explorar SPDX
- Dirigido a los equipos jurídicos y a la diligencia debida en materia de propiedad intelectual (sólido modelo de metadatos para licencias).
- Amplio lenguaje de expresión de licencias (lista de licencias SPDX).
- Normalizado bajo la norma ISO/IEC 5962:2021.
- Utilizado en grandes esfuerzos como OpenChain, ORT y Tern.
SPDX es reconocida mundialmente como la única norma SBOM con acreditación ISO, lo que aumenta su credibilidad. Inicialmente concebida para la concesión de licencias de software, SPDX se ha ampliado para satisfacer necesidades más amplias de transparencia del software.
SPDX admite múltiples formatos de datos como tag/value, JSON, XML, YAML y RDF, integrándose sin problemas con diversas herramientas y plataformas. Proporciona una visión en profundidad de los componentes de software, documentando archivos y fragmentos de código para un seguimiento detallado de la conformidad y la seguridad.
Ejemplo de formato SPDX
SPDXVersión: SPDX-2.3
DataLicense: CC0-1.0
SPDXID: SPDXRef-DOCUMENTO
DocumentName: ejemplo-sbom
DocumentNamespace: http://spdx.org/spdxdocs/example-sbom
Creador: Tool: SPDX-Tools
Creada: 2025-05-08T12:00:00Z
NombrePaquete: example-lib
SPDXID: SPDXRef-Paquete-example-lib
PackageVersion: 1.0.0Paquete
DownloadLocation: NOASSERTION
PackageLicenseConcluded: MIT
PaqueteLicenciaDeclarada: MIT
PackageChecksum: SHA256: abcdef1234567890abcdef1234567890abcdef1234569ui
Comprender las etiquetas SWID
- Dirigido a la gestión del inventario de software empresarial.
- Normalizado como ISO/IEC 19770-2 - muy centrado en el ámbito gubernamental/militar.
- Utilizado en FedRAMP, NIST 800-171 y marcos de cumplimiento relacionados.
Las etiquetas SWID se centran en una clara delimitación de los productos de software. A diferencia de los SBOM exhaustivos, las etiquetas SWID identifican los paquetes de software individuales, lo que resulta crucial para una gestión precisa del inventario.
En la gestión de activos, las etiquetas SWID ofrecen un método estandarizado para rastrear las instalaciones de software, garantizando que las organizaciones mantengan un panorama preciso del software. Esto ayuda a cumplir las normativas y a optimizar las estrategias de gestión de activos.
Las etiquetas SWID se integran con marcos como las normas SCAP y TCG, lo que refuerza su papel en la seguridad y el cumplimiento de las normativas.
Ejemplo de formato SWID
<SoftwareIdentity xmlns="http://standards.iso.org/iso/19770/-2/2015/schema.xsd" name="example-lib"
version="1.0.0"
tagId="example-lib@1.0.0"
patch="false"
</SoftwareIdentity>
Comparación de las normas SBOM
Para diferenciar CycloneDX, SPDX y SWID Tags, empiece por sus características. CycloneDX se adapta a la gestión flexible de listas de materiales en entornos de seguridad dinámicos. SPDX destaca en el seguimiento de la conformidad, mientras que SWID Tags se centra en la identificación precisa del software. He aquí una rápida comparación:
La estructura de CycloneDX responde a la necesidad de transparencia. SPDX proporciona documentación detallada e integridad de los datos para la supervisión del cumplimiento.
Cada estándar se adapta a unas necesidades específicas. CycloneDX se adapta a los equipos que dan prioridad a un desarrollo rápido y seguro. SPDX atrae a las organizaciones centradas en el cumplimiento de normativas. Las etiquetas SWID mejoran la gestión de activos garantizando un seguimiento preciso.
Las herramientas de conversión entre estos formatos son esenciales para mantener la interoperabilidad. Las soluciones avanzadas permiten a las organizaciones beneficiarse de los puntos fuertes de cada norma, adaptando las estrategias para satisfacer requisitos específicos.
Elegir la norma SBOM adecuada
No basta con generar un SBOM en un solo formato. Las distintas partes interesadas, ya sean auditores internos, organismos gubernamentales o clientes empresariales, puedennecesitar el SBOM en un formato específico para incorporarlo a sus herramientas o flujos de trabajo existentes. Por ejemplo:
- Un contrato federal puede exigir SPDX, mientras que un proveedor de seguridad que realice una evaluación de riesgos puede preferir CycloneDX.
- Algunos sistemas CI/CD pueden admitir sólo determinados formatos de SBOM para la aplicación de políticas o la exploración automatizada.
Las herramientas importan: Elija una que admita varios formatos
Dada esta variabilidad, debe elegir una herramienta que pueda generar SBOM en múltiples formatos a partir de los mismos artefactos de origen. Herramientas como Aikido Security simplifican este proceso generando automáticamente SBOM durante el proceso de creación o las exploraciones de seguridad y exportándolas en formatos como CycloneDX, SPDX y otros, según sea necesario.
Esta capacidad multiformato le garantiza el cumplimiento de diversos requisitos, sin duplicar el trabajo ni introducir errores derivados de las conversiones manuales.