Cadena de suministro de software: ¿basta con firmar?

Firmar es un gran paso, pero no cierra la discusión. En este artículo te contamos dónde conviene poner la firma, cómo lograr que tu plataforma rechace lo que no puede verificar y qué riesgos quedan abiertos aun con todo firmado. Lo hacemos a partir de una implementación real de nuestro equipo en AWS.

¿Qué significa asegurar la cadena de suministro de software?

Asegurar la cadena de suministro de software es poder comprobar, en cada paso entre el código y producción, de dónde viene cada pieza y que nadie la alteró en el camino. Incluye las librerías que usas, los paquetes que construye tu pipeline y lo que finalmente se ejecuta en tus servidores.

En un modelo GitOps, el repositorio de código funciona como fuente de verdad. Una herramienta como Argo CD compara lo que dice el repositorio con lo que corre en el clúster de Kubernetes y los sincroniza. El riesgo está en que una rama del repositorio puede cambiar después de aprobada.

Por eso, en una primera etapa, Javier Sepúlveda, de nuestro equipo, reemplazó esa referencia por artefactos inmutables: paquetes con un identificador único, llamado digest, que no se puede modificar. Con eso quedó resuelto qué se despliega. Faltaba comprobar que cada paquete saliera de su propio pipeline antes de usarlo.

Firma de artefactos: identidad sin llaves que custodiar

La firma de artefactos agrega ese control. En la implementación de Javier sobre Amazon EKS, el servicio administrado AWS Signer firma cada paquete con un perfil de firma: una identidad criptográfica cuyas llaves gestiona AWS. Tu equipo nunca ve ni guarda la llave privada, y así desaparece uno de los riesgos más comunes al firmar código.

El formato de la firma lo define Notation, la herramienta del Notary Project, un proyecto de la Cloud Native Computing Foundation (CNCF). La verificación descansa entonces sobre un estándar abierto que otras herramientas también reconocen.

Para un líder de TI, la decisión que más pesa es otra: la firma es automática. Desde noviembre de 2025, Amazon ECR, el registro de contenedores de AWS, puede firmar cada paquete en el momento en que se sube, según reglas por repositorio. El pipeline solo espera la confirmación, así que tus equipos de desarrollo no suman pasos manuales.

Dos puntos de control antes de llegar a producción

La firma solo sirve si alguien la revisa en el momento correcto. En esta implementación, la arquitectura define dos fronteras de verificación, cada una con una política de confianza que acepta únicamente las firmas de un perfil específico:

1. Antes de construir. El pipeline verifica que las librerías base estén firmadas por el perfil oficial. Si alguien publicó una librería por fuera del proceso o la modificó después de firmarla, la construcción se detiene antes de generar cualquier paquete.
2. Justo antes de desplegar. Dentro del clúster, un paso previo a la sincronización de Argo CD verifica la firma del paquete final. Así se comprueba, en el último momento posible, que lo que se firmó en el registro es lo mismo que se va a aplicar.

Entre ambas fronteras hay un control humano. La promoción a un entorno se hace con una solicitud de cambio (pull request) que fija el identificador exacto del paquete y solo un rol definido puede aprobarla. Queda registro de quién aprobó qué versión y esa versión ya no puede cambiar.

Este esquema se monta sobre tu flujo actual de integración y entrega continua sin reemplazarlo.

La prueba que importa: rechazar lo que no se puede verificar

Ver un despliegue verificado con éxito tranquiliza, pero dice poco sobre lo que pasaría con un paquete sospechoso. Por eso Javier repitió la verificación del clúster, con la misma identidad y la misma política de confianza, contra un paquete que nunca existió en el registro.

La verificación falló, como debía. Según la documentación de Argo CD, cuando falla un paso previo a la sincronización, todo el proceso se detiene y se marca como fallido. Nada se aplica en el clúster.

Te recomendamos incluir una prueba de rechazo en cualquier implementación de este tipo. Es la manera de comprobar que el control detiene un despliegue cuando debe hacerlo.

¿Qué no garantiza una firma digital?

Una firma prueba dos cosas: el origen del paquete, que salió de tu pipeline y no de un tercero, y su integridad, que no cambió desde que se firmó. Hay riesgos que quedan por fuera:

• Si una dependencia vulnerable entró al paquete antes de firmarlo, la firma la certifica igual. El contenido puede ser inseguro y estar perfectamente firmado.
• Un paquete antiguo, con una firma todavía válida, podría volver a desplegarse. La firma dice que esa versión es auténtica; decidir si debe correr hoy es otra tarea.
• Tampoco sabes, solo con la firma, cómo se construyó el paquete ni con qué insumos.

Por eso la firma tiene que convivir con otros controles: análisis de vulnerabilidades, reglas sobre qué versiones se aceptan en cada entorno y prácticas maduras de DevSecOps

Del control a la confianza: SLSA como siguiente paso

Después de firmar, el paso natural es documentar la procedencia: cómo, dónde y con qué se construyó cada artefacto. Ese es el terreno de SLSA, una especificación construida por consenso de la industria que define niveles para mejorar de forma gradual la seguridad de la cadena de suministro.

Su versión vigente, la 1.2, trata por separado los controles del código fuente y los de la construcción. Si tu equipo quiere ver el detalle técnico, Javier documentó la implementación completa, con su código, en la serie GitOps Beyond Git (en inglés).

Conclusión: firmar es el comienzo

Cuando firmas tus artefactos y obligas a tu plataforma a verificarlos, nadie puede introducir un paquete ajeno o alterado sin que el despliegue se detenga y con la firma automática el costo operativo es bajo.

Lo siguiente es saber qué garantiza cada control de tu cadena y qué deja por fuera. Si mañana te lo pidiera un auditor, ¿podrías demostrar que lo que corre en producción es lo que tu equipo aprobó?

En Pragma acompañamos a los equipos de tecnología a diseñar plataformas en la nube donde la seguridad hace parte del flujo de entrega, con una estrategia de seguridad en la nube que no acumula deuda técnica.

¡Conversemos sobre la seguridad de tu cadena de suministro!