⌘K
ENES
GitHub
conceptDevSecOps~1 min de lecturaActualizado Apr 23, 2026

SBOM and Provenance

Definición

Un SBOM registra qué componentes de software hay en un producto, mientras que provenance da trazabilidad sobre cómo, dónde y desde qué se construyeron esos artifacts.

Por qué importa

No podés gobernar bien el riesgo de software si no sabés qué hay dentro de tus artifacts o cómo fueron producidos. SBOM y provenance mejoran incident response, review de dependencias, confianza de release y confianza downstream. Mantené clara la distinción: SBOM y provenance mejoran visibilidad y trazabilidad, mientras artifact-integrity se enfoca en si los artifacts se mantuvieron confiables y dependency-risk se enfoca en exposición de paquetes upstream.

Perspectiva del atacante

Los atacantes se benefician cuando los equipos no pueden responder:

  • ¿qué componentes hay en este release?
  • ¿qué build lo produjo?
  • ¿qué upstreams estuvieron involucrados?
  • ¿qué versiones están deployadas dónde?

Perspectiva del defensor

Los defensores deberían:

  • entender qué se está shippeando
  • conectar componentes con builds y releases
  • mejorar velocidad de respuesta cuando aparece nuevo riesgo upstream
  • usar provenance para reforzar confianza en artifacts

Ejemplos prácticos

  • un equipo no puede identificar rápido dónde está deployado un paquete transitivo vulnerable
  • existe un artifact en producción con origen de build poco claro
  • los registros de release no capturan suficiente detalle de componentes para triage rápido

Notas relacionadas

Referencias

  • Fundamental: NIST SP 800-218 SSDF — https://csrc.nist.gov/pubs/sp/800/218/final
  • Fundamental: CISA Secure by Design — https://www.cisa.gov/resources-tools/resources/secure-by-design
  • Fundamental: OWASP Software Supply Chain Security Cheat Sheet — https://cheatsheetseries.owasp.org/cheatsheets/Software_Supply_Chain_Security_Cheat_Sheet.html

Notas relacionadas

DevSecOpsArtifact IntegrityArtifact integrity es la garantía de que outputs de build, paquetes, imágenes y artifacts de release no fueron manipulados y pueden trazarse hasta el proceso de build previsto. DevSecOpsASVS como input del proceso de desarrolloEsta nota trata OWASP ASVS no como una checklist post-hoc, sino como un input del proceso de desarrollo para diseñar, revisar y verificar controles técnicos de seguridad durante la implementación. DevSecOpsProtección de ramas y controles de releaseLa protección de ramas y los controles de release son las reglas y mecanismos de governance que determinan quién puede cambiar rutas de código protegidas, aprobar releases y promover artifacts hacia producción. DevSecOpsCI/CD HardeningCI/CD hardening es asegurar el build, test y deployment pipeline para que la automatización se vuelva una ruta de control confiable en vez de un amplificador de ataques. DevSecOpsContainer SecurityContainer security es la práctica de reducir riesgo en cómo las aplicaciones containerizadas se construyen, configuran, shippean y corren. DevSecOpsDependency RiskDependency risk es el riesgo de seguridad introducido por librerías, frameworks y paquetes de terceros directos y transitivos, y por sus patrones de actualización y confianza.