La cadena de suministro del software se ha convertido en uno de los puntos más críticos de la ciberseguridad moderna. Hoy una aplicación no se construye desde cero: combina código propio, librerías open source, imágenes de contenedores, dependencias transitivas, pipelines CI/CD, paquetes de terceros, secretos, artefactos compilados y despliegues automatizados.
Proteger esa cadena requiere más que un antivirus o un escáner final. Se necesita visibilidad, inventario, control de dependencias, generación de SBOM, análisis de vulnerabilidades, firma de artefactos, validación de procedencia, revisión de repositorios y políticas automatizadas.
Idea central: la seguridad de la cadena de suministro no consiste solo en escanear código. Consiste en saber qué componentes usas, de dónde vienen, cómo se construyeron, quién los firmó, qué vulnerabilidades tienen y si cumplen tus políticas antes de llegar a producción.
¿Qué es Software Supply Chain Security?
Software Supply Chain Security es el conjunto de prácticas, herramientas y controles usados para proteger todo el ciclo de vida del software: desde el código fuente hasta la entrega del artefacto final.
Incluye la revisión de repositorios, dependencias, paquetes, contenedores, scripts de construcción, pipelines, credenciales, firmas, SBOM, infraestructura como código y políticas de despliegue.
| Riesgo | Ejemplo | Control recomendado |
|---|---|---|
| Dependencias vulnerables | Librerías antiguas con CVE. | SCA, SBOM y actualización controlada. |
| Paquetes maliciosos | Typosquatting o dependency confusion. | Políticas de repositorio y validación de procedencia. |
| Artefactos manipulados | Imagen de contenedor alterada. | Firma con Sigstore/Cosign y verificación antes de desplegar. |
| Secretos expuestos | Tokens o claves API dentro del repositorio. | Escaneo de secretos y rotación de credenciales. |
| Pipeline comprometido | CI/CD modifica el binario sin control. | SLSA, in-toto, builds reproducibles y mínimo privilegio. |
1. SLSA: el marco base para integridad de artefactos
SLSA, pronunciado “salsa”, no es una herramienta única sino un marco de seguridad. Ayuda a proteger artefactos de software, mejorar integridad, controlar builds y reducir el riesgo de manipulación durante el proceso de construcción.
Sirve para responder preguntas clave: ¿quién construyó este paquete?, ¿con qué código fuente?, ¿en qué entorno?, ¿bajo qué proceso?, ¿existe evidencia verificable?
Uso recomendado: adoptar SLSA como guía para madurar la seguridad del pipeline, especialmente en proyectos que producen contenedores, paquetes, librerías o software distribuido a terceros.
2. Sigstore y Cosign: firma y verificación de artefactos
Sigstore es uno de los proyectos más importantes para proteger la procedencia del software. Permite firmar, verificar y proteger artefactos como imágenes de contenedores, paquetes y archivos.
Cosign es su herramienta más conocida para firmar imágenes de contenedores y verificar que no fueron alteradas antes de ser desplegadas.
Consejo: firma tus imágenes al final del pipeline y verifica la firma antes de desplegar en Kubernetes, servidores o ambientes productivos.
3. OpenSSF Scorecard: medir la salud de seguridad de repositorios
OpenSSF Scorecard evalúa repositorios open source mediante controles automatizados. Permite identificar prácticas débiles, como falta de mantenimiento, ausencia de revisión de dependencias, uso inseguro de workflows o carencia de políticas básicas.
Es útil tanto para proyectos propios como para revisar dependencias críticas antes de adoptarlas.
4. Syft: generar SBOM de aplicaciones y contenedores
Syft permite generar un SBOM, es decir, un inventario de componentes, dependencias, paquetes y librerías que forman parte de una aplicación, imagen o sistema de archivos.
Un SBOM no soluciona vulnerabilidades por sí solo, pero te permite saber qué contiene tu software y reaccionar más rápido cuando aparece una vulnerabilidad crítica.
5. Grype: escanear vulnerabilidades desde imágenes, directorios o SBOM
Grype, también de Anchore, es un escáner open source para detectar vulnerabilidades conocidas en imágenes de contenedores, sistemas de archivos y SBOM.
Una práctica sólida es generar el SBOM con Syft y luego evaluarlo con Grype dentro del pipeline CI/CD.
6. Trivy: escáner todo en uno para contenedores, IaC, secretos y SBOM
Trivy es una de las herramientas open source más utilizadas en DevSecOps. Puede encontrar vulnerabilidades, malas configuraciones, secretos expuestos y generar o consumir SBOM en repositorios, imágenes, Kubernetes, nubes y sistemas de archivos.
Es ideal para equipos que buscan una herramienta simple, rápida y fácil de integrar en GitHub Actions, GitLab CI, Jenkins o pipelines internos.
7. OSV-Scanner: vulnerabilidades en dependencias open source
OSV-Scanner conecta las dependencias del proyecto con la base de datos OSV para encontrar vulnerabilidades conocidas. Es especialmente útil en proyectos con archivos lock, manifiestos de dependencias o SBOM.
Puede integrarse en CI/CD para detectar vulnerabilidades nuevas en pull requests o análisis programados.
8. OWASP Dependency-Check: SCA clásico para dependencias
OWASP Dependency-Check es una herramienta de Software Composition Analysis que intenta detectar vulnerabilidades públicamente conocidas dentro de las dependencias de un proyecto.
Sigue siendo útil en entornos Java, .NET, JavaScript y pipelines donde se requiere un reporte formal de dependencias vulnerables.
9. Dependency-Track: gestión continua de SBOM y riesgo
Dependency-Track, proyecto de OWASP, permite consumir SBOM y analizarlos de forma continua para identificar riesgos de seguridad, operación y licencias.
Su valor aparece cuando la empresa ya tiene varios proyectos, múltiples versiones, proveedores internos o externos y necesita una plataforma central para monitorear exposición a vulnerabilidades.
Uso recomendado: genera SBOM en cada build y súbelos a Dependency-Track para mantener trazabilidad histórica, riesgo por proyecto y alertas cuando aparezcan nuevas vulnerabilidades.
10. CycloneDX y SPDX: formatos estándar para SBOM
CycloneDX y SPDX son formatos clave para representar SBOM. La elección depende del caso de uso: CycloneDX es muy usado en seguridad de aplicaciones y SCA, mientras SPDX tiene fuerte adopción en cumplimiento, licencias y ecosistemas empresariales.
| Formato | Uso recomendado |
|---|---|
| CycloneDX | Seguridad de aplicaciones, SCA, Dependency-Track, análisis de componentes. |
| SPDX | Cumplimiento, licencias, auditoría legal y documentación formal. |
11. in-toto: verificar cada paso de la cadena
in-toto protege la integridad de la cadena de suministro verificando que cada paso del proceso se ejecutó como estaba previsto, por actores autorizados y sin manipulación del producto durante el tránsito.
Es especialmente útil cuando una organización necesita demostrar trazabilidad de construcción, pruebas, firma y entrega de artefactos.
12. Gitleaks: evitar secretos dentro del código
Gitleaks detecta secretos como contraseñas, tokens, claves API y credenciales expuestas en repositorios Git, archivos y directorios.
Debe ejecutarse en pre-commit, pull requests y repositorios históricos. Si encuentra una clave real, no basta con borrarla: se debe rotar inmediatamente.
13. Semgrep: análisis estático y revisión de patrones inseguros
Semgrep permite analizar código fuente con reglas de seguridad. Puede ayudar a detectar errores de programación, malas prácticas, vulnerabilidades y patrones inseguros antes de que el código avance en el pipeline.
Debe complementarse con revisión humana y pruebas, pero es muy útil para insertar seguridad desde las primeras etapas de desarrollo.
Tabla resumen de herramientas recomendadas
| Herramienta | Categoría | Uso principal |
|---|---|---|
| SLSA | Framework | Integridad de builds y artefactos. |
| Sigstore / Cosign | Firma | Firmar y verificar contenedores. |
| OpenSSF Scorecard | Evaluación | Medir salud de seguridad de repositorios. |
| Syft | SBOM | Generar inventario de componentes. |
| Grype | SCA | Escanear vulnerabilidades desde imágenes o SBOM. |
| Trivy | Scanner integral | Vulnerabilidades, secretos, IaC, contenedores y SBOM. |
| OSV-Scanner | Vulnerabilidades OSS | Detectar CVE en dependencias open source. |
| OWASP Dependency-Check | SCA | Análisis de dependencias vulnerables. |
| Dependency-Track | Gestión SBOM | Monitoreo continuo de riesgo por proyecto. |
| CycloneDX / SPDX | Estándares SBOM | Intercambio de inventarios de software. |
| in-toto | Integridad | Verificar pasos autorizados de la cadena. |
| Gitleaks | Secret scanning | Detectar credenciales expuestas. |
| Semgrep | SAST | Detectar patrones inseguros en código. |
Pipeline mínimo recomendado
Una empresa puede comenzar con un flujo simple y efectivo:
- Escanear secretos con Gitleaks antes del commit.
- Analizar código con Semgrep en cada pull request.
- Escanear dependencias con OSV-Scanner, Trivy, Grype o Dependency-Check.
- Generar SBOM con Syft en cada build.
- Guardar el SBOM en Dependency-Track.
- Escanear imagen de contenedor con Trivy o Grype.
- Firmar el artefacto con Cosign.
- Verificar firma y políticas antes del despliegue.
- Medir madurez del repositorio con OpenSSF Scorecard.
- Adoptar SLSA e in-toto progresivamente para builds verificables.
Errores comunes al proteger la cadena de suministro
- Generar SBOM solo una vez y no actualizarlo por cada release.
- Confiar en un único escáner sin validar falsos positivos o falsos negativos.
- No firmar imágenes de contenedores.
- No verificar firmas antes de desplegar.
- Permitir secretos dentro del repositorio.
- Usar dependencias sin bloqueo de versión.
- No revisar dependencias transitivas.
- Ejecutar pipelines CI/CD con privilegios excesivos.
- No separar ambientes de desarrollo, pruebas y producción.
- Ignorar licencias de terceros.
Buenas prácticas para empresas
- Exigir SBOM en todos los proyectos críticos.
- Definir una política de dependencias permitidas.
- Usar repositorios internos o proxies de paquetes.
- Bloquear versiones vulnerables en CI/CD.
- Firmar artefactos y verificar firmas antes de producción.
- Aplicar revisión obligatoria en cambios de pipelines.
- Evitar tokens permanentes en CI/CD.
- Usar identidades OIDC y credenciales temporales cuando sea posible.
- Monitorear nuevas vulnerabilidades sobre SBOM históricos.
- Capacitar a desarrolladores en seguridad de dependencias.
Preguntas clave
¿Qué es un SBOM?
Es un inventario de componentes de software. Permite saber qué librerías, paquetes, versiones y dependencias forman parte de una aplicación o artefacto.
¿SBOM reemplaza al escaneo de vulnerabilidades?
No. El SBOM da visibilidad. Luego necesitas herramientas como Grype, Trivy, OSV-Scanner o Dependency-Track para analizar riesgos.
¿Cuál es la herramienta más completa?
Trivy es una de las más completas para empezar porque cubre vulnerabilidades, secretos, configuraciones, contenedores, Kubernetes y SBOM.
¿Por qué firmar imágenes de contenedores?
Porque permite verificar que el artefacto desplegado proviene de una fuente confiable y no fue modificado después de su construcción.
¿Qué diferencia hay entre SLSA e in-toto?
SLSA es un marco de niveles y controles para mejorar integridad de la cadena. in-toto es una tecnología para verificar pasos concretos del proceso de construcción y entrega.
¿Una pyme necesita estas herramientas?
Sí, al menos en una versión mínima: escaneo de secretos, análisis de dependencias, generación de SBOM, escaneo de contenedores y firma de artefactos críticos.
Recomendamos
- Guía definitiva para construir un entorno DevSecOps con herramientas de código abierto
- Las 25 herramientas de ciberseguridad open source más utilizadas por administradores y analistas
- Ciberseguridad en Linux: 50 herramientas gratuitas para proteger servidores y estaciones
- Las mejores herramientas SIEM de código abierto para ciberseguridad
En resumen
Proteger la cadena de suministro del software exige visibilidad, automatización y verificación. Herramientas como Syft, Grype, Trivy, OSV-Scanner, Dependency-Track, Sigstore, Cosign, OpenSSF Scorecard, SLSA, in-toto, Gitleaks y Semgrep permiten construir una defensa práctica usando software libre.
La estrategia correcta no es elegir una sola herramienta, sino combinarlas dentro del pipeline: revisar código, detectar secretos, analizar dependencias, generar SBOM, escanear contenedores, firmar artefactos y verificar políticas antes del despliegue.
Conclusión editorial
La seguridad del software moderno ya no termina en el código. Empieza en la dependencia que eliges, continúa en el pipeline que construye tu aplicación y termina en el artefacto que llega a producción. Las herramientas open source permiten controlar ese recorrido sin depender completamente de soluciones cerradas.
