Procedencia de compilación y firma de SLSA en canalizaciones de CI/CD

Hoy en día, la mayoría de los equipos de seguridad cuentan con una lista de componentes de software (SBOM, por sus siglas en inglés) . Sin embargo, una lista de componentes de software solo cuenta una parte de la historia. Indica qué contiene el software, pero no dice nada sobre cómo se construyó ni si alguien lo manipuló entre el repositorio de código fuente y el servidor de producción.

La garantía de integridad de la compilación, y no solo la catalogación de componentes, es el objetivo que buscan subsanar la procedencia de la compilación y la firma de artefactos. En resumen, la procedencia de la compilación es un registro firmado y verificable de cómo, dónde y desde qué fuente se compiló un artefacto de software, y la firma de artefactos es el sello criptográfico que hace que dicho registro sea a prueba de manipulaciones.

Este blog explica qué significa realmente la procedencia de las compilaciones, cómo funcionan en la práctica los niveles del marco de trabajo Supply-chain Levels for Software Artifacts (SLSA) y cómo encaja la firma de artefactos en una canalización de CI/CD.

Procedencia de compilación SLSA, definida: una certificación completa firmada, generada por la propia plataforma de compilación en lugar de un script controlado por el usuario, que registra la confirmación exacta del código fuente, el sistema de compilación y las entradas detrás de un artefacto, para que un verificador pueda confirmar criptográficamente qué se compiló y cómo, en lugar de confiar en la afirmación no verificada de un desarrollador o de un registro de CI.

Puntos Clave

• Un SBOM enumera los componentes; la procedencia demuestra cómo se realizó la compilación. La brecha de seguridad SUNBURST de SolarWinds de 2020, la puerta trasera de XZ Utils de 2024 y el gusano npm Shai-Hulud de 2025 superaron las comprobaciones a nivel de componentes porque la vulnerabilidad se encontraba en la ruta de compilación o publicación, no en una dependencia listada.
• SLSA v1.2 (noviembre de 2025) es la versión estable actual; su Build Track define tres niveles (un cuarto nivel, compilaciones herméticas reproducibles, está previsto, pero aún no forma parte de la especificación).
• Esta página explica qué es la procedencia y cómo se comparan los niveles SLSA. Para obtener información detallada sobre la implementación de CI/CD, la identidad del servicio OIDC, la doble firma, las puertas de aprobación y el flujo de trabajo de ejemplo, consulte Fortalecimiento de la seguridad de la cadena de suministro con SLSA Nivel 3 y firma de código..
• La firma de un certificado de procedencia que no se verifica en el momento del despliegue no ofrece ninguna protección; la verificación debe ser un requisito obligatorio, no una comprobación opcional.

Por qué las SBOM por sí solas ya no son suficientes

Un SBOM es esencialmente una lista de componentes. Indica qué bibliotecas, paquetes y dependencias se incluyen en el software. Esto resulta útil para detectar vulnerabilidades conocidas y gestionar las obligaciones de licencia. Sin embargo, no proporciona información sobre la integridad del proceso de compilación en sí.

Los atacantes conocen esta limitación desde hace años. En la brecha de seguridad SUNBURST de SolarWinds , todos los componentes de software de la compilación afectada eran legítimos. El atacante había comprometido el proceso de compilación e inyectado código malicioso en el resultado compilado. Un SBOM habría listado componentes limpios y de confianza. No habría detectado la vulneración porque el ataque se produjo dentro del proceso de compilación, no dentro de una dependencia.

Incidentes más recientes siguen el mismo patrón. La puerta trasera XZ Utils de 2024 (CVE-2024-3094) y el gusano npm Shai-Hulud de 2025 eludieron las comprobaciones a nivel de componentes. El gusano Shai-Hulud lo logró comprometiendo la publicación de paquetes de confianza y los flujos de trabajo de CI/CD. En ambos casos, se alteró la ruta de compilación o lanzamiento en sí, no una dependencia listada.

Por eso, los reguladores, los equipos de seguridad empresarial y los ingenieros de DevSecOps ahora exigen algo más específico. Quieren una prueba criptográfica e inalterable de que un artefacto se creó a partir de una fuente conocida, utilizando un proceso definido y en un sistema de compilación verificado. Esta prueba se denomina procedencia de la compilación.

La norma NIST SP 800-204D , publicada en febrero de 2024, aborda este tema directamente. Enfatiza la importancia de las certificaciones firmadas criptográficamente como mecanismo fundamental para establecer la integridad y la procedencia del software en los flujos de trabajo de CI/CD. La publicación también explica que los SBOM por sí solos no pueden utilizarse para la gestión de vulnerabilidades, ya que proporcionan un inventario de componentes en lugar de evidencia criptográfica sobre cómo se construyó el software o si el proceso de construcción fue confiable.

Esa evidencia criptográfica es precisamente lo que proporciona la procedencia de la compilación. La cuestión práctica, entonces, es qué registra y cómo está estructurado ese registro.

¿Qué es la procedencia de la compilación?

La procedencia de la compilación es un registro verificable que normalmente está firmado criptográficamente y responde a cuatro preguntas sobre un artefacto de software.

• Qué: El artefacto exacto, identificado mediante un hash criptográfico (resumen SHA-256).
• Dónde: El repositorio de origen y la confirmación específica que lo generó.
• Cuándo: El momento en que se realizó la compilación.
• Cómo: El sistema de compilación, la definición del flujo de trabajo, el entorno de ejecución y los datos de entrada utilizados.

En conjunto, estos detalles crean una cadena de custodia rastreable y verificable desde la confirmación del código hasta el artefacto desplegable. Cuando ocurre un incidente, se puede rastrear hacia atrás a través de los registros de procedencia. Si algo parece sospechoso en una puerta de despliegue, se puede verificar la información criptográficamente en lugar de depender de una afirmación del desarrollador o un registro de CI que cualquier persona con acceso al pipeline podría modificar.

La procedencia se expresa mediante el marco de certificación integral. Una certificación integral es un documento firmado que vincula metadatos a un artefacto. Consta de tres partes: el tipo de declaración (qué tipo de afirmación es), el sujeto (el artefacto, identificado por su resumen) y el predicado (los metadatos propiamente dichos, como el repositorio, el flujo de trabajo, los parámetros de compilación y la identidad del compilador). La procedencia de compilación SLSA es un predicado de procedencia estandarizado que se incluye en una declaración de certificación integral.

Definir la procedencia es una cosa; establecer un estándar medible sobre cuán confiable debe ser es la función del marco SLSA.

SLSA: Un marco para la integridad de la compilación

SLSA es un marco de trabajo abierto mantenido por la Open Source Security Foundation (OpenSSF) que define requisitos cada vez más estrictos sobre cómo se debe compilar el software y cómo se debe generar y proteger su procedencia. La versión estable actual es SLSA v1.2 (noviembre de 2025), que añade una pista de código fuente a la pista de compilación existente; esta última define tres niveles distintos de seguridad creciente.

Nivel 1 de SLSA: Existe procedencia

El proceso de compilación genera un documento de procedencia que describe cómo se produjo el artefacto. Este documento se distribuye junto con el artefacto. En el Nivel 1, la procedencia no está firmada criptográficamente. Cualquiera que pueda modificar el script de compilación también puede modificar la procedencia. El Nivel 1 es un punto de partida que mejora la trazabilidad y facilita la respuesta a incidentes, pero no impide que un atacante decidido falsifique información.

SLSA Nivel 2: Firmado por la plataforma de compilación

La procedencia debe ser generada y firmada por la propia plataforma de compilación, no por un script de compilación controlado por el usuario. La clave de firma la conserva la plataforma y no es accesible para los pasos de compilación. Esta distinción es fundamental. Si un atacante compromete un script de compilación en el Nivel 2, no podrá falsificar un documento de procedencia válido porque no tiene acceso a la clave de firma de la plataforma. El Nivel 2 es el objetivo práctico para la mayoría de los equipos. Se puede lograr en GitHub Actions o GitLab CI con una configuración mínima del pipeline.

Nivel 3 de SLSA: Entorno de construcción reforzado y aislado

El entorno de compilación está reforzado para que la clave de firma y el material secreto nunca sean accesibles para los pasos de compilación definidos por el usuario, incluso si dichos pasos se ven completamente comprometidos. La plataforma de compilación garantiza el aislamiento a nivel de infraestructura. El nivel 3 es el objetivo apropiado para componentes críticos, software distribuido en entornos regulados y cualquier elemento con una superficie de ataque de alto riesgo.

Una forma sencilla de entenderlo: el Nivel 1 es un recibo. El Nivel 2 es un recibo con el sello oficial de la plataforma, que el desarrollador no pudo haber impreso él mismo. El Nivel 3 es un recibo generado dentro de una sala cerrada con llave, donde el operador no tenía acceso al mecanismo de sellado.

Existe también un cuarto nivel: compilaciones herméticas y totalmente reproducibles con revisión por dos partes. Este nivel figura en el borrador original de SLSA y está previsto para una versión futura, pero no forma parte de la especificación actual v1.2, por lo que el Nivel 3 es el nivel más alto definido en la especificación que debe cumplir una plataforma de compilación en la actualidad.

Niveles de construcción de pistas SLSA, lado a lado

Nivel	Requisito de procedencia	¿Quién puede falsificarlo?	Esfuerzo típico
Nivel 1	Existe, distribuido junto con el artefacto	Cualquiera que pueda modificar el script de compilación	Bajo; agregar un paso de generación de procedencia
Nivel 2	Generado y firmado por la plataforma de compilación, no por el script de compilación.	Nadie sin acceso a la clave de firma de la plataforma podrá hacerlo.	Moderado; alcanzable en GitHub Actions o GitLab CI con configuración de canalización.
Nivel 3	Generado en un entorno de compilación aislado y reforzado.	Nadie, ni siquiera comprometiendo completamente el paso de construcción.	Más alto; requiere entornos de compilación efímeros y de un solo uso.

Una vez definidos los niveles, el siguiente paso consiste en observar cómo fluyen la procedencia y la firma a través de una canalización de CI/CD en funcionamiento.

Cómo se integra todo el flujo de trabajo en CI/CD

Así es como fluyen la procedencia de las compilaciones y la firma a través de una canalización típica de CI/CD, desde la confirmación hasta el despliegue.

1. Todo comienza cuando un desarrollador sube código a una rama, y ​​ese evento de subida activa el proceso de integración continua (CI).
2. A continuación, se ejecuta el proceso de compilación, que consiste en compilar o empaquetar el código fuente, resolviendo las dependencias a partir de versiones fijas basadas en resúmenes en lugar de etiquetas mutables.
3. La procedencia la genera la propia plataforma, no el script de compilación, que produce una certificación completa que captura la confirmación de origen, la identidad del flujo de trabajo, el entorno del ejecutor y el resumen SHA-256 del artefacto de salida.
4. En una implementación de firma sin clave, la certificación se firma mediante un servicio que emite un certificado de corta duración vinculado a la identidad OIDC (OpenID Connect) de la plataforma de compilación, lo utiliza para firmar la certificación y registra el evento de firma en un registro público de transparencia a prueba de manipulaciones. Dado que el certificado es de corta duración, no hay claves privadas de larga duración que almacenar, rotar o revocar.
5. Para las versiones de nivel de producción, un proceso de aprobación requiere la autorización de un quórum definido de aprobadores antes de que se pueda proceder con la firma, de modo que ninguna identidad comprometida pueda aprobar una versión por sí sola.
6. La certificación firmada se almacena junto con el artefacto en un registro de contenedores o en el repositorio de artefactos, en un registro de transparencia o en ambos.
7. Finalmente, la verificación se ejecuta en la puerta de despliegue. Antes de que un artefacto pase a los entornos de prueba o producción, una comprobación de políticas verifica la firma y confirma que la certificación proviene del repositorio y flujo de trabajo esperados. También verifica que el resumen del artefacto coincida con el registro de procedencia. Los artefactos que no superan la verificación se rechazan automáticamente.

GitLab CI cuenta con soporte de procedencia integrado. La verificación se puede realizar mediante la CLI de GitHub, una herramienta de verificación de firmas o un controlador de admisión de Kubernetes que aplica políticas a cada despliegue de pod.

Puertas de aprobación

No todas las compilaciones requieren aprobación humana; las compilaciones internas o de desarrollo pueden generar y firmar la procedencia automáticamente. Las versiones de nivel de producción son diferentes: requieren aprobación M-de-N antes de que el servicio de firma actúe sobre dicha procedencia, aplicada por el propio motor de políticas de la plataforma de firma en lugar de por la lógica de la canalización que podría eludir un paso de compilación modificado. Decida con anticipación quiénes son los aprobadores elegibles para cada nivel de lanzamiento y qué sucede si la aprobación caduca, si la canalización falla o si se recurre a una ruta más lenta y explícitamente manual.

Manejo de fallos y reversión

Un fallo de procedencia o firma debería bloquear la publicación, no convertirse en una advertencia. Si la plataforma no puede generar la procedencia, si no se otorga la aprobación o si el servicio de firma no está disponible, el artefacto no debería publicarse. Dado que los certificados de firma sin clave tienen una vida útil corta y no representan una credencial permanente, la reversión en este caso es más limitada que en un escenario de compromiso de clave: si un artefacto firmado y verificado resulta posteriormente haber sido creado a partir de una confirmación de código fuente comprometida, la respuesta es revocar la confianza en ese artefacto específico en la política de verificación (bloquear ese resumen) y revertir las implementaciones al último artefacto válido conocido y verificado de forma independiente, sin tocar la infraestructura de firma en sí.

Localización de averías

Síntoma	Causa probable	Qué comprobar
La verificación falla a pesar de que el artefacto es legítimo.	La certificación fue generada por un paso de compilación en lugar del plano de control de confianza de la plataforma.	Confirme que la función de procedencia nativa de la plataforma CI esté habilitada, y no que un script personalizado esté generando la certificación.
La certificación está presente, pero la verificación de la firma falla.	El verificador está realizando la comprobación con el emisor OIDC incorrecto o con una entrada de registro de transparencia caducada.	Confirme que la identidad del certificado y el emisor esperados coinciden con la plataforma de compilación que se está utilizando.
Discrepancia en el resumen entre el artefacto y el registro de procedencia.	El artefacto fue reconstruido o reempaquetado después de que se generó la procedencia.	Asegúrese de que la firma se realice en el artefacto exacto que se publicará, sin ningún paso de modificación posterior a la procedencia.
La dependencia de terceros no tiene procedencia para verificar.	El paquete upstream no publica la procedencia SLSA.	Tratar como una brecha conocida; evaluar el riesgo en función del rol de ese componente en lugar de asumir la equivalencia con uno verificado.

Integrar esto en un único sistema es sencillo; implementarlo en toda una organización requiere un enfoque más minucioso.

Consideraciones de implementación empresarial

Empieza con los artefactos críticos, no con todo.

No todos los componentes de una gran organización requieren SLSA Nivel 3 desde el primer día. Comience por identificar qué componentes de software están orientados al cliente, se implementan en entornos regulados o forman parte de infraestructura crítica. Aplique SLSA Nivel 2 primero a estos componentes, establezca los controles de verificación que lo garantizan y, posteriormente, extiéndalo de forma más generalizada. Este enfoque gradual permite gestionar el esfuerzo con rapidez y obtener beneficios en materia de cumplimiento normativo.

La verificación es tan importante como la firma.

Muchos equipos implementan la firma digital y dan por hecho que el trabajo está hecho. La procedencia solo ofrece un verdadero valor de seguridad cuando se verifica activamente en el momento de la implementación. Añada un paso de verificación a cada canalización de implementación. Configure su controlador de admisión de Kubernetes o puerta de implementación para rechazar los artefactos que carezcan de una certificación válida y conforme a las políticas. Un artefacto cuya procedencia no coincida con el repositorio de origen, la rama o la identidad del flujo de trabajo esperados nunca debería llegar a producción.

Anclar dependencias a resúmenes

La procedencia de la compilación describe con precisión los componentes de entrada solo si estos son estables. Si su canalización resuelve las dependencias dinámicamente a partir de etiquetas de versión modificables, una actualización maliciosa de un paquete de registro público puede alterar el contenido final del artefacto sin modificar el código fuente. Asigne dependencias a resúmenes SHA-256 específicos en lugar de a etiquetas de versión. Esto garantiza la reproducibilidad de las compilaciones y la relevancia de la procedencia.

Las firmas de larga duración requieren marcas de tiempo.

Los certificados de firma de corta duración son ideales para la firma en tiempo de compilación, donde la verificación se realiza poco después de la firma. Si necesita verificar artefactos de lanzamiento años después de su firma, los certificados de corta duración por sí solos no son suficientes, ya que el certificado habrá caducado mucho antes de la verificación. En esos casos, también necesita una marca de tiempo RFC 3161 de una Autoridad de Marcas de Tiempo de confianza, que vincula la firma a un momento que se puede verificar independientemente de la validez del certificado. Para obtener la máxima seguridad, almacene sus claves de firma en un HSM (módulo de seguridad de hardware) para evitar la extracción de claves y garantizar la seguridad física de su infraestructura de firma.

Incluso los equipos que siguen estas prácticas al pie de la letra pueden cometer errores, por lo que vale la pena señalar los fallos que con mayor frecuencia socavan la procedencia de las construcciones en la práctica.

Dónde falla la procedencia

• Generación de procedencia dentro del script de compilación: Si el script de compilación controla el generador de procedencia, un atacante que lo vulnere puede falsificar la información que proporciona dicha procedencia. La plataforma de compilación debe generar la procedencia, fuera de los pasos controlados por el usuario. Esta distinción es la que separa el Nivel 2 del Nivel 1 de SLSA.
• Firma sin controles de verificación: Generar certificados firmados sin aplicarlos durante el despliegue crea una falsa sensación de seguridad. Todo proceso de producción debe incluir un paso de verificación que rechace los artefactos que no cumplan con los requisitos.
• Uso de claves de larga duración sin protección HSM ni planes de rotación: Una clave de firma comprometida invalida toda la cadena de confianza. Las claves estáticas almacenadas en software deben estar protegidas por HSM y respaldadas por procedimientos documentados de rotación y revocación.
• Considerar la procedencia como un mero trámite documental: La procedencia solo aporta valor cuando influye en las decisiones de control de acceso y respuesta a incidentes. Si su política de verificación no se aplica automáticamente, solo ofrece una apariencia de cumplimiento, no seguridad real.
• Ignorar la procedencia de las dependencias de terceros: Es posible que su código fuente propio esté limpio, pero sus dependencias de terceros podrían no estarlo. Cuando un paquete original publique la procedencia SLSA, verifíquela. Y cuando no lo haga, evalúe si esa discrepancia representa un riesgo aceptable dado el rol del componente en su software.

Evitar estos escollos es lo que marca la diferencia entre un programa de trazabilidad que realmente reduce el riesgo y uno que solo existe sobre el papel.

Acertar con estos detalles de forma sistemática es donde la orientación especializada da sus frutos, especialmente a medida que la criptografía subyacente a la seguridad empieza a cambiar.

Cómo puede ayudar la consultoría de cifrado

CodeSign Secure es la plataforma de gestión de firmas de código de clase empresarial de Encryption Consulting, diseñada para proporcionar los controles de infraestructura que necesitan las industrias.

Gestión de claves respaldada por HSM

CodeSign Secure almacena todas las claves de firma privadas en módulos de seguridad de hardware (HSM) con certificación FIPS 140-2 Nivel 3, integrándose con Thales Luna, Entrust nCipher, Utimaco, Securosys y HSM en la nube de AWS y Azure. El aislamiento de claves por producto se aplica a nivel de partición del HSM: cada línea de productos recibe su propia clave dedicada, generada internamente en el hardware y que nunca se exporta.

Quórum de firmas de la M de N y RBAC

El modelo de control de acceso basado en roles (RBAC) de la plataforma aplica requisitos de aprobación multiusuario (M-of-N) para la firma del firmware de producción. Ningún individuo puede iniciar ni aprobar una operación de firma. Todas las solicitudes, aprobaciones y rechazos de firma quedan registrados. La configuración del RBAC es auditable y está controlada por versiones, lo que proporciona la política de firma documentada que exigen las evaluaciones de conformidad de la CRA.

Registro de auditoría inmutable

Cada evento de firma en CodeSign Secure genera una entrada de registro inmutable que captura el hash del artefacto, el identificador de la clave, el certificado utilizado, la identidad del aprobador y la marca de tiempo RFC 3161. Los registros se centralizan y se almacenan por separado de la infraestructura de firma.

Compatibilidad con formatos de firmware multiplataforma

CodeSign Secure admite la firma de artefactos de firmware en toda la gama de formatos que requiere una cartera de productos diversa: .bin, .img, .hex, .fw, .dfu y .efi, satisfaciendo el requisito de la CRA de controles consistentes en todas las líneas de productos sin reconstruir la infraestructura de firma para cada plataforma.

Soporte para criptografía postcuántica

CodeSign Secure v3.02 admite ML-DSA de nivel de producción (FIPS 204, con niveles de seguridad ML-DSA-44, ML-DSA-65 y ML-DSA-87) y SLH-DSA (FIPS 205) como firmas separables junto con algoritmos clásicos. Para los fabricantes que desarrollan productos con obligaciones de soporte CRA de más de cinco años , la firma PQC es actualmente la arquitectura que protege contra la amenaza HNDL antes de que llegue un CRQC.

Integración de canalización de CI/CD

CodeSign Secure se integra con Azure DevOps , Jenkins , GitLab CI y otras plataformas de canalización importantes mediante interfaces API y de línea de comandos. La firma del firmware es una etapa controlada y regulada dentro del proceso de compilación, no un paso manual.

Preguntas frecuentes

¿Una lista de materiales (SBOM) ya me proporciona información sobre la procedencia de la compilación?

No. Un SBOM enumera los componentes dentro de un artefacto; no dice nada sobre cómo se realizó la compilación ni si el proceso de compilación fue manipulado. SolarWinds SUNBURST es el ejemplo más claro: todos los componentes listados eran legítimos, pero la propia canalización de compilación se vio comprometida.

¿Cuál es la diferencia práctica entre el Nivel 1 y el Nivel 2 de SLSA?

¿Quién puede falsificar la procedencia? En el Nivel 1, cualquiera que pueda modificar el script de compilación también puede modificar el registro de procedencia. En el Nivel 2, la plataforma de compilación genera y firma la procedencia, al margen de los pasos de compilación controlados por el usuario, por lo que un script comprometido no puede falsificarla.

¿Existe un SLSA de nivel 4?

No está contemplado en la especificación v1.2 actual. En el borrador original de SLSA existe un cuarto nivel que abarca compilaciones herméticas y totalmente reproducibles con revisión por dos partes, y está previsto para una versión futura, pero el Nivel 3 es el nivel más alto definido en la especificación actual.

¿Qué ocurre si una dependencia de terceros no publica la procedencia SLSA?

Se trata de una deficiencia conocida, no algo que se pueda disimular. Evalúe el riesgo en función del papel que desempeña ese componente en su software, en lugar de asumir que equivale a una dependencia que puede verificar.

Conclusión

Los SBOM (Modelos de Materiales de Software) brindan a los equipos de seguridad visibilidad sobre los componentes de su software. La procedencia de la compilación y la firma de artefactos van un paso más allá. Proporcionan una prueba criptográfica de cómo se compiló el software y ayudan a confirmar que llega a producción sin modificaciones. El marco SLSA transforma esta idea en un proceso práctico y gradual. En lugar de exigir a los equipos que resuelvan todo a la vez, define niveles claros que pueden adoptarse de forma incremental.

El Nivel 1 requiere que se genere y se ponga a disposición la procedencia de la compilación, proporcionando a los equipos un registro de cómo se produjo cada artefacto. El Nivel 2 eleva el nivel al exigir que la propia plataforma de compilación genere y firme dicha procedencia. Esto impide que un script de compilación comprometido la falsifique y es factible en la mayoría de las plataformas de CI modernas. El Nivel 3 refuerza aún más el entorno de compilación para cargas de trabajo críticas y software de alta fiabilidad. Para muchas organizaciones, alcanzar el Nivel 2 de forma temprana proporciona una sólida base de seguridad, mientras que el Nivel 3 puede adoptarse gradualmente cuando se requiera una mayor fiabilidad. Las organizaciones que inicien este proceso ahora estarán bien posicionadas cuando la integridad verificable de la compilación se convierta en una expectativa básica.

Si desea comprender en qué situación se encuentra su organización actualmente en lo que respecta a la procedencia de los componentes, la firma de artefactos o la preparación para el control de calidad posterior a la fabricación (PQC) en su cadena de suministro, póngase en contacto con nosotros para iniciar la conversación.