SBOM básico: inventario de dependencias que sí sirve
Qué es un SBOM, cuándo ayuda, qué no resuelve y cómo usarlo como evidencia de supply chain sin vender humo.
Antes de empezar necesitás
- Tener un proyecto de juguete con package.json o dependencias similares
- Idea básica de dependencias directas y transitivas
Al terminar vas a poder
- Entender qué contiene un SBOM
- Distinguir CycloneDX, SPDX y lockfiles
- Usar un SBOM como evidencia revisable
- Reconocer límites: inventario no es remediación
Un SBOM no hace tu software seguro. Es un inventario: qué componentes tenés, con qué versiones y, según el formato, con metadatos útiles. Sin inventario, cuando aparece una vulnerabilidad, empezás preguntando “¿usamos eso?”.
Primer inventario con npm
Para un proyecto Node, empezá por algo simple:
npm ls --depth=0
npm audit --omit=devEsto no reemplaza un SBOM formal, pero te obliga a separar dependencias directas, transitivas y entorno de ejecución.
Qué debería responder
pregunta dato que necesitás
¿usamos la librería vulnerable? nombre y versión
¿está en runtime o dev? scope/dependency type
¿llega a producción? build/deploy path
¿hay fix disponible? versión corregida
¿rompe actualizar? tests / changelog / compatibilidadEvidencia útil
Tu entrega puede ser una tabla:
paquete directo/transitivo runtime/dev versión por qué está
astro directo runtime x.y.z framework del sitio
prettier directo dev x.y.z formato de códigoLo que practicás en este lab
Llevátelo a tu repo si querés, pero no es obligatorio: es tu aprendizaje.
- SBOM generado o ejemplo sintético
- Tabla con 5 dependencias: directa/transitiva, versión y uso
- Writeup: qué harías ante una dependencia vulnerable
Reto
Elegí un proyecto de juguete. Listá dependencias directas, marcá cuáles son runtime y cuáles dev, y escribí qué dato necesitarías para decidir si una vulnerabilidad aplica.
Resolvelo y escribí dos líneas explicando qué pasó. Con eso lo fijás.