Buenas prácticas de seguridad de la cadena de suministro de software

Código fuente

• Exija una autenticación sólida. Use autenticación multifactor en todas las cuentas de alojamiento de código.
• Proteja la rama principal. Exija revisión antes de fusionar y no permita que nadie haga push directamente a una rama de lanzamiento.
• Mantenga los secretos fuera del código. Búsquelos en cada push y rote todo lo que haya quedado expuesto.
• Trate los archivos de workflow como código. Un cambio en un pipeline puede llegar a sus secretos, así que exija que los revisen sus responsables.

Dependencias

• Añada un lockfile al repositorio e instale a partir de él. Use npm ci y sus equivalentes, para que los builds no incorporen versiones nuevas por accidente. Un lockfile tiene sus límites, pero es el punto de partida.
• Añada un periodo de espera para las versiones nuevas. Las versiones maliciosas suelen detectarse poco después de aparecer, así que no adoptar una versión el mismo día en que se publica da margen para que eso ocurra.
• Limite los scripts de instalación. Desactívelos donde pueda. Los scripts que se ejecutan al instalar son la vía por la que se propagan los gusanos de npm.
• Examine las dependencias nuevas. Compruebe que el nombre no sea un caso de typosquatting y fíjese en el mantenimiento y la popularidad. OpenSSF Scorecard automatiza parte de esto.
• Proteja los nombres de los paquetes internos. Use ámbitos y la configuración del registro, para que un paquete público no pueda ocupar el lugar de uno interno mediante una confusión de dependencias.
• Recorte lo que no necesite. Cada dependencia es una cosa más que monitorizar.

Build y CI/CD

• Fije las GitHub Actions a un hash de commit completo. Las etiquetas se pueden mover, como demostró el ataque a tj-actions.
• Limite lo que puede hacer cada job. Conceda al token del workflow el mínimo permiso que necesite y use credenciales de corta duración en lugar de secretos de larga duración.
• Restrinja el tráfico saliente. Un build necesita paquetes de fuentes conocidas y publica en lugares conocidos. Bloquee todo lo demás, y los secretos robados no tendrán adónde ir. Consulte política de salida de GitHub Actions.
• Ejecute cada job en un entorno nuevo y aislado. Nada debería pasar de un job al siguiente, y menos aún desde una pull request de un colaborador externo.
• Trate las cachés como una entrada. Una caché envenenada sobrevive entre builds, y lo que restaura es fácil de pasar por alto. Consulte caché de GitHub Actions.

Para ver la lista completa, consulte la lista de comprobación de seguridad del pipeline de CI/CD y cómo se compara la seguridad de los runners.

Lanzamiento

• Genere una SBOM para cada versión, a partir del build. Consérvela junto al artefacto. Consulte buenas prácticas de SBOM.
• Firme los artefactos y publique la procedencia. Así, los consumidores pueden comprobar de dónde procede una versión. SLSA define los niveles.
• Compile las versiones solo en CI. Una versión hecha en un portátil no tiene detrás ningún registro fiable.
• Use un único artefacto desde las pruebas hasta producción. Promueva lo que ha probado en lugar de recompilarlo, para que el registro siga siendo fiel.

Después del lanzamiento

• Monitorice lo que ha distribuido. Siga cotejando las SBOM de las versiones con soporte con las nuevas vulnerabilidades.
• Priorice con algo más que CVSS. Use CISA KEV, EPSS y el contexto. Consulte cómo priorizar vulnerabilidades.
• Sepa cuánto tiempo estuvo expuesto. El historial de builds muestra qué versiones contenían un paquete y desde cuándo.
• Tenga un plan antes de necesitarlo. Decida quién hace el triaje, quién corrige y quién habla con los clientes. Consulte el ciclo de vida de la gestión de vulnerabilidades.
• Practique con un escenario real. Pregúntese cuánto tardaría en encontrar todas las versiones con un paquete determinado. Si la respuesta es días, empiece por ahí.

Qué hacer primero

Cuándo	Qué hacer
Esta semana	Autenticación multifactor, lockfiles en CI, GitHub Actions fijadas, tokens de workflow con el mínimo privilegio
Este mes	SBOM de cada build de lanzamiento, alertas de dependencias con un responsable, detección de secretos
Este trimestre	Reglas de tráfico saliente para los builds, monitorización de las versiones distribuidas, un plan de respuesta probado
Después	Procedencia firmada, una revisión formal de la cobertura de SLSA o NIST SSDF, SBOM de proveedores

Cuáles de estas prácticas cubre CRACI

CRACI cubre el build y todo lo que viene después. Como runner de GitHub Actions, ejecuta cada job en su propia máquina virtual aislada, registra en una SBOM cada paquete que descarga el job, marca los paquetes restaurados desde cachés de CI y aplica una política de salida que bloquea las conexiones que su build no necesita. Después sigue comprobando lo distribuido, muestra qué builds contenían un paquete vulnerable y puede bloquear builds con controles de política.

El resto queda en manos de sus otras herramientas: CRACI no escanea código fuente ni secretos, no detecta nuevos paquetes maliciosos por su comportamiento y no firma SBOM ni procedencia. Consulte la comparativa de herramientas de seguridad de la cadena de suministro de software para ver qué cubre cada carencia.

Buenas prácticas de seguridad de la cadena de suministro: preguntas frecuentes

¿Cómo se protege una cadena de suministro de software?

Sepa lo que distribuye con una SBOM de cada build de lanzamiento, controle lo que entra con lockfiles y una revisión previa, proteja el build limitando los secretos y el tráfico saliente, y siga monitorizando lo que ha lanzado.

¿Qué debería hacer primero un equipo pequeño?

Active la autenticación multifactor, instale a partir de lockfiles en CI, fije las GitHub Actions a hashes de commit y conceda a los tokens de workflow el mínimo permiso que necesiten. Estos pasos llevan días y cierran vías de ataque habituales.

¿Cómo se evitan los paquetes maliciosos?

Ningún paso por sí solo lo consigue. Retrase la adopción de versiones nuevas, limite los scripts de instalación y examine las dependencias nuevas. Restringir el tráfico saliente de los builds limita el daño si un paquete malicioso se cuela.

¿Por qué fijar las GitHub Actions a un hash de commit?

Porque una etiqueta de versión se puede mover a otro código. Un hash de commit completo siempre hace referencia al mismo código, de modo que una etiqueta secuestrada no llega a su pipeline.

¿Con qué frecuencia debe revisarse la cadena de suministro?

La monitorización debe ser continua. Revise su política de dependencias, los permisos de los workflows y el plan de respuesta al menos una vez al año, y después de cualquier incidente en su stack.