CADENA DE SUMINISTRO DE SOFTWARE
Seguridad de la cadena de suministro de software: qué puede fallar y qué revisar
La mayor parte del código que desplegás lo escribió otra persona, y llega a producción por un pipeline de CI con acceso a tus secretos. La seguridad de la cadena de suministro de software (supply chain security) se trata de proteger ese camino: los paquetes de los que dependés, el build que convierte código en artefactos y las credenciales en el medio. Esta guía repasa las amenazas principales, los frameworks SLSA y SBOM y exactamente qué partes revisa Nurbak.
Crear cuenta y conectar GitHubNo guardamos tu código. Solo escribimos cuando pedís un PR de fix.
Tus dependencias también son tu código
Un CVE conocido en un paquete que importás es tan explotable como un bug tuyo. Saber qué versiones están afectadas es lo mínimo.
El CI es parte de la cadena
Un workflow que corre código no confiable con permisos de escritura o secretos puede dejar que alguien de afuera cambie lo que desplegás.
Los secretos son las llaves
Tokens en el código, en commits viejos o metidos en imágenes Docker le permiten a un atacante publicar, desplegar o leer datos en tu nombre.
Claros con el alcance
Nurbak revisa tu repo para estos riesgos. No genera SBOMs, no firma artefactos y no detecta paquetes maliciosos más allá de advisories conocidos.
Las principales amenazas a la cadena de suministro de software
Dependencias vulnerables
Paquetes directos y transitivos con CVEs publicados. El fix suele ser subir de versión, si sabés qué versión lo corrige. Análisis de composición de software.
Paquetes maliciosos y typosquatting
Paquetes publicados para parecerse a otros populares, o paquetes legítimos tomados por un atacante y actualizados con código malicioso. Los registries eliminan muchos, pero siguen apareciendo nuevos.
pull_request_target en GitHub Actions
GitHub advierte que estos workflows son privilegiados y pueden tener permisos de escritura y secretos, así que no deben hacer checkout de código no confiable de forks.
Inyección de scripts en workflows
Meter valores como el título de un pull request directo en un script de run le permite a un atacante inyectar comandos. GitHub recomienda pasarlos por una variable de entorno.
Actions de terceros sin fijar
Un tag como @v3 se puede mover. GitHub dice que fijar una action a un commit SHA completo es hoy la única forma de usarla como release inmutable.
Secretos filtrados
API keys y tokens en el código, en el historial de git o en Dockerfiles. Borrar la línea no los saca de los commits viejos. Escáner de secretos.
Frameworks: SLSA y SBOM
SLSA
Supply-chain Levels for Software Artifacts es un framework de seguridad, un checklist de estándares y controles para prevenir manipulaciones, mejorar la integridad y asegurar paquetes e infraestructura (slsa.dev).
Niveles de build de SLSA
En SLSA v1.0, Build L1 pide provenance que muestre cómo se construyó el paquete, L2 suma provenance firmada generada por una plataforma de build hosteada y L3 exige una plataforma de build endurecida.
SBOM
CISA describe un software bill of materials como un inventario anidado, una lista de los ingredientes que forman los componentes de software. Nurbak no genera SBOMs. Qué es un SBOM.
Amenazas a la cadena de suministro y qué revisa Nurbak
Cada amenaza, un control habitual y si Nurbak la cubre. Cuando no la cubre, lo decimos.
| Amenaza | Control habitual | Qué hace Nurbak |
|---|---|---|
| Dependencias vulnerables | SCA en cada cambio, lockfiles, actualizar a tiempo | Encuentra CVEs de dependencias con OSV y te dice la versión que lo corrige |
| Paquetes maliciosos, typosquatting | Revisar dependencias nuevas, lockfiles, advisories del registry | Solo marca paquetes con advisories conocidos en OSV. No detecta paquetes maliciosos nuevos |
| Mal uso de pull_request_target | Nunca hacer checkout de código no confiable en workflows privilegiados | Revisa los workflows de GitHub Actions buscando usos riesgosos de pull_request_target |
| Inyección de scripts en workflows | Pasar el input no confiable por variables de entorno | Revisa los workflows de GitHub Actions buscando inyección |
| Actions sin fijar | Fijar las actions de terceros a un commit SHA completo | No está entre los chequeos que listamos acá. Seguí la guía de GitHub |
| Secretos filtrados | Escaneo de secretos, también del historial, y rotación | Encuentra secretos en el código, en el historial de git y en Dockerfiles |
| Manipulación del build | Provenance de SLSA, firma de artefactos | No. Nurbak no firma artefactos ni genera provenance |
| Inventario desconocido | Generar y compartir un SBOM | No. Nurbak no genera SBOMs |
Cómo revisa Nurbak la cadena de suministro de tu repo
Creás una cuenta y conectás GitHub. Sirve para repos públicos y privados.
Elegís un repo. El modelo propio de Nurbak lo analiza sobre infraestructura efímera.
Recibís CVEs de dependencias con la versión que los corrige, problemas en GitHub Actions y Dockerfiles y secretos en el historial de git, con un score de seguridad de 0 a 100.
Con un clic abrís un pull request con el fix y un test de regresión de seguridad.
Con un plan, el repo se escanea de nuevo todos los días, así también detectás los CVEs recién publicados.
Preguntas sobre seguridad de la cadena de suministro de software
¿Qué es la seguridad de la cadena de suministro de software?
Es proteger todo lo que entra en tu software y el camino que recorre hasta producción: dependencias open source, sistemas de build y CI, las credenciales que usan y los artefactos que publican. Un atacante que compromete cualquiera de esas piezas puede llegar a tus usuarios sin tocar tu propio código.
¿Qué herramientas de seguridad de la cadena de suministro existen?
Hay herramientas SCA que cruzan tus dependencias con bases de vulnerabilidades, escáneres de secretos, escáneres de configuración de CI e IaC, generadores de SBOM y herramientas de firma y provenance para los builds. Nurbak cubre las tres primeras para tu repo de GitHub: CVEs de dependencias con OSV, secretos incluso en el historial de git y chequeos de GitHub Actions, Docker, Terraform y Kubernetes.
¿Cómo mejoro la seguridad de la cadena de suministro en npm?
Commiteá tu lockfile, revisá las dependencias nuevas antes de sumarlas, mantené las versiones al día y contrastalas con vulnerabilidades conocidas. El propio comando npm audit envía una descripción de tus dependencias a tu registry por defecto y pide un reporte de vulnerabilidades conocidas. Nurbak también revisa las dependencias de npm contra OSV y te muestra la versión que corrige el problema.
¿Nurbak detecta paquetes maliciosos?
Solo cuando un paquete tiene un advisory conocido en la base de OSV. Nurbak no analiza el comportamiento de los paquetes para detectar paquetes maliciosos o de typosquatting nuevos, así que combinalo con los advisories del registry y una revisión cuidadosa de las dependencias nuevas.
¿Nurbak genera un SBOM o firma artefactos?
No. Nurbak no genera SBOMs, no firma artefactos y no produce provenance de SLSA. Encuentra dependencias vulnerables, secretos y malas configuraciones de CI en tu repo. Nuestra guía qué es un SBOM explica cómo funcionan.
¿Qué riesgos de GitHub Actions revisa Nurbak?
Nurbak revisa tus workflows buscando inyección de scripts desde input no confiable y usos riesgosos de pull_request_target, además de otras malas configuraciones en GitHub Actions, Dockerfiles, Terraform y Kubernetes. Mirá el escáner de seguridad para GitHub y nuestra guía de herramientas de detección de secretos.
¿Cuánto cuesta?
El primer escaneo es gratis y te muestra completos los 3 hallazgos más importantes, más 1 PR con fix gratis. Los planes son USD 79 por mes para 1 repo y USD 199 por mes para hasta 5 repos, con escaneos diarios. Para más de 5 repos hay un plan Enterprise. Cobramos por repo, no por desarrollador. Mirá los precios.
Revisá hoy la cadena de suministro de tu repo
Conectá GitHub y recibí gratis tu score de seguridad y tus 3 hallazgos más importantes.
Escanear mi repo