Hemos contabilizado todos los formatos que CodeSign Secure puede firmar.

Pregúntale a un ingeniero de lanzamientos cuántas herramientas de firma utiliza su organización y verás cómo se detiene a contarlas con los dedos. Signtool para el instalador de Windows. Jarsigner para el servicio Java que nadie quiere tocar. Lo que sea que el equipo móvil haya configurado para los APK. Una clave GPG que alguien configuró para el repositorio de Debian hace tres ingenieros, y nadie está seguro de quién la conserva. Esto no es una hipótesis. Esa es la huella de firma promedio en cualquier empresa que haya distribuido software en más de una plataforma durante más de dos años, y es la razón por la que la firma de código sigue apareciendo en análisis post mortem de incidentes que no tienen nada que ver con el código en sí.

Aquí está la parte que hace que esto sea urgente ahora mismo, en lugar de algo que se pueda posponer: la propuesta CSC-31 del Foro CA/Browser redujo la validez máxima de los certificados de firma de código de confianza pública de 39 meses a 460 días, con vigencia a partir del 1 de marzo de 2026. Cada clave de firma dispersa que tenga una organización, cada token USB guardado en un cajón, cada certificado que nadie recuerda haber emitido, ahora necesita ser utilizado aproximadamente tres veces más a menudo que hace dieciocho meses. La firma fragmentada no era una buena idea antes de que se aprobara esa propuesta. Ahora es un riesgo operativo.

Por eso queremos responder a la pregunta que nos hacen casi todas las evaluaciones de CodeSign Secure para una solución de firma de código empresarial: «Vale, pero ¿cubre realmente nuestra infraestructura tecnológica?». A continuación, encontrarás una respuesta honesta y específica, formato por formato, con suficientes detalles técnicos para que puedas comprobarla con tu propio proceso de lanzamiento en lugar de fiarte solo de nuestra palabra.

Solución de firma de código empresarial, definida como: una plataforma centralizada que genera y almacena claves de firma privadas dentro de hardware respaldado por HSM, impone una aprobación múltiple basada en roles para cada solicitud de firma y produce firmas válidas en todos los formatos que distribuye la organización, en lugar de dejar que cada equipo firme con sus propias claves y herramientas locales.

Puntos Clave

• CodeSign Secure firma más de 20 formatos, Windows, Apple, Java/Android, Linux, nativos de la nube, encapsulados en PKCS#11 y post-cuánticos, desde una plataforma respaldada por HSM de nivel 3 FIPS 140-2.
• Un único modelo RBAC y un único flujo de trabajo de aprobación M de N rigen todas las solicitudes de firma, independientemente del formato.
• La propuesta CSC-31 del Foro CA/Browser redujo la validez de los certificados públicos de firma de código de 39 meses a 460 días, con vigencia a partir del 1 de marzo de 2026, triplicando la frecuencia con la que es necesario volver a emitir las claves de firma dispersas.
• CodeSign Secure admite firmas post-cuánticas separables (ML-DSA, LMS) junto con la firma clásica RSA/ECDSA en el mismo artefacto, por lo que la adopción de PQC es aditiva, no una migración de reemplazo total.
• Las opciones de implementación incluyen modelos HSM locales, en la nube e híbridos; consulte las secciones de Requisitos previos y Limitaciones conocidas más adelante antes de realizar la evaluación.

La versión corta

CodeSign Secure firma más de 20 formatos distintos desde una plataforma respaldada por HSM: binarios y scripts de Windows (Signtool, JSign, PowerShell, Appx/MSIX, ClickOnce a través de Mage, NuGet, firma de controladores HLK/HCK), binarios de Apple, artefactos de Java y Android (jarsigner, JSign, APK), paquetes de Linux y de código abierto (OpenSSL, XML, GPG2, Debian, RPM), artefactos nativos de la nube (contenedores, OVA/OVF, firmware), compilaciones reproducibles, firma HSM encapsulada en PKCS#11 y firmas post-cuánticas separables (ML-DSA, LMS). Un modelo de control de acceso basado en roles (RBAC) y un flujo de trabajo de aprobación M-of-N rigen todo. Ese último punto es el verdadero problema, no la cantidad de formatos. Una plataforma que firma veinte formatos a través de veinte límites de confianza diferentes no ha resuelto el problema de la fragmentación; simplemente le ha dado una lista de características más larga.

¿Quieres ver el mapa completo antes de los detalles? Aquí lo tienes.

Categoría	Formatos/Herramientas cubiertas	Extensiones de archivo
Windows	Signtool (Authenticode), JSign, scripts de PowerShell, paquetes Appx/MSIX, manifiestos ClickOnce (Mage/Mage UI), paquetes NuGet, controladores HLK/certificados por HCK	.exe, .dll, .sys, .msi, .cab, .ps1, .appx/.msix, .application, .nupkg
Apple	Aplicaciones para macOS, iOS y watchOS	.app, .ipa
Java y Android	Archivos JAR (jarsigner), Authenticode multiplataforma mediante JSign, paquetes APK	.jar, .apk
Linux y código abierto	Firma basada en OpenSSL, firmas digitales XML, GPG2, paquetes Debian, paquetes RPM	.rpm, .deb, .xml, .asc/.sig
Infraestructura y tecnologías nativas de la nube	Imágenes de contenedores/OCI, archivos de virtualización OVA/OVF, imágenes de firmware	N/A (resumen de contenido), .ova/.ovf, binarios de firmware
Integridad de la cadena de suministro	Construcciones reproducibles	N/A (certificación de compilación, no un solo tipo de archivo)
Post-cuántico	Firmas separables PQC (ML-DSA, LMS)	.sig (desconectado)
Interoperabilidad de hardware	Firma de envoltura PKCS#11 para herramientas de terceros y heredadas	No aplica (a nivel de protocolo, no específico del archivo)

Ahora vamos a analizar qué hay realmente detrás de cada fila, porque "apoyamos X" no significa nada sin el "por qué es importante" que se le añade.

Windows: donde nacen la mayoría de los programas de firma digital y donde la mayoría de ellos se estancan.

Si su organización firma algo, casi con seguridad comenzó con Windows, y suele ser también donde comienza la proliferación de firmas. Signtool.exe de Microsoft es la herramienta de referencia para la firma Authenticode, el esquema que Windows utiliza para confiar en los archivos PE: .exe, .dll, .sys, .msi, .cab y archivos de catálogo. El problema es que Signtool solo se ejecuta en Windows, y en el momento en que su canalización de compilación incluye un contenedor Linux o un conjunto mixto de CI/CD, esto deja de ser una pequeña molestia y se convierte en la razón por la que alguien mantiene una máquina virtual Windows activa solo para firmar archivos. JSign, una herramienta Authenticode multiplataforma de código abierto escrita en Java, existe específicamente para solucionar este problema, y ​​CodeSign Secure la utiliza como uno de sus motores de firma para que los agentes de compilación de Linux y macOS puedan producir firmas Authenticode válidas sin necesidad de iniciar esa máquina virtual. La clave privada permanece en un HSM FIPS 140-2 Nivel 3 en todo momento, ya sea que la solicitud provenga de Signtool o de JSign.

Los scripts de PowerShell reciben el mismo tratamiento. Si su política de ejecución requiere una firma Authenticode válida en cada archivo .ps1 (y debería ser así), CodeSign Secure firma esos scripts a través del HSM y los deja verificables con una simple llamada a Get-AuthenticodeSignature, sin que la clave de firma llegue a la máquina que ejecuta el script.

Luego está la capa de empaquetado, que es donde la mayoría de las configuraciones de firma de Windows se fragmentan silenciosamente en tres o cuatro flujos de trabajo separados: paquetes Appx y MSIX, que Windows no instalará sin una cadena de certificados a una raíz de confianza, ya sea que se distribuya a través de la Tienda o se cargue de forma lateral; ClickOnce, el modelo de implementación autoactualizable de .NET cuya confianza se basa en manifiestos firmados generados a través de las herramientas Mage y Mage UI de Microsoft (y cuyas claves de firma tienen la mala costumbre de terminar en el almacén de certificados local de un desarrollador en lugar de en algún lugar donde un equipo de seguridad pueda verlas); y paquetes NuGet, que han admitido la firma basada en Authenticode desde NuGet 4.6 y realmente deberían llevar una marca de tiempo de confianza para que la firma sobreviva al certificado. CodeSign Secure maneja los tres de la misma manera que maneja el binario en sí: un HSM, un registro de auditoría, sin excepciones para "es solo un manifiesto".

Y luego está el formato que aterroriza silenciosamente a los proveedores de hardware: la firma de controladores HLK/HCK. Obtener la certificación de un controlador mediante el Windows Hardware Lab Kit (el sucesor del antiguo Hardware Certification Kit) implica enviar paquetes firmados al Centro de desarrollo de hardware de Windows de Microsoft, y los controladores en modo kernel en Windows de 64 bits simplemente no se cargarán sin una firma de un certificado que cumpla con los requisitos actuales de clave EV o respaldada por hardware de Microsoft. Un envío HLK rechazado por un tecnicismo de firma le cuesta tiempo real al equipo de hardware. CodeSign Secure admite la firma conforme a esos requisitos directamente, lo que marca la diferencia entre un envío que supera la revisión y uno que rebota con una nota que nadie quiere leer.

Apple: Un ecosistema, un reglamento más estricto

Apple es más estricta que Windows en este aspecto. Codesign y Gatekeeper exigen que cada binario de macOS, iOS y watchOS incluya una firma de un certificado de desarrollador de Apple, y macOS añade una segunda comprobación mediante la certificación notarial antes de que Gatekeeper permita al usuario abrir la aplicación sin mostrar un cuadro de diálogo de advertencia. El fallo más común no reside en la falta de una firma, sino en que el ID de desarrollador de Apple se encuentre en el llavero de un ingeniero en lugar de en un lugar donde el equipo pueda rotarlo o revocarlo. CodeSign Secure firma las aplicaciones de macOS, iOS y watchOS mediante el flujo estándar de Apple, manteniendo esos certificados en la misma bóveda protegida por HSM que las claves de otras plataformas, de modo que la persona que posee el certificado de firma de Apple deja de ser un único punto de fallo vinculado a un solo ordenador portátil.

Java y Android: La pila tecnológica que todo el mundo da por sentada que firma otra persona

Cada empresa tiene al menos un servicio Java interno que ha estado funcionando silenciosamente desde una JVM que el equipo actual apenas recuerda. jarsigner, incluido en el JDK, firma los archivos JAR de los que dependen esos servicios para que una JVM (o un usuario) pueda confirmar que el archivo no ha sido manipulado y, cuando el manifiesto lo incluye, quién lo publicó realmente. CodeSign Secure firma los archivos JAR a través de su flujo centralizado habitual, lo cual es importante principalmente porque las claves de firma de JAR son precisamente el tipo de credencial que se configura una vez, se olvida y nunca se rota. JSign también aparece aquí, permitiendo que los ejecutores de CI/CD basados ​​en Linux y macOS soliciten firmas en formato Windows sin un host de firma de Windows dedicado solo para esa etapa del pipeline.

Android es un caso aparte. Cada APK debe firmarse antes de la instalación, y el esquema ha evolucionado cuatro veces: v1 (heredado directamente de la firma JAR de Java), v2 y v3 (esquemas de firma de archivo completo que Android introdujo en las versiones 7.0 y 9 específicamente para cerrar las brechas que dejó v1, vinculando la firma al contenido exacto del APK en lugar de solo al manifiesto), y v4 (un esquema de transmisión utilizado junto con v2/v3 para actualizaciones incrementales de aplicaciones). CodeSign Secure firma en todos estos esquemas a través de APKSigner, enrutado a través de su envoltorio PKCS#11 en los agentes de compilación de Linux, Windows y macOS, por igual, de modo que una versión móvil cumple con los requisitos actuales de Google Play sin una herramienta de firma móvil separada y no administrada que exista fuera de todo lo demás.

Linux y el código abierto: el ecosistema con más convenciones de firma, no el que menos.

Si alguien te dice que la firma en Linux es "solo GPG", es que no ha lidiado con RPM, Debian y la firma a nivel de repositorio como tres convenciones genuinamente diferentes. Las distribuciones basadas en RPM firman con rpm –addsign (o rpmsign), incrustando una clave GPG directamente en la cabecera del paquete. Los paquetes basados ​​en Debian se firman mediante herramientas como dpkg-sig o durante la compilación a través de debsign. Y los metadatos del repositorio APT, el propio archivo Release, se firman por separado para que un gestor de paquetes pueda confiar en todo un repositorio en lugar de verificar los paquetes uno por uno. Tres convenciones suelen significar tres llaveros GPG dispersos por la infraestructura de compilación, cada uno con su propia idea de quién está autorizado a usarlo. CodeSign Secure centraliza las tres bajo una única capa de gestión de claves.

Dos formatos más cercanos a Linux completan esta lista. La firma OpenSSL cubre los casos que las herramientas de empaquetado no cubren: hashes sin procesar, estructuras de datos personalizadas, archivos arbitrarios que necesitan una firma separada y no se ajustan a un formato de paquete estándar. CodeSign Secure admite la firma basada en OpenSSL (dgst -sign y flujos de trabajo CMS) para que esos artefactos no dependan de "quien tenga un archivo de clave local a mano". Y las firmas digitales XML, el formato XML-DSig estandarizado por el W3C que subyace a las aserciones SAML, los mensajes SOAP y una buena cantidad de intercambio de documentos regulados, se firman con esa misma especificación cuando un requisito de cumplimiento o integración B2B lo exige específicamente.

Infraestructura y tecnologías nativas de la nube: donde las estrategias de firma son más recientes y tienen más probabilidades de ser omitidas.

Esta es la categoría para la que la mayoría de las herramientas de firma heredadas nunca fueron diseñadas, y se nota.

La firma de imágenes de contenedor adjunta una firma criptográfica a una imagen para que cualquiera que la descargue pueda verificar quién la publicó y confirmar que no ha sido alterada. El ecosistema ha convergido principalmente en dos enfoques: Cosign de Sigstore, que admite claves autogestionadas (incluidas las respaldadas por HSM) o firma sin clave mediante certificados de corta duración y un registro de transparencia público, y Notation, basado en la especificación CNCF Notary v2, que utiliza políticas de confianza basadas en PKI y es lo que Microsoft AKS y Amazon EKS recomiendan para Kubernetes empresarial. Ambos vinculan la firma al resumen de contenido de la imagen en lugar de a una etiqueta mutable, que es la razón principal por la que se puede detectar cualquier manipulación. CodeSign Secure firma según estos estándares actuales, no según el modelo Docker Content Trust que Docker ya ha descontinuado para las imágenes oficiales.

La firma de archivos OVA y OVF cumple la misma función para los dispositivos de máquinas virtuales, los formatos de empaquetado estándar de VMware y la especificación de virtualización abierta del Distributed Management Task Force, de modo que un equipo puede verificar la integridad de un dispositivo de máquina virtual antes de que se acerque a la producción.

La firma del firmware es más importante que cualquier otra cosa, ya que el firmware se encuentra por debajo del sistema operativo. Una imagen de firmware comprometida sobrevive a una reinstalación del sistema operativo y elude la mayoría de las herramientas de seguridad de endpoints. El firmware firmado, verificado mediante una cadena de arranque seguro, es el control que impide que se cargue una imagen modificada, y es precisamente el tipo de clave de larga duración y alto alcance que nunca debería estar en un script de compilación ni en una herramienta local del proveedor. CodeSign Secure firma el firmware a través del mismo HSM que el resto de los elementos de esta lista, sin excepciones.

Compilaciones reproducibles: demostrando que el binario coincide realmente con el código fuente.

Una compilación reproducible significa que compilar el mismo código fuente con las mismas instrucciones produce exactamente el mismo binario, bit a bit, sin importar quién lo compile ni cuándo. Esta propiedad permite que alguien ajeno a su organización compile de forma independiente una versión y confirme que lo que usted distribuyó coincide con lo que publicó, lo que constituye una de las defensas más sólidas contra un proceso de compilación comprometido que existen actualmente. CodeSign Secure admite flujos de trabajo de firma basados ​​en prácticas de compilación reproducibles, de modo que la firma en un artefacto de lanzamiento está vinculada a un proceso de compilación que se puede verificar, y no solo confiar en él porque el proveedor lo haya dicho. Para obtener más información sobre cómo esto se relaciona con la certificación de la cadena de suministro en general, consulte Fortalecimiento de la seguridad de la cadena de suministro con SLSA Nivel 3 y firma de código.

Fichaje posterior a la era cuántica: El que la mayoría de los equipos aún no están considerando.

He aquí un hecho incómodo: cada firma RSA y ECDSA que respalda la firma de código actual es precisamente el tipo de cosa que una computadora cuántica suficientemente potente rompería. El NIST no dejó esto en teoría. FIPS 204 (ML-DSA, el estándar de firma digital basado en retículos de módulos) y FIPS 205 (SLH-DSA, el estándar de firma digital basado en hash sin estado) se finalizaron en agosto de 2024, junto con los esquemas LMS y XMSS basados ​​en hash con estado especificados en NIST SP 800-208. CodeSign Secure admite la firma separable PQC mediante ML-DSA y LMS, lo que significa que una firma post-cuántica puede coexistir con, o en lugar de, una firma RSA/ECDSA clásica en el mismo artefacto. Nadie tiene que eliminar su esquema de firma existente para comenzar. Ese es todo el valor de "separable": agilidad criptográfica que puede comenzar a incorporar en un flujo de trabajo hoy mismo en lugar de durante una crisis posterior. Aquí es donde esto se relaciona con una pregunta más importante que la mayoría de los equipos aún no han respondido: simplemente saber qué algoritmos de firma se utilizan realmente en su entorno. Esto pertenece más al ámbito de CBOM Secure que al de la firma de código, pero ambos parten del mismo inventario.

PKCS#11: Asegurarse de que las herramientas heredadas no se conviertan en una excusa

Una gran cantidad de herramientas de firma existentes, especialmente las más antiguas, se desarrollaron directamente sobre PKCS#11, la API criptográfica estándar que exponen la mayoría de los HSM y tokens inteligentes. En lugar de que alguien tenga que reemplazar cada una de esas herramientas, CodeSign Secure se presenta como un proveedor de PKCS#11, por lo que los scripts existentes y las herramientas de terceros que requieren acceso directo al hardware siguen funcionando tal como se concibieron. La diferencia radica en lo que sucede tras esa interfaz: cada operación de firma se enruta a través de la capa centralizada de políticas, registro y aprobación de CodeSign Secure, en lugar de comunicarse directamente con el hardware sin supervisión.

En la práctica, el envoltorio PKCS#11 es sobre el que se basan los motores de firma de CodeSign Secure, y funciona en todas las principales plataformas de compilación:

• Firma de APK: Linux, Windows y macOS
• Firma basada en OpenSSL: Linux y Windows
• Firmas digitales XML — Linux y macOS
• Firma basada en JSign: Linux, Windows y macOS
• Firma de archivos JAR con Jarsigner — Linux, Windows y macOS
• Firma de paquetes GPG2, Debian y RPM — Linux

Cómo está diseñado CodeSign Secure

Si eliminamos los detalles específicos de cada formato mencionados anteriormente, la arquitectura es la misma para todos ellos: una raíz de confianza de hardware, un conjunto de motores de firma que utilizan las herramientas nativas de cada formato y una capa de políticas que cada solicitud debe superar antes de que se realice una operación clave.

• Raíz de confianza del hardware: Las claves privadas se generan y almacenan en un HSM (Módulo de Seguridad de Hardware) con certificación FIPS 140-2 de nivel 3, implementado localmente, en la nube o como una combinación de ambos, de modo que el material de la clave nunca abandona el hardware validado, independientemente del formato.
• Motores de firma específicos para cada formato: Signtool y JSign para Authenticode, jarsigner y APKSigner para Java/Android, cosign para Apple y firma alineada con Cosign/Notation para contenedores, cada uno de los cuales se comunica con el HSM en lugar de mantener una copia local de la clave.
• Capa de interoperabilidad PKCS#11: Una interfaz de proveedor PKCS#11 permite que los scripts existentes y las herramientas de terceros que esperan acceso directo al hardware sigan funcionando sin modificaciones, mientras que cada llamada se enruta a través de la capa de políticas inferior.
• Capa centralizada de políticas y aprobación: Los flujos de trabajo de aprobación múltiple RBAC y M-of-N se sitúan delante de cada motor de firma, por lo que una credencial de compilación comprometida no puede producir una firma de confianza por sí sola.
• Puntos de integración: Los complementos de canalización de CI/CD, una API/CLI y la interfaz PKCS#11 descritas anteriormente cubren las formas en que los sistemas de compilación suelen solicitar una firma; confirme las plataformas de CI/CD y las versiones de sistema operativo compatibles con su entorno consultando la documentación de implementación actual de CodeSign Secure antes de finalizar la arquitectura.

Controles de seguridad detrás de cada firma

La lista de formatos importa menos que lo que sucede debajo de ella. Cada evento de firma, sin importar cuál de los más de 20 formatos anteriores lo active, pasa por el mismo conjunto de controles:

• Custodia de llaves: Las claves privadas se generan y permanecen dentro de un HSM (Mando de Seguridad de Hardware) con certificación FIPS 140-2 de nivel 3; el motor de firma de ningún formato obtiene una copia local de la clave.
• Control de acceso basado en roles: Quién puede solicitar una firma, en qué formato y bajo qué certificado, se define por rol, no por credencial individual.
• Aprobación M-of-N: Las operaciones de firma de mayor riesgo (el envío de un nuevo controlador HLK, una imagen de firmware, un contenedor de producción) pueden requerir la aprobación de un quórum definido de aprobadores en lugar de la simple autorización de un único desarrollador.
• Registro de auditoría centralizado e inmutable: Cada evento de firma en todos los formatos se registra en un único archivo de registro, un control del que carecen por completo las configuraciones de firma más fragmentadas, en lugar de un registro por herramienta (o ningún registro en absoluto).

Lo que necesitas antes de implementar una solución de firma de código empresarial.

Nada de lo anterior funciona sin que se cumplan algunos requisitos previos. Antes de evaluar o implementar una plataforma de firma centralizada, confirme que cuenta con lo siguiente:

• Un HSM que cumpla con el nivel 3 de FIPS 140-2 (en las instalaciones, en la nube o mediante HSM como servicio si aún no dispone de uno).
• Cree agentes o ejecutores de CI/CD para cada plataforma para la que firme (Windows, Linux, macOS) que puedan acceder a la API, al complemento de CI/CD o a la interfaz PKCS#11 de la plataforma de firma.
• Certificados emitidos por una CA apropiada para cada caso de uso: una CA de confianza pública para la firma de Authenticode y Apple Developer y, cuando la política lo permita, una CA interna para la firma interna de Java, XML o repositorios de paquetes.
• Una fuente de identidad (directorio existente o proveedor de identidad) para asignar los aprobadores designados al flujo de trabajo de aprobación RBAC y M-of-N.
• En lo que respecta específicamente a la firma de contenedores, se requiere un registro que admita la vinculación de firmas OCI, de modo que las firmas de estilo Cosign o Notation se enlacen al resumen de la imagen.

Las versiones exactas de sistemas operativos compatibles, las plataformas CI/CD y los requisitos de red varían según el modelo de implementación; confirme la lista actual con la documentación de implementación de CodeSign Secure o con su contacto de evaluación, en lugar de basarse únicamente en esta publicación.

Limitaciones conocidas

Una lista de cobertura honesta incluye lo que la centralización de la firma no hace, no solo lo que sí hace:

• Centralizar la clave no elimina la necesidad de utilizar herramientas nativas de la plataforma para preparar el artefacto previamente. El conjunto de herramientas de Xcode para la certificación de Apple, las herramientas de empaquetado del Windows Hardware Lab Kit para la certificación de controladores y herramientas similares siguen ejecutándose en el agente de compilación; CodeSign Secure proporciona la operación de clave de confianza, no el paso de empaquetado.
• Una implementación local aún requiere que la organización proporcione o conecte un HSM compatible con FIPS 140-2 Nivel 3 (o lo consuma como HSM como servicio); CodeSign Secure es una capa de firma y políticas, no un reemplazo para el HSM en sí.
• El envoltorio PKCS#11 está documentado más arriba para seis flujos de trabajo específicos (APK, OpenSSL, XML, JSign, jarsigner y firma GPG2/Debian/RPM); si utiliza una herramienta heredada que no esté en esa lista, debe confirmarlo directamente con el equipo de CodeSign Secure antes de dar por sentada su compatibilidad.
• La firma PQC separable añade una segunda firma junto con la clásica; no elimina ni reemplaza la firma RSA/ECDSA que sus clientes actuales siguen verificando hoy en día, por lo que debe tratarse como una mejora adicional en la criptografía, no como una migración completa.

Esta es la parte que realmente te diríamos por teléfono.

La cantidad de formatos que admite una plataforma de firma no es lo importante. Lo repetimos en casi todas las conversaciones de evaluación, y sorprende a quienes tienen menos experiencia en el sector de lo que uno pensaría. Lo realmente importante es cuántas claves de firma de una organización se encuentran actualmente fuera de un plano de control único respaldado por un HSM, cada una con su propia lista de acceso, su propio registro de auditoría (o la ausencia total del mismo) y su propio calendario de renovación que nadie gestiona de forma centralizada.

Ignorar esa cifra ahora resulta mucho más costoso. Con el nuevo plazo máximo de validez de 460 días, cada una de esas claves dispersas necesita ser reemitida y redistribuida aproximadamente tres veces más a menudo que antes de marzo de 2026. Un flujo de trabajo de firma manual por herramienta, que hace dieciocho meses solo resultaba molesto, ahora consume tiempo real de ingeniería cada trimestre, y es aún peor para quienes todavía envían tokens USB físicos para su firma en lugar de utilizar un HSM en red o en la nube.

Por lo tanto, la solución no consiste en elegir la herramienta con la lista de funciones más extensa en su sitio web. Consiste en asegurarse de que cada formato de firma que utilice una organización esté respaldado por un único HSM, un único modelo RBAC y un único flujo de trabajo de aprobación M-of-N, de modo que un servidor de compilación comprometido o una cuenta de desarrollador robada mediante phishing no puedan generar una firma de confianza, independientemente del formato (más de veinte) que intenten utilizar.

Lista de verificación para la evaluación de una solución de firma de código empresarial

Utilice estas preguntas, en orden, al comparar una plataforma de firma centralizada con su propia lista de formatos y herramientas:

1. ¿Cada formato que distribuyes pasa por una raíz de confianza respaldada por HSM, o el recuento de formatos oculta un almacén de claves independiente para cada herramienta?
2. ¿Se aplica la aprobación RBAC y M-of-N a todos los formatos, o solo a los pocos sistemas informáticos configurados inicialmente?
3. ¿Es posible obtener un registro de auditoría para un evento de firma específico bajo demanda, en cualquier formato, sin tener que consultar los registros de una segunda o tercera herramienta?
4. ¿La plataforma admite actualmente la firma post-cuántica separable, o todavía está "en la hoja de ruta"?
5. ¿El modelo de implementación (local, en la nube o híbrido) se ajusta a sus requisitos de propiedad de HSM y residencia de datos?
6. Para cualquier herramienta en la que confíen sus equipos y que requiera acceso directo al hardware PKCS#11, ¿el proveedor publica exactamente qué flujos de trabajo son compatibles actualmente, en lugar de una afirmación genérica de "compatibilidad con PKCS#11"?

Validación independiente

No tome la lista de formatos de esta página como la única evidencia. Compárela con fuentes externas a Encryption Consulting:

• ABI Research incluyó a CodeSign Secure entre los líderes del mercado de firma de código en su evaluación de mercado independiente; ver ABI Research nombra a CodeSign Secure entre los líderes del mercado de firma de código..
• El cambio en la validez de los certificados que justifica la urgencia de esta publicación está documentado directamente por el organismo de normalización: Boletín del Foro CA/Browser CSC-31: Reducción de la validez máxima.
• Los estándares de firma post-cuántica a los que se hace referencia anteriormente, FIPS 204 (ML-DSA) y FIPS 205 (SLH-DSA), son publicados directamente por el NIST, no son resúmenes de segunda mano.
• La postura de seguridad de Encryption Consulting (ISO/IEC 27001:2022, SOC 2, PCI DSS) está documentada en el Centro de confianza, independientemente de las afirmaciones de cualquier producto en particular.

Si has llegado hasta aquí

Contar con más de veinte formatos no es una métrica vanidosa; es simplemente un reflejo honesto de las diversas formas en que una organización de software moderna distribuye sus productos: código, scripts, paquetes, contenedores, firmware y, ahora, firmas post-cuánticas, a menudo dentro del mismo proceso de lanzamiento. Los equipos perjudicados no son los que carecen de una herramienta de firma, sino los que utilizan seis, cada una con una clave oculta en algún lugar sin supervisión, justo cuando la vigencia de los certificados se ha reducido a la tercera parte.

Si su propia infraestructura de firma ya abarca más de dos o tres de los formatos mencionados anteriormente, ese suele ser el punto en el que consolidarse en una plataforma respaldada por HSM deja de ser un proyecto para algún día y comienza a ser lo que se interpone entre un lanzamiento rutinario y una semana muy mala.

Descubre cómo CodeSign Secure centraliza todos estos flujos de trabajo: explora la plataforma CodeSign Secure.

Preguntas frecuentes

¿CodeSign Secure requiere un HSM diferente para cada formato de firma?

No. Todos los formatos compatibles con CodeSign Secure, desde Authenticode hasta imágenes de contenedores y firmas PQC desmontables, se ejecutan a través de la misma infraestructura HSM centralizada, implementada localmente, en la nube o como un sistema híbrido, de modo que una organización gestiona una única raíz de confianza de hardware en lugar de una por cada herramienta.

¿Puede CodeSign Secure firmar tanto firmas clásicas (RSA/ECDSA) como post-cuánticas en el mismo artefacto?

Sí. CodeSign Secure admite firmas PQC separables mediante ML-DSA y LMS junto con la firma clásica, por lo que se puede agregar una firma post-cuántica a una versión sin eliminar la firma clásica de la que aún dependen los clientes para la verificación.

¿Por qué la firma de controladores HLK/HCK requiere un flujo de trabajo específico en lugar de la firma Authenticode estándar?

Las pruebas enviadas al Windows Hardware Lab Kit conllevan sus propios requisitos de certificado y envío vinculados al Centro de desarrollo de hardware de Windows de Microsoft, y los controladores en modo kernel en Windows de 64 bits no se cargarán sin una firma que cumpla con esos requisitos específicos, por lo que el flujo de trabajo de firma debe coincidir con el proceso de certificación de controladores de Microsoft en lugar de las reglas genéricas de Authenticode.

¿Sigue siendo Docker Content Trust un método compatible para firmar contenedores?

Docker ha dejado de usar Content Trust para las imágenes oficiales, y la práctica actual se ha desplazado a Sigstore Cosign o Notation (Notary v2), que vinculan las firmas al resumen de contenido de una imagen. CodeSign Secure firma según estos estándares actuales en lugar del modelo obsoleto.

¿Qué cambios se produjeron en la validez de los certificados de firma de código en 2026?

Según la propuesta CSC-31 del Foro CA/Browser, la validez máxima de los certificados de firma de código de confianza pública se redujo de 39 meses a 460 días, a partir del 1 de marzo de 2026, lo que aumenta significativamente la frecuencia con la que es necesario volver a emitir certificados, especialmente para las organizaciones que aún dependen de tokens de hardware físicos en lugar de la firma centralizada mediante HSM.

¿Qué necesito antes de implementar una solución de firma de código empresarial como CodeSign Secure?

Como mínimo, se requiere un HSM FIPS 140-2 de nivel 3 (en las instalaciones, en la nube o como servicio), agentes de compilación o ejecutores de CI/CD para cada plataforma que se utilice, certificados emitidos adecuadamente para cada caso de uso y una fuente de identidad para asignar los aprobadores al flujo de trabajo RBAC y M-of-N. Las versiones exactas de los sistemas operativos compatibles y las integraciones de CI/CD deben confirmarse con la documentación de implementación vigente.

¿La centralización de la firma de código elimina la necesidad de herramientas de firma específicas para cada plataforma?

No. Herramientas como el conjunto de herramientas de Xcode para la certificación de Apple o las herramientas de empaquetado del Windows Hardware Lab Kit para la certificación de controladores siguen ejecutándose en el agente de compilación para preparar el artefacto. CodeSign Secure modifica la ubicación de la clave privada y la forma en que se autoriza la solicitud de firma, no el paso de empaquetado nativo de la plataforma en sí.