Durante años, el debate sobre la seguridad en la distribución de software se centró en una sola pregunta: ¿este binario está firmado digitalmente? Una firma digital válida se consideraba un sello de confianza, la prueba de que un archivo provenía de quien decía provenir y no había sido alterado. Esta suposición siempre fue incompleta, y los ataques a la cadena de suministro de los últimos años han puesto de manifiesto precisamente lo incompleta que era.
La incómoda realidad es que una firma solo prueba el último paso. Confirma que quien poseía la clave de firma aprobó el artefacto final. No dice nada sobre si el código fuente que se incluyó en ese artefacto era el código que realmente escribieron los desarrolladores, si el entorno de compilación se vio comprometido o si se inyectó algún paso malicioso en algún punto entre la confirmación y el resultado compilado.
Esta es la brecha que el marco de Niveles de Cadena de Suministro para Artefactos de Software (SLSA) busca cerrar, y el Nivel 3 de SLSA, en particular, es donde la firma de código ayuda a crear una cadena de custodia verificable que abarca desde el código fuente hasta el binario. Este blog explica qué requiere el Nivel 3 de SLSA, cómo funciona en conjunto con la firma de código y cómo las organizaciones pueden construir la procedencia verificable de la que depende la seguridad de la cadena de suministro de software moderna.
¿Por qué una firma por sí sola ya no es suficiente?
Para comprender la importancia de SLSA, es útil precisar qué prueba y qué no prueba una firma de código. Al firmar un binario, la firma establece dos cosas: que el artefacto fue aprobado por una entidad que posee la clave privada correspondiente y que el artefacto no ha sido modificado desde su firma. Ambas garantías son valiosas, y la firma de código sigue siendo un control de seguridad esencial.
Pero esto no prueba que el código fuente compilado en el binario coincida con el código fuente de su repositorio. No prueba que la compilación se haya ejecutado en un entorno limpio y seguro. No prueba que ningún paso de compilación no autorizado haya inyectado código adicional durante el proceso. Y no prueba que la persona o el sistema que activó la operación de firma estuviera autorizado para publicar ese artefacto en particular. Una firma es una declaración sobre el objeto final, no sobre el proceso que lo generó.
Los ataques más dañinos a la cadena de suministro explotan precisamente este punto ciego. No atacan la firma digital, ya que atacarla es difícil y está bien protegido. En cambio, atacan el proceso de compilación previo a la firma, de modo que el código malicioso fluye a través del proceso legítimo y emerge con una firma perfectamente válida. La firma es real, pero la confianza que transmite es infundada, porque el elemento que se firma ya estaba corrompido antes de llegar a la etapa de firma.
Lo que las organizaciones necesitan, y lo que los consumidores de software demandan cada vez más, es evidencia verificable sobre todo el proceso de producción, no solo la aprobación final. Necesitan poder responder preguntas como: ¿qué commit exacto produjo este binario?, ¿qué plataforma de compilación lo compiló?, ¿qué entradas se utilizaron para su creación?, y ¿se puede probar todo esto criptográficamente en lugar de simplemente afirmarlo? Este conjunto de evidencia verificable se denomina procedencia, y generar una procedencia a prueba de manipulaciones es el objetivo principal del marco SLSA.
¿Qué es SLSA y por qué existe?
SLSA son las siglas de Supply-chain Levels for Software Artifacts (Niveles de la cadena de suministro para artefactos de software) y es un marco de seguridad independiente del proveedor, propuesto originalmente por Google en 2021 y mantenido actualmente como un proyecto por la Open Source Security Foundation (OpenSSF). Su objetivo es proporcionar un conjunto común de estándares, acordados por la industria, para describir y verificar cómo se construyen los artefactos de software, de modo que tanto productores como consumidores puedan analizar la integridad de la cadena de suministro utilizando un vocabulario compartido.
El marco se basa en un concepto central: la procedencia. La procedencia son metadatos verificables que registran dónde, cuándo y cómo se produjo un artefacto de software. Un registro de procedencia completo identifica el repositorio de origen y la confirmación exacta, la plataforma de compilación que la realizó, las entradas y los parámetros utilizados, y un resumen criptográfico del artefacto resultante. Cuando esta procedencia es generada por un sistema de compilación confiable y firmada de forma que los propios pasos de compilación no puedan alterarla, se convierte en una prueba irrefutable de cómo se originó el artefacto.
Es importante tener claro qué es y qué no es SLSA. SLSA no es una herramienta, un escáner ni un producto que se instale. Es una especificación que define qué significa "seguro" en distintos niveles de madurez y está diseñada para aplicarse automáticamente mediante motores de políticas. Además, complementa, en lugar de reemplazar, otras prácticas de seguridad. El análisis de vulnerabilidades identifica debilidades conocidas en el código y las dependencias, mientras que SLSA verifica que la compilación en sí no haya sido manipulada. Ambas herramientas abordan diferentes amenazas y son más eficaces cuando se utilizan conjuntamente.
El marco de trabajo ha evolucionado significativamente. SLSA v1.0 se publicó en abril de 2023 y centró la especificación en la rama de compilación (Build Track) con niveles del 0 al 3. SLSA v1.1 se aprobó oficialmente en abril de 2025, lo que mejoró la precisión de los requisitos y convirtió varias recomendaciones anteriores en requisitos normativos más estrictos. SLSA v1.2, que introdujo la rama de código fuente (Source Track) para abordar la integridad del código fuente, se publicó en noviembre de 2025. El marco de trabajo continúa madurando, pero la rama de compilación (Build Track) sigue siendo la base estable y ampliamente adoptada, y es donde la relación con la firma de código es más directa.
El SLSA Build Track define cuatro niveles acumulativos, numerados del 0 al 3. Cada nivel se basa en el anterior, lo que significa que para alcanzar el Nivel 3 también es necesario cumplir con los requisitos de los Niveles 1 y 2. Esta estructura acumulativa es intencionada, ya que permite a las organizaciones adoptar SLSA de forma gradual en lugar de intentar una revisión completa de sus procesos de compilación de una sola vez.
| Nivel | Requisito básico | Amenaza principal abordada |
|---|---|---|
| Nivel 0 | Sin procedencia alguna | Sin protección; sin pruebas verificables de cómo se construyeron los artefactos. |
| Nivel 1 | Existe un registro de procedencia que describe cómo se construyó el artefacto. | Distribución accidental de versiones erróneas; trazabilidad básica |
| Nivel 2 | La procedencia está firmada y generada por una plataforma de compilación alojada. | Impide que el inquilino del edificio falsifique la procedencia. |
| Nivel 3 | Plataforma de compilación reforzada y aislada con claves de firma inaccesibles para los pasos de compilación. | Evita la falsificación de procedencia incluso a partir de credenciales comprometidas o amenazas internas. |
¿Qué requisitos exige realmente el nivel 3 de SLSA?
El Nivel 3 de SLSA introduce dos requisitos exigentes que van mucho más allá de la simple firma de la procedencia. Comprenderlos con precisión es clave para entender cómo el Nivel 3 establece una auténtica cadena de custodia.
El primer requisito es el aislamiento de la compilación . Los pasos de compilación deben ejecutarse en un entorno aislado que no pueda verse afectado por otros procesos de compilación, y dicho entorno no debe reutilizarse entre compilaciones. En la práctica, esto significa entornos efímeros y aislados, como contenedores o máquinas virtuales recién creadas, que se configuran específicamente para una única compilación y luego se eliminan. Este aislamiento impide que una ejecución de compilación interfiera con otra, incluso dentro del mismo proyecto, lo que elimina una clase de ataques en los que una compilación comprometida contamina las compilaciones posteriores.
El segundo requisito, y el más importante, es que la procedencia debe ser infalsificable . Debe ser imposible para los propios usuarios de la plataforma de compilación, incluyendo a quienes definen los pasos de compilación, falsificar la información de procedencia. Esto se logra garantizando que toda la procedencia sea generada por el servicio de compilación dentro de un plano de control de confianza y, fundamentalmente, que el material secreto utilizado para firmar la procedencia nunca sea accesible para los pasos de compilación definidos por el usuario. Las claves de firma pertenecen a la plataforma de compilación, no a la configuración de compilación que controlan los usuarios.
Este segundo requisito es lo que hace que el Nivel 3 sea tan potente, y es donde la conexión con la firma de código se vuelve estructural en lugar de incidental. En el Nivel 3, incluso un empleado malintencionado con acceso completo a la configuración de compilación no puede falsificar la procedencia, porque la clave de firma que la certifica reside en una parte del sistema a la que el empleado no puede acceder. Por lo tanto, la firma en la procedencia es una declaración confiable sobre la compilación, no algo que un paso de compilación comprometido podría haber fabricado.
El resultado es que la procedencia de Nivel 3 responde a preguntas que una firma por sí sola no puede. No se limita a decir "este artefacto fue aprobado", sino que indica "este artefacto se creó a partir de esta confirmación de código fuente exacta, en esta plataforma reforzada, mediante este proceso, y aquí está la prueba criptográfica generada por un sistema que los pasos de compilación en sí mismos no pudieron haber manipulado".
Cómo puede ayudar la consultoría de cifrado
La creación de una cadena de custodia verificable desde el código fuente hasta el binario reúne precisamente las disciplinas que definen la experiencia de Encryption Consulting: la protección de las claves de firma, la regulación de su uso y la generación de la evidencia auditable que exigen tanto la seguridad como el cumplimiento normativo. La conexión entre SLSA Nivel 3 y la firma de código no es casual, ya que ambas dependen en última instancia de la integridad de la infraestructura de firma, y ahí es donde se centra nuestro trabajo.
Nuestra plataforma CodeSign Secure proporciona la base de firma de la que depende una cadena de custodia de nivel 3. Protege las claves de firma privadas dentro de módulos de seguridad de hardware (HSM) validados según FIPS 140-3 y FIPS 140-2 de nivel 3 de proveedores como Thales , Entrust , Utimaco y Securosys , de modo que el material clave utilizado para firmar tanto los artefactos como la procedencia nunca existe en formato de software y no puede extraerse mediante un paso de compilación comprometido.
Esto aborda directamente el requisito de SLSA Nivel 3 de que los secretos de firma permanezcan inaccesibles para los pasos de compilación definidos por el usuario. La plataforma aplica un control de acceso basado en roles sobre quién puede solicitar y aprobar operaciones de firma, utiliza el sellado de tiempo RFC 3161 para que las firmas sean verificables a lo largo del extenso ciclo de vida del software publicado y registra cada evento de firma en un registro de auditoría inmutable que captura qué se firmó, cuándo, quién lo autorizó y a través de qué etapa del proceso.
Ese registro de auditoría es la evidencia verificable que convierte una afirmación de integridad de compilación en algo que un consumidor o regulador puede comprobar. Dado que CodeSign Secure se integra directamente en plataformas de CI/CD como Azure DevOps , Jenkins y GitLab , la firma se convierte en una etapa controlada y regulada dentro del proceso, en lugar de un paso manual, que es precisamente el modelo que requiere el enfoque automatizado de SLSA, impulsado por la plataforma de compilación.
Más allá de la plataforma en sí, nuestros equipos de asesoramiento ayudan a las organizaciones a diseñar la arquitectura más amplia que requiere una cadena de custodia verificable, desde evaluar la madurez actual de su canalización de compilación y firma en comparación con los niveles SLSA, hasta estructurar los controles clave de gestión y aislamiento que exige el Nivel 3, y alinear la evidencia resultante con los marcos regulatorios como el NIST SSDF , la Orden Ejecutiva 14028 y la Ley de Resiliencia Cibernética de la UE , que cada vez lo exigen más.
Para las organizaciones que también necesitan que la protección de claves de hardware subyacente se ofrezca como una capacidad gestionada, nuestra oferta de HSM como servicio proporciona una protección de claves validada por FIPS e independiente del proveedor que puede servir de base tanto para la firma de artefactos como para la firma de procedencia sin la carga de operar el hardware internamente.
Conclusión
La época en que una firma válida bastaba como prueba de la fiabilidad del software ha llegado a su fin. Los ataques más dañinos a la cadena de suministro de los últimos años no invalidaron las firmas; corrompieron el proceso de compilación antes de la firma, de modo que apareció código malicioso con una firma perfectamente legítima. Para superar esta vulnerabilidad, se requiere evidencia verificable de todo el recorrido, desde el código fuente hasta el binario, y eso es precisamente lo que SLSA, y en particular SLSA Nivel 3, se diseñó para proporcionar.
La relación entre SLSA Nivel 3 y la firma de código es fundamental. No son enfoques que compitan entre sí, sino capas complementarias de una misma cadena de custodia. La procedencia establece cómo se creó un artefacto y demuestra que no pudo haber sido falsificado ni siquiera por alguien con acceso a la información, mientras que la firma de código certifica que el artefacto y su procedencia son auténticos e inalterados.
A medida que los marcos regulatorios exigen cada vez más una integridad de compilación verificable en lugar de una mera autodeclarada, y que los compradores empresariales y gubernamentales comienzan a requerir niveles mínimos de SLSA como condición de adquisición, la capacidad de generar una cadena de custodia verificable para cada binario está pasando de ser un ideal de seguridad a una necesidad empresarial. Las organizaciones que desarrollen esta capacidad ahora, comenzando con la base de firma y avanzando gradualmente hacia el Nivel 3, serán las que estén en posición de demostrar, y no solo prometer, que su software es confiable.
En Encryption Consulting, nuestra plataforma CodeSign Secure y nuestros servicios de consultoría están diseñados para brindar esa base. Si busca establecer una cadena de custodia verificable para su cadena de suministro de software, con gusto le ayudaremos.
