El SBOM en un párrafo
Un Software Bill of Materials (SBOM) es un inventario de cada componente de terceros del que depende un software — nombre, versión, y un identificador lo bastante preciso para que un equipo de procurement o seguridad pueda buscarlo. CycloneDX es uno de los dos estándares SBOM dominantes (el otro es SPDX), mantenido por OWASP, actualmente en versión de especificación 1.5. A diferencia de un informe SARIF, un SBOM no describe vulnerabilidades — describe de qué está hecho su software. Ambos son complementarios: SARIF responde "qué encontró", un SBOM responde "de qué depende".
Generar el SBOM
Un solo flag, mismo CLI que el resto:
./staticcodeaudit-linux-x86_64 /path/to/project --sbomEsto escribe SCA-SBOM-<timestamp>.json junto al informe HTML habitual. El escáner detecta automáticamente los archivos manifiesto de dependencias en la raíz del proyecto y las rutas incluidas — sin configuración adicional necesaria.
Archivos manifiesto que lee
Se analizan seis formatos de manifiesto de dependencias directamente, cubriendo los lenguajes que este escáner audita en busca de vulnerabilidades:
| Manifest | Ecosystem |
|---|---|
requirements.txt / pyproject.toml |
PyPI (Python) |
package.json |
npm (JavaScript/TypeScript) |
pom.xml |
Maven (Java) |
build.gradle |
Gradle (Java) |
*.csproj |
NuGet (C#) |
composer.json |
Packagist (PHP) |
Cada manifiesto se lee una sola vez por escaneo (raíz del proyecto más rutas incluidas configuradas, deduplicado por ruta normalizada) — un proyecto con tanto requirements.txt como package.json obtiene componentes de ambos en el mismo SBOM.
Qué contiene realmente el archivo
Un ejemplo real — dos dependencias fijadas en un requirements.txt:
{
"bomFormat": "CycloneDX",
"specVersion": "1.5",
"version": 1,
"metadata": {
"timestamp": "2026-08-07T18:30:12.104Z",
"tools": [{ "name": "StaticCodeAudit", "version": "1.0.0" }],
"component": {
"type": "application",
"name": "your-project",
"version": "1.0.0"
}
},
"components": [
{
"type": "library",
"name": "requests",
"version": "2.31.0",
"purl": "pkg:pypi/requests@2.31.0"
},
{
"type": "library",
"name": "flask",
"version": "3.0.0",
"purl": "pkg:pypi/flask@3.0.0"
}
]
}Cada componente lleva un Package URL (purl) — un identificador estandarizado (pkg:pypi/requests@2.31.0) que las herramientas de procurement y bases de datos de vulnerabilidades pueden emparejar sin ambigüedad. La exportación lista nombre, versión y purl; no calcula ni incluye hashes de archivo por dependencia.
SBOM o SARIF — nunca ambos en la misma ejecución
Las exportaciones SBOM y SARIF son mutuamente excluyentes por invocación — sirven a consumidores distintos (procurement/inventario vs. triaje de vulnerabilidades) y combinarlas dificultaría el análisis correcto de ambas aguas abajo:
$ ./staticcodeaudit-linux-x86_64 /path/to/project --sarif --sbom
❌ --sarif and --sbom are mutually exclusive. Use one or the other.Ejecute el escaneo dos veces en CI si un pipeline necesita ambos artefactos del mismo commit — cada ejecución tarda bastante menos de un segundo en una base de código pequeña a mediana. Vea la guía de exportación SARIF para el lado de vulnerabilidades.
Dónde encaja para entidades reguladas
Para organizaciones dentro del alcance de la directiva europea NIS2, el Artículo 21(2)(d) exige "medidas" que cubran la seguridad de la cadena de suministro. Un SBOM CycloneDX — combinado con hallazgos de vulnerabilidades SARIF del mismo código — es el tipo de evidencia concreta y legible por máquina sobre la que un auditor o revisor de procurement puede actuar: exactamente qué dependencias hay en una release dada, en qué versión, cruzadas con vulnerabilidades conocidas. Más detalle en la página de sectores regulados.
Preguntas frecuentes
¿Generar un SBOM envía mi lista de dependencias a algún sitio?
No. El SBOM se construye enteramente a partir de archivos locales (su requirements.txt, package.json, etc.) y se escribe en disco local. StaticCodeAudit no realiza ninguna llamada de red saliente durante un escaneo — generar un SBOM no cambia eso, ya que no se involucra ninguna consulta a una base de datos externa.
¿El SBOM incluye vulnerabilidades conocidas de cada dependencia?
No — para eso está el flag --with-deps y la exportación SARIF. El SBOM en sí es un inventario puro (array components de CycloneDX): nombre, versión, purl. Cruzar los componentes con bases de datos de vulnerabilidades es un paso separado, típicamente realizado por el sistema que consume el SBOM aguas abajo.
¿Qué pasa si mi proyecto no tiene un manifiesto de dependencias reconocido?
El SBOM se genera igualmente, con un array components vacío — un CycloneDX 1.5 válido, que simplemente describe una aplicación sin dependencias de terceros declaradas. Esperado, por ejemplo, para un proyecto puramente HTML o infra-as-code sin equivalente a requirements.txt/package.json.
¿Puedo obtener un SBOM para un monorepo con varios manifiestos?
Sí — el escáner recorre la raíz del proyecto más cada ruta listada bajo include en audit.config.json, y fusiona los componentes de cada manifiesto encontrado (por ejemplo, un package.json raíz y un backend/requirements.txt anidado en el mismo repo contribuyen ambos a un solo SBOM).
Vea un SBOM completo sobre código real
Abra el informe de demostración en vivo — sin instalación, sin registro — o ejecute el binario contra su propio proyecto e inspeccione directamente el SBOM generado.
Abrir el informe en vivo Descargar el binario de demo