# Lista de comprobación del SBOM para pymes (A1.6) Qué recoger en una lista de materiales de software (SBOM) y cuándo hacerlo. Un SBOM favorece la transparencia y la trazabilidad de los productos que utilizan componentes FOSS, y las prácticas relacionadas con el SBOM pueden adoptarse de forma progresiva. ## Qué recoger — Mínimo - [ ] Nombre del producto + versión (identificador de la versión) - [ ] Nombre del componente + versión - [ ] Dependencias directas y transitivas (según disponibilidad) - [ ] Información sobre licencias (cuando sea posible) - [ ] Identificadores únicos (cuando estén disponibles, p. ej., package URL / hashes) ## Cuándo generar o actualizar el SBOM Mínimo: - [ ] En las versiones principales (p. ej., versión 1.0, 1.1, 2.0) Recomendado: - [ ] En cada versión que modifique las dependencias Actualizar siempre cuando: - [ ] Un parche de seguridad requiere actualizar una dependencia - [ ] Un componente crítico o muy expuesto cambia de versión - [ ] Se aplica una corrección de vulnerabilidad ## Niveles de madurez del SBOM ### Nivel 1 — Básico - Lista estructurada de dependencias - Actualización en las versiones principales - Vinculado a la documentación de la versión ### Nivel 2 — Estructurado - Generación automatizada del SBOM (cuando sea posible) - Dependencias directas + transitivas - Registro de licencias - SBOM almacenado junto con los artefactos de la versión ### Nivel 3 — Avanzado - Generación del SBOM integrada en CI/CD - Vigilancia continua de las dependencias - Verificación de hashes - Seguimiento del historial de versiones del SBOM - Análisis rápido del impacto de las CVE --- _Basado en el entregable D2.3 de OCCTET – Documento de buenas prácticas de adopción del CRA (v1.0, marzo de 2026), con licencia CC BY 4.0._