Introducción a la firma de código: Cómo proteger su cadena de suministro de software

Cada vez que descargas una actualización de software, instalas una extensión de navegador o ejecutas una aplicación empresarial, depositas un profundo nivel de confianza en ese software. Pero, ¿cómo puedes estar seguro de que no ha sido manipulado, de que proviene del proveedor que dice ser y no de un atacante? La respuesta es firma de código. 

Como líderes en seguridad, las organizaciones han dedicado años a fortalecer la seguridad de las aplicaciones, los controles en la nube y la gestión de identidades. Sin embargo, uno de los pilares de confianza más olvidados en el ciclo de vida del software sigue siendo la firma de código. Muchos aún se enfrentan al mismo problema: invierten considerablemente en un desarrollo seguro, pero dejan el proceso de lanzamiento final fragmentado, manual y difícil de gestionar.  

La creciente prevalencia de ciberataques dirigidos a vulnerabilidades de software exige mecanismos robustos para garantizar la autenticidad y seguridad del código de software. Al implementar la firma de código, los desarrolladores pueden establecer confianza con los usuarios, asegurándoles que el software que instalan es legítimo y está libre de malware. Y a medida que la industria madura, surgen prácticas emergentes, como la firma sin clave (donde los certificados de corta duración reemplazan las claves privadas de larga duración, eliminando por completo la necesidad de la gestión de claves) y Lista de materiales de software (SBOM) La integración (que proporciona un inventario legible por máquina de cada componente de un artefacto de software) está transformando la concepción de una estrategia de firma integral. Para comprender su función crucial, es fundamental examinar los complejos procesos involucrados, incluidos los relacionados con la transparencia, la validez y la seguridad. 

¿Qué es la firma de código y por qué es importante? 

En esencia, la firma de código es el proceso de aplicar una firma digital al software, ya sea un ejecutable, un script, un controlador, una imagen de firmware o un contenedor. Esta firma cumple dos propósitos esenciales: 

1. Autenticación — Demuestra quién creó o publicó el software. 
2. Integridad — Garantiza que el código no ha sido alterado desde que fue firmado. 

En 2025, según el mismo informe CleanStart, el 35% de los ataques a la cadena de suministro se originaron a través de dependencias de software comprometidas, el 22% se dirigieron a las canalizaciones de CI/CD y los entornos de compilación, y el 20% involucraron imágenes de contenedores envenenadas o no verificadas. También descubrieron que ataques a la cadena de suministro de software A nivel mundial, las cifras se duplicaron con creces durante 2025, alcanzando pérdidas globales de 60 mil millones de dólares y con más del 70 % de las organizaciones reportando al menos un incidente de seguridad relacionado con la cadena de suministro ese año. Lo que hace que estas cifras sean particularmente alarmantes es que los atacantes ya no se dirigen al perímetro, sino que ingresan a través del propio proceso de fabricación.  

Al firmar código, es importante saber que la firma solo es válida mientras el certificado de firma esté vigente. Sin embargo, el software suele tener una vida útil mayor que la del certificado. Una marca de tiempo confiable, emitida por una Autoridad de Marcas de Tiempo (TSA) compatible con RFC 3161 en el momento de la firma, vincula criptográficamente la firma a un punto específico en el tiempo. Esto significa que, incluso después de que expire el certificado de firma, la firma sigue siendo válida, ya que la marca de tiempo demuestra que la firma se realizó mientras el certificado aún estaba activo. Sin marcas de tiempo, toda la versión firmada podría dejar de ser confiable en el momento en que expire el certificado. 

Otro concepto importante a comprender es que, si una clave de firma se ve comprometida, el certificado correspondiente debe revocarse de inmediato. Las Listas de Revocación de Certificados (CRL, por sus siglas en inglés) son listas de certificados revocados que se publican periódicamente. Protocolo de estado del certificado en línea (OCSP) Proporciona comprobaciones de revocación en tiempo real para cada certificado. Los sistemas operativos y las herramientas de seguridad consultan estos mecanismos para verificar que un certificado no haya sido revocado antes de confiar en una firma. Un programa de firma de código robusto debe incluir un plan de revocación probado, que no solo permita revocar, sino que también incluya un proceso documentado para revocar, volver a firmar y redistribuir rápidamente los elementos afectados. 

La aplicación de las políticas de la plataforma añade una capa adicional de validación de confianza. En Windows, SmartScreen evalúa la reputación de los ejecutables firmados: el software con firma EV y reputación establecida evita la advertencia de "Editor desconocido", que puede disuadir a los usuarios y erosionar la confianza. En macOS, Gatekeeper comprueba que las aplicaciones estén firmadas con un certificado de ID de desarrollador emitido por Apple y que hayan superado la certificación notarial, el análisis automatizado de malware de Apple. En Linux, los gestores de paquetes como apt y dnf verifican las firmas GPG de los paquetes antes de la instalación. Comprender estos controles a nivel de plataforma ayuda a los equipos de seguridad a diseñar flujos de trabajo de firma que resulten en una entrega de software segura y sin fricciones. 

Sin la firma de código, los usuarios y los sistemas carecen de una forma fiable de distinguir el software legítimo de una imitación maliciosa. Sin embargo, también es importante comprender que la firma de código no garantiza que el software sea seguro, inocuo o esté libre de vulnerabilidades. Una firma válida prueba la integridad y el origen, no la calidad ni la intención. Si una clave de firma se ve comprometida, o si un editor legítimo firma código defectuoso, la firma aún podría validarse correctamente. Para quienes toman las decisiones, esta distinción es fundamental: la firma de código es un control necesario, pero debe funcionar junto con el desarrollo seguro, el endurecimiento de los procesos, el control de acceso y la monitorización. 

A principios de 2025, se descubrió que ciberdelincuentes abusaban del servicio Trusted Signing de Microsoft para firmar malware con certificados de corta duración (tres días), lo que hacía que las cargas maliciosas parecieran totalmente fiables y eludieran los controles de seguridad tradicionales. Los certificados eran técnicamente válidos y se verificaron correctamente; el problema no era la infraestructura, sino que los atacantes habían accedido a ella. Esto ilustra con precisión la principal limitación de la firma de código: una firma válida demuestra que alguien con acceso a la firma produjo el software, no que el software sea seguro. La infraestructura de firma debe reforzarse, el acceso debe controlarse estrictamente y la actividad de firma anómala debe detectarse prácticamente en tiempo real, porque cuando el proceso de firma se ve comprometido, la firma se convierte en el arma más poderosa del atacante. 

La Fundación Criptográfica 

Para comprender verdaderamente la firma de código, necesita un conocimiento básico de Infraestructura de clave pública (PKI) y criptografía asimétrica. 

Pares de claves asimétricas 

Cada identidad de firma de código se basa en un par de claves: 

• A llave privada — mantenido en secreto por el editor del software. Esto se utiliza para Para crear la firma. 
• A Llave pública — compartido abiertamente. Esto se utiliza para verificar la firma. 

La relación matemática entre estas dos claves es unidireccional: se puede firmar con la clave privada y verificar con la clave pública, pero no se puede derivar la clave privada a partir de la clave pública. La elección del algoritmo es crucial. Los tres algoritmos más utilizados actualmente en la firma de código son: 

RSA (Rivest-Shamir-Adleman) — El algoritmo más consolidado, que se suele utilizar con claves de 2048 o 4096 bits. RSA Es compatible universalmente con diversos sistemas operativos y herramientas, pero el mayor tamaño de sus claves lo hace más lento que las alternativas modernas con niveles de seguridad equivalentes. 

ECDSA (Algoritmo de firma digital de curva elíptica) — Utiliza matemáticas de curvas elípticas para lograr una seguridad equivalente a RSA con tamaños de clave significativamente más pequeños. Un 256 bits ECDSA La clave (P-256) ofrece prácticamente la misma seguridad que una clave RSA de 3072 bits, con una generación y verificación de firmas más rápidas. ECDSA se utiliza cada vez más en entornos con recursos limitados y donde el rendimiento es crucial. 

EdDSA (Algoritmo de firma digital de la curva de Edwards) — La más reciente de las tres, basada en curvas Edwards retorcidas (generalmente Ed25519). EdDSA ofrece un rendimiento excelente, sólidas propiedades de seguridad y es resistente a ciertos ataques de canal lateral que pueden afectar a las implementaciones de ECDSA.  

El proceso de firma  

1. hash: El editor de software ejecuta el código a través de una función hash criptográfica, SHA-256 como mínimo, ya que SHA-1 es criptográficamente vulnerable y está obsoleto. NIST Desde 2011 (y prohibido en la firma de código por las principales autoridades de certificación desde 2016), SHA-256 genera una "huella digital" de longitud fija del código, denominada resumen criptográfico. Incluso un solo bit modificado en el código produce un hash completamente diferente. 
2. Firmar el hash: El editor cifra el hash utilizando su clave privada. Este hash cifrado es la firma digital. 
3. Adjuntar la firma: La firma, junto con la del editor certificado (que contiene la clave pública), viene incluido con el software. 

El proceso de verificación 

Cuando un usuario descarga y ejecuta el software, el sistema operativo o la herramienta de seguridad: 

1. Extrae la firma y el certificado del archivo. 
2. Valida la cadena de certificados comprobando que el certificado haya sido emitido por una CA de confianza, que no haya caducado y que no haya sido revocado (mediante CRL u OCSP). 
3. Valida la marca de tiempo, es decir, confirma que la firma se aplicó mientras el certificado estaba activo, lo que garantiza que la firma siga siendo válida incluso después de que caduque el certificado. 
4. Utiliza la clave pública del certificado para descifrar la firma y recuperar el hash original. 
5. Genera un hash independiente para el software descargado. 
6. Compara los dos hashes. Si coinciden, el software está intacto y proviene genuinamente del editor declarado. Si no coinciden, ¡la verificación falla! El software ha sido modificado. 

El papel de las autoridades de certificación (CA) 

Ahora es fundamental saber y comprender qué impide que un actor malicioso simplemente cree su propio par de claves y afirme ser Microsoft o Adobe. 

Aquí es donde Autoridades de certificación (CA) Adelante. Una CA es una tercera parte de confianza (como DigiCert, Sectigo o GlobalSign) que emite certificados de firma de código solo después de verificar la identidad del solicitante. La firma de la CA en el certificado es lo que le otorga legitimidad. Pero la infraestructura de confianza va más allá de una sola CA. 

Jerarquía de CA raíz frente a CA intermedia 

El PKI El modelo de confianza es jerárquico. En la cúspide se encuentra la CA raíz, una entidad altamente segura, a menudo sin conexión a internet, cuyo certificado es autofirmado y cuya clave pública está integrada directamente en los sistemas operativos y navegadores por proveedores como Microsoft, Apple y Mozilla. Dado que comprometer una CA raíz sería catastrófico, las claves privadas de la raíz se almacenan en HSM aislados de la red y rara vez se utilizan para la emisión directa de certificados. 

En cambio, las CA raíz emiten certificados a las CA intermedias (también llamadas CA subordinadas), que operan en línea y realizan el trabajo diario de emitir certificados de firma de código a los editores. Esto crea una cadena de confianza: CA raíz → CA intermedia → Certificado del editor. Al verificar una firma, el sistema recorre esta cadena, comparando la firma de cada certificado con la de su certificado padre, hasta llegar a una raíz de confianza. 

Tiendas de confianza 

Tu sistema operativo incluye un almacén de confianza preinstalado: una lista seleccionada de certificados raíz de CA de confianza. Windows mantiene el Programa de Certificados Raíz de Confianza de Microsoft, macOS e iOS mantienen el almacén de confianza de Apple, y las distribuciones de Linux dependen del paquete ca-certificates (a menudo obtenido del programa de Mozilla). Los navegadores como Chrome y Firefox pueden mantener sus propios almacenes de confianza independientemente del sistema operativo. Cuando un certificado de firma de código se encadena hasta una raíz en el almacén de confianza, la firma se considera de confianza. Si la cadena no se puede validar hasta una raíz de confianza, la firma se rechaza. 

Certificados de firma de código con validación extendida (EV) 

No todos los certificados de firma de código son iguales. Los certificados OV (Validación de la Organización) estándar requieren que la CA verifique que la organización del solicitante existe legalmente, pero la verificación es relativamente sencilla. Los certificados EV (Validación Extendida) requieren un proceso significativamente más riguroso: 

• Verificación de la existencia legal: la organización debe ser una entidad jurídica registrada y en regla ante su jurisdicción. 

• Domicilio físico y existencia operativa: la CA verifica la ubicación física y la presencia operativa de la organización. 

• Identidad del solicitante del certificado: la persona que solicita el certificado debe estar verificada como representante autorizado de la organización. 

• Verificación telefónica: la autoridad competente se pone en contacto con la organización a través de un número de teléfono verificado de forma independiente para confirmar la solicitud. 

• Control contra el blanqueo de capitales y las sanciones: la organización y sus directivos son cotejados con las listas de vigilancia gubernamentales y regulatorias. 

El resultado es un certificado que ofrece una garantía de identidad mucho más sólida. En Windows, el software firmado con EV genera inmediatamente reputación en SmartScreen, evitando la advertencia de "Editor desconocido", porque Microsoft tiene mayor confianza en la identidad verificada detrás del certificado. Los certificados EV también requieren que las claves privadas se almacenen en un módulo de seguridad de hardware (HSM), lo que eleva significativamente el listón para el robo de claves en comparación con los certificados OV, que se pueden almacenar en software. 

Certificados autofirmados Los certificados generados internamente, sin una autoridad de certificación (CA), son perfectamente válidos para entornos de prueba internos donde se controla la confianza en ambos extremos. Sin embargo, nunca deben usarse para software distribuido públicamente. No existe una cadena de confianza; los sistemas de los usuarios finales no los reconocerán como legítimos y no ofrecen ninguna garantía sobre la identidad del editor. 

La cadena de suministro de software 

Hasta ahora, hemos hablado de firmar un único programa informático. Pero el desarrollo de software moderno es mucho más complejo. Es probable que su producto incluya: 

• Bibliotecas y paquetes de código abierto (npm, PyPI, Maven, NuGet, etc.) 
• SDK y componentes de terceros 
• Artefactos de la canalización de CI/CD 
• Imágenes de contenedores 
• Scripts de infraestructura como código 
• Firmware y controladores 
• Lista de materiales de software (SBOM) 
• Imágenes de contenedores y artefactos de Docker 

Cada uno de estos elementos representa un posible punto de entrada para un ataque a la cadena de suministro, y las estrategias de firma deben abarcarlos todos, no solo los ejecutables finales. Las imágenes de contenedor deben firmarse con herramientas como cosign y verificarse en el momento de la implementación. La firma de artefactos para los resultados de la compilación (JAR, wheels) garantiza que el resultado del sistema de compilación coincida con el resultado de la compilación. La firma de SBOM añade una capa de certificación al inventario, lo que permite a los usuarios finales verificar no solo el software, sino también la lista completa de sus componentes. 

• Complejidad del ecosistema

  El ecosistema de código abierto está bajo un escrutinio más intenso que nunca, y con razón. La enorme dependencia de paquetes de terceros crea una superficie de ataque gigantesca. La mayoría de las aplicaciones empresariales incorporan cientos o miles de dependencias transitivas (paquetes que dependen de otros paquetes), muchas de las cuales son mantenidas por personas con recursos de seguridad limitados.

  El índice trimestral de malware de código abierto de Sonatype registró un aumento implacable a lo largo de 2025: en el primer trimestre se descubrieron casi 1 18,000 nuevos paquetes maliciosos, en el tercer trimestre se registraron 3 34,319, un aumento del 140 % con respecto al segundo trimestre, y para el cuarto trimestre de 2025, Sonatype había identificado la asombrosa cifra de 2 4 nuevos paquetes de malware de código abierto en un solo trimestre, impulsados ​​en gran medida por campañas automatizadas y autorreplicantes. El total acumulado de paquetes maliciosos identificados por Sonatype desde 2019 ha superado los 394,877 877,000.

• Escalada de la amenaza

  Lo más preocupante es que el 56 % del malware descubierto en el primer trimestre de 2025 estaba diseñado para la exfiltración de datos, dirigido principalmente a credenciales de desarrolladores, secretos de CI/CD y claves de API en la nube almacenadas en ubicaciones predecibles en las máquinas de los desarrolladores. Una vez extraídos, esos datos se convierten en la clave para comprometer todo un proceso de firma digital. Un atacante con acceso a un secreto de CI/CD o a una credencial de desarrollador puede inyectar código malicioso en el proceso de compilación, firmarlo con una clave legítima y distribuirlo a través de canales oficiales, todo ello sin siquiera tocar el perímetro de la organización objetivo.

Por lo tanto, una estrategia integral de firma de código debe abarcar toda la cadena, desde los paquetes de código abierto que se consumen hasta los artefactos que se producen y distribuyen. 

El marco SLSA 

El marco de Niveles de la Cadena de Suministro para Artefactos de Software (SLSA), desarrollado por Google, proporciona un modelo escalonado para evaluar y mejorar la integridad de la cadena de suministro. Va desde el Nivel 1 (documentación básica) hasta el Nivel 4 (los controles más rigurosos). La firma de código es un componente fundamental para alcanzar niveles SLSA superiores. A continuación, se explica qué significa cada nivel en la práctica: 

SLSA Nivel 1El proceso de compilación está documentado y automatizado mediante scripts. La información de origen y los metadatos sobre cómo se compilaron los artefactos están disponibles, pero no autenticados. Esto establece una base de trazabilidad. 

SLSA Nivel 2La compilación se ejecuta en un servicio de compilación alojado (no solo en el portátil del desarrollador), y el código fuente está firmado por dicho servicio. Esto significa que un atacante necesitaría comprometer el servicio de compilación, no solo el ordenador del desarrollador, para falsificar la procedencia del código. 

SLSA Nivel 3El servicio de compilación ofrece mayores garantías de aislamiento, y los datos de origen incluyen información sobre el entorno de compilación. El código fuente debe provenir de un sistema de control de versiones, y la compilación debe estar protegida y asegurada. 

Nivel 4 de SLSA: Requiere la revisión de todos los cambios por parte de dos personas, con una compilación reproducible e información completa del código fuente. En este nivel, toda la cadena, desde el código fuente hasta el artefacto, es a prueba de manipulaciones y auditable. 

Uno de los aspectos más importantes y complejos de la firma de código moderna es su integración en los procesos de compilación automatizados. Aquí es donde muchas organizaciones encuentran dificultades. Según un estudio de 2025, menos del 50 % de las empresas supervisan actualmente más del 50 % de su cadena de suministro de software, lo que significa que los atacantes operan habitualmente en puntos ciegos cuya existencia las organizaciones desconocen. 

Los errores más comunes incluyen: 

• Almacenar claves privadas en variables de entorno o archivos de configuración. — Este es un error crítico. Las claves privadas almacenadas en texto plano en un entorno CI/CD están a un paso de una configuración incorrecta del control de acceso de una posible vulneración total.  
• Compartir credenciales de firma entre equipos — Si todos los equipos de su organización utilizan la misma clave de firma, una sola cuenta de desarrollador comprometida podría dar lugar a versiones firmadas de forma maliciosa. 
• Firmar en el momento equivocado Firmar demasiado pronto en el proceso implica firmar código sin probar. Firmar demasiado tarde puede generar vulnerabilidades que permiten que artefactos sin firmar se propaguen entre sistemas. 
• No hay estrategia de rotación de llaves Las claves de firma deben rotarse periódicamente (como mínimo anualmente e inmediatamente después de cualquier posible vulneración de seguridad). Muchas organizaciones configuran su infraestructura de firma y nunca la revisan, dejando claves obsoletas y potencialmente expuestas. 
• No hay separación de funciones La separación de funciones garantiza que una cuenta de desarrollador comprometida no pueda firmar ni publicar unilateralmente código malicioso. Por ejemplo, el desarrollador que escribe el código no debe ser la misma persona que lo firma y lo publica sin la revisión de otro desarrollador. 
• Falta de firma de la política de cumplimiento Sin políticas bien definidas, la firma digital se vuelve improvisada. Los equipos pueden firmar con certificados incorrectos, omitir el sellado de tiempo o firmar en la etapa de compilación equivocada. Las plataformas de firma centralizadas, como nuestra CodeSign Secure, aplican políticas de forma programática y permiten a los usuarios controlar sus procesos y entornos de firma. 
• No hay correlación con el registro de auditoría. — Los eventos de firma deben registrarse, y esos registros deben correlacionarse con los eventos del sistema de compilación. Un evento de firma inesperado fuera de un proceso de compilación normal es una clara señal de que se ha producido una vulneración de seguridad. 

Ahora bien, quizás se pregunte: "¿Por qué los CISO, los líderes de DevSecOps y los ejecutivos de seguridad deberían preocuparse por implementar la firma de código en sus flujos de trabajo?". La cadena de suministro de software moderna va mucho más allá del código fuente. Incluye sistemas de compilación, flujos de trabajo de CI/CD, repositorios de artefactos, gestores de paquetes, canales de actualización, certificados y la infraestructura utilizada para entregar software a clientes y empleados. Este alcance es precisamente la razón por la que la firma de código se ha convertido en un elemento central de los principales marcos regulatorios y normativos.  

• NIST SSDF (SP 800-218)El marco de desarrollo de software seguro exige explícitamente verificar la integridad de los componentes de software, proteger las claves de firma e implementar procesos para detectar manipulaciones en el proceso de compilación. Se corresponde directamente con la firma de código como medida de control. 
• Diseño seguro según la CISALas directrices de CISA instan a los fabricantes de software a asumir la responsabilidad de los resultados en materia de seguridad, lo que incluye garantizar que el software entregado a los clientes pueda verificarse como auténtico y sin modificaciones. Firma de código es un mecanismo fundamental para esta entrega verificable. 
• Orden Ejecutiva 14028 (Mejora de la Ciberseguridad Nacional)La Orden Ejecutiva 14028, firmada en mayo de 2021, exigió que las agencias federales y sus proveedores de software cumplieran con requisitos específicos de seguridad en la cadena de suministro de software, incluyendo la generación de listas de materiales de software (SBOM), entornos de compilación seguros y verificación de la integridad de los artefactos. Esta orden convirtió la seguridad de la cadena de suministro y la firma de código en un requisito de cumplimiento para cualquier organización que realice negocios con el gobierno federal de los Estados Unidos. 

Cuando los atacantes no pueden vulnerar la aplicación directamente, suelen dirigirse al proceso de producción o distribución. Por ello, la firma de código se convierte en un control estratégico, no en una medida táctica secundaria. Proporciona a las plataformas, las herramientas de seguridad y los usuarios finales una forma de verificar que el software proviene del editor previsto y que no ha sido modificado tras su lanzamiento. En términos ejecutivos, la firma de código ayuda a reducir el riesgo de software manipulado, actualizaciones maliciosas y pérdidas de confianza en el proceso de lanzamiento. Contribuye tanto a la seguridad como a la credibilidad operativa. 

Al incluir la firma de código en la cadena de suministro, las organizaciones y los equipos deben seguir la siguiente lista de verificación para mantener sus entornos seguros: 

• Utilice certificados EV para todo el software de distribución pública firmado para producción.
• Siempre registre la fecha y hora de cada documento firmado utilizando una TSA de confianza.
• Almacene las claves privadas en un HSM. — nunca en archivos, variables de entorno o máquinas de desarrolladores.
• Integrar la firma en CI/CD en la etapa adecuada. (posterior a la prueba, previo al lanzamiento).
• Implementar el acceso basado en roles — No todo el mundo necesita privilegios de firma.
• Registre cada evento de firma y supervise si hay anomalías.
• Realiza un seguimiento de la caducidad de los certificados y automatiza los recordatorios de renovación. a los 90, 60 y 30 días.
• Tener un plan de revocación — saber exactamente cómo revocar y volver a firmar si una clave se ve comprometida.
• Gire las llaves periódicamente — como mínimo anualmente, e inmediatamente después de cualquier sospecha de vulneración de la seguridad o cambio de personal.
• Utilice claves de firma independientes para cada entorno. — Las claves de desarrollo, preproducción y producción deben ser distintas, lo que limita el alcance de las consecuencias en caso de una vulneración de seguridad.
• Utilice certificados de firma de corta duración siempre que sea posible. — especialmente para flujos de trabajo de firma sin clave, que eliminan por completo la gestión de claves de larga duración.

CodeSign Secure de Encryption Consulting 

CodeSign Secure Es una plataforma de firma de código centralizada, segura y escalable, diseñada para ayudar a las organizaciones a firmar código con confianza sin comprometer la seguridad ni la velocidad. Está diseñada para entornos DevOps modernos y se integra con herramientas populares. pipelines de CI / CD como Azure DevOps, Jenkins y GitLab, al tiempo que se aplican estrictos controles de acceso y flujos de trabajo de aprobación para mantener el proceso de firma limpio y conforme a las normas. 

Características principales

• Seguridad de claves respaldada por HSM

  CodeSign Secure aprovecha un FIP 140-2 HSM de nivel 3 para almacenamiento seguro de claves, que garantiza que las claves privadas estén siempre protegidas. La plataforma se integra con varios Módulos de seguridad de hardware, incluyendo Entrust nCipher, Thales Luna, Utimaco y Securosys, lo que garantiza que las claves criptográficas siempre se almacenen en un dispositivo de hardware seguro y a prueba de manipulaciones, ya sea que prefiera hardware local o HSM en la nube.

• Control de acceso basado en políticas

  El sistema de control de acceso de CodeSign Secure se integra con Microsoft Active Directory y Keycloak para registrar usuarios y permitir la gestión centralizada de sus credenciales y permisos. La plataforma ofrece un sistema detallado de control de acceso basado en roles (RBAC) con flujos de trabajo personalizables para proporcionar un control preciso sobre los procesos de firma de código, evitando el acceso no autorizado y minimizando los riesgos de seguridad.

  Las políticas de firma se aplican programáticamente a nivel de plataforma; es decir, ningún artefacto puede firmarse a menos que cumpla con todos los criterios predefinidos: el tipo de certificado correcto, la etapa de firma correcta y las aprobaciones requeridas. La separación de funciones se garantiza mediante flujos de trabajo de aprobación de varios pasos: un desarrollador puede iniciar una solicitud de firma, pero los gestores de versiones o los responsables de seguridad deben aprobarla antes de que se aplique la firma. Esto elimina el riesgo de que una sola cuenta comprometida firme y publique software unilateralmente sin supervisión. Además, los registros de auditoría documentan cada aprobación, denegación y evento de firma, lo que proporciona a los equipos de seguridad la evidencia que necesitan para los informes de cumplimiento y la investigación de incidentes.

• Integración perfecta de CI/CD

  La plataforma aplica controles de seguridad y validación de integridad para evitar que los artefactos sin firmar lleguen a producción y permite el seguimiento centralizado con alertas instantáneas ante intentos de firma no autorizados. CodeSign Secure está diseñado para admitir ciclos de desarrollo rápidos y procesos de integración y entrega continuas (CI/CD), incluyendo Azure DevOps, Jenkins, GitLab y más.

• Compatibilidad con diversos formatos y plataformas.

  La solución admite la firma de diversos formatos, como .exe, .dll, .jar, .apk, .dmg, contenedores Docker, binarios de firmware y más, garantizando que todos los artefactos de software se puedan firmar de forma segura en múltiples plataformas de sistemas operativos, como Windows, Linux y macOS. Se integra a la perfección con nuestro envoltorio PKCS11 personalizado y con numerosas herramientas de firma de terceros, como Signtool, Jarsigner, JSign y muchas más.

• Hashing del lado del cliente y sellado de tiempo seguro

  La plataforma utiliza el hash del lado del cliente, es decir, genera el hash del código en su máquina con la ayuda de un proveedor de almacenamiento de claves (KSP) personalizado, diseñado para funcionar a la perfección con el marco de trabajo Cryptography Next Generation (CNG) de Microsoft. Junto con marcas de tiempo seguras, garantiza la integridad y la durabilidad de las firmas digitales, incluso después de la expiración del certificado.

• Pistas de auditoría integrales

  La plataforma proporciona visibilidad en tiempo real de todo firma de código Realiza actividades de seguridad y cumplimiento normativo, manteniendo registros detallados de eventos y pistas de auditoría para controlar el uso de claves, investigar incidentes y cumplir con los requisitos normativos. Además, ofrece integración mediante plugins con numerosas herramientas SIEM, como Grafana, Loki y Splunk, a través de OpenTelemetry.

• Modelos de implementación flexibles

  Las organizaciones pueden aprovechar una solución totalmente gestionada y alojada en la nube con seguridad HSM integrada que ofrece todas las funciones a través del acceso API, o bien implementar CodeSign Secure en sus instalaciones utilizando servidores físicos, gestionando de forma segura las claves privadas en HSM en la nube, HSM locales o ambos, para obtener la máxima flexibilidad.

• Soporte para criptografía postcuántica (PQC)

  CodeSign Secure es compatible Criptografía post-cuántica La firma digital, mediante ML-DSA (Algoritmo de Firma Digital de Retícula Multivariada) y LMS (Firmas Leighton-Micali), dos esquemas de firma resistentes a la computación cuántica reconocidos por el NIST, se ejecuta directamente en el propio HSM. Al delegar este proceso a un HSM compatible con PQC, las enormes claves criptográficas necesarias nunca se exponen al sistema, permaneciendo físicamente bloqueadas en un entorno reforzado.

  Para las organizaciones que necesitan una transición gradual, CodeSign Secure también admite esquemas de firma dual, por ejemplo, el uso de una firma RSA o ECDSA clásica junto con una firma ML-DSA o LMS para diferentes requisitos de firma. La configuración de firma dual permite que distintos programas informáticos sean firmados tanto por sistemas de verificación clásicos como cuánticos, según los requisitos, y acepta la transición posterior a la computación cuántica.

Tanto si su empresa está en crecimiento, como si es una gran corporación o si opera en sectores altamente regulados como el automotriz, el sanitario o el de tecnología financiera, CodeSign Secure está diseñado para satisfacer sus necesidades específicas. Si gestiona decenas de identidades de firma en equipos distribuidos, ejecuta pipelines de CI/CD de alta velocidad o trabaja bajo estrictas normativas de cumplimiento, CodeSign Secure se creó pensando precisamente en sus desafíos. 

Conclusión 

La firma de código puede parecer una cuestión técnica y específica, algo que se configura una vez y se olvida. Pero como demuestran de forma contundente los datos sobre amenazas de 2025 y 2026, es uno de los controles de seguridad más importantes de su arsenal. Ataques a la cadena de suministro de software Se duplicaron con creces en 2025. Los atacantes ya no esperan en la puerta; están integrados en los paquetes que tus desarrolladores descargan cada mañana, en las tareas de CI/CD que tus pipelines ejecutan automáticamente y en los artefactos de compilación en los que tus equipos confían sin reservas. Cybersecurity Ventures proyecta que el costo anual global de estos ataques alcanzará los 138 mil millones de dólares para 2031. La pregunta es si tu estrategia de firma de código está preparada para afrontarlo. 

Ya sea que esté implementando su primera infraestructura de clave pública (PKI), integrando la firma de código en un entorno CI/CD multicloud complejo o buscando cumplir con marcos de trabajo como SLSA o NIST, Encryption Consulting está aquí para ayudarle, ya sea con asesoría, migración o integración. La cadena de suministro de software es tan fuerte como su eslabón más débil. Asegúrese de que la firma de código no sea el suyo.