Madurez de la firma de código al descubierto: desafíos y perspectivas

Si le preguntas a la mayoría de los equipos de desarrollo si firman sus códigos, la respuesta será afirmativa. Pero si les preguntas si tienen una política de firma centralizada, un procedimiento documentado de gestión de claves, un registro de auditoría de cada evento de firma y un proceso automatizado para la renovación de certificados antes de su vencimiento, la respuesta se vuelve más compleja.

La diferencia entre "firmamos código" y "contamos con un programa de firma de código maduro" es mayor de lo que la mayoría de las organizaciones perciben. Y en 2026, esa diferencia tiene consecuencias más importantes que nunca. Los ataques a la cadena de suministro alcanzan niveles récord y, según el Informe de Investigaciones de Violaciones de Datos de Verizon de 2026 , que analiza más de 22 000 violaciones confirmadas en 145 países, se constató que la participación de terceros representa ahora el 48 % de todas las violaciones, un aumento del 60 % con respecto al año anterior.

La votación CSC-31 del Foro CA/Browser redujo la validez de los certificados de firma de código de 39 meses a 460 días, con vigencia a partir del 1 de marzo de 2026. El NIST publicó un borrador público inicial de la versión 1.2 del SSDF (SP 800-218 Revisión 1) en diciembre de 2025, elevando el estándar para lo que constituye un desarrollo de software demostrablemente seguro. Además, los reguladores de todos los sectores están pasando de las directrices a la aplicación de la normativa.

Analizaremos un modelo práctico de madurez en la firma de código: cuatro etapas que describen cómo las organizaciones evolucionan desde prácticas de firma fragmentadas y ad hoc hasta programas totalmente automatizados, regidos por políticas y preparados para el futuro. Independientemente de la situación actual de su organización, comprender dónde se encuentra y cómo será la siguiente etapa es el punto de partida para alcanzarla.

Madurez en la firma de código, definida como el grado en que la custodia de claves respaldada por HSM, el control de acceso basado en roles (RBAC) con separación de funciones, las puertas de aprobación, la rotación programada de claves, los registros de auditoría inmutables, la revocación probada, el sellado de tiempo obligatorio y los entornos de compilación aislados son aplicados por la infraestructura en lugar de por documentos de política que se confía que las personas sigan, medido en cuatro etapas, desde ad hoc hasta optimizado.

Puntos Clave

• 3CX (2023) es la prueba más clara de que la madurez, y no la criptografía, es el punto de fallo habitual: tanto la firma como el certificado eran auténticos, y la vulneración se produjo porque ningún control impidió que un atacante que accedió al entorno de compilación activara una operación de firma.
• Una política que no se aplica técnicamente no es un control; la diferencia entre "tenemos una política de firmas" y "nuestra infraestructura hace que sea imposible eludir la política" es toda la distancia entre la Etapa 2 y la Etapa 3.
• La rotación de claves, la preparación para la revocación y el aislamiento de compilaciones suelen faltar incluso en programas que, por lo demás, son maduros; consulte la sección "Controles que no se deben omitir" a continuación para obtener información específica sobre cada uno de ellos.
• Esta página es el marco de diagnóstico, ¿en qué punto se encuentra su programa y cuál es la siguiente etapa? Para obtener una lista de verificación plana e independiente de la etapa de las prácticas individuales, consulte Buenas prácticas de firma de código en el ciclo de vida del desarrollo de software (SDLC).
• La puntuación de madurez es un diagnóstico, no una garantía de seguridad; consulte la sección "Limitaciones" a continuación antes de considerar un resultado de Etapa 3 o 4 como prueba suficiente de seguridad.

Por qué la madurez de la firma de código es más importante que nunca.

La firma de código existe por una razón fundamental: brindar a los usuarios y plataformas de software una forma de verificar que un archivo binario fue producido por una entidad conocida y de confianza, y que no ha sido modificado desde su firma. Cuando funciona correctamente, es el mecanismo principal para establecer la identidad del software y garantizar su integridad.

Cuando falla, ya sea porque se roba una clave de firma, se utiliza un certificado sin autorización o la operación de firma se realiza fuera de cualquier marco de gobernanza, las consecuencias pueden ser graves y de gran alcance.

Analicemos uno de los ataques a la cadena de suministro más importantes de la historia reciente para ver exactamente qué sucede cuando se abusa de la firma de código:

3CX (2023): El Grupo Lazarus, vinculado a Corea del Norte, llevó a cabo un ataque en cascada a la cadena de suministro en el que un paquete de software financiero comprometido provocó la vulneración del entorno de compilación de 3CX. La aplicación de escritorio de 3CX, utilizada por aproximadamente 600 000 organizaciones, fue firmada con el certificado legítimo de 3CX y distribuida a los clientes como una actualización rutinaria. Ni la firma ni el certificado eran fraudulentos. El archivo firmado en sí era malicioso.

Este ataque deja una importante lección: una firma válida en código malicioso no es un fallo de seguridad a nivel criptográfico, sino un fallo de gobernanza y de proceso. Ni la clave ni el certificado fueron robados ni falsificados. El proceso de firma simplemente carecía de controles que hubieran impedido que un atacante que ya hubiera accedido al entorno de compilación activara la firma.

¿Qué es un modelo de madurez de firma de código?

Un modelo de madurez es un marco que describe cómo una capacidad evoluciona desde una práctica inicial e informal hasta una operación totalmente optimizada. El Modelo de Madurez de Capacidades (CMM, por sus siglas en inglés), desarrollado originalmente por el Instituto de Ingeniería de Software de Carnegie Mellon, estableció el patrón fundamental, que requería que las organizaciones progresaran a través de etapas definidas, cada una de las cuales representaba un mayor nivel de disciplina, repetibilidad y resiliencia en los procesos.

Estos son todos los criterios que importan para la madurez de la firma de código:

Dimensión	Lo que cubre
Gestión de claves	Cómo se generan, almacenan, protegen y rotan las claves de firma privadas.
Control de Acceso	Quién puede firmar, qué puede firmar y qué supervisión rige ese acceso.
Política y Gobernanza	Si las políticas de firma están documentadas, se aplican y se revisan
Gestión de certificados	Cómo se realiza el seguimiento, la renovación y la revocación de los certificados en toda la organización.
Integración de canalizaciones	Ya sea que la firma esté integrada en los flujos de trabajo de CI/CD o se realice manualmente.
Auditoria y Monitoreo	Si cada evento de firma se registra, se revisa y se alertan los eventos anómalos.
Respuesta al incidente	Si la organización cuenta con un plan para claves comprometidas o firmas no autorizadas
Preparación futura	Si el programa tiene en cuenta la criptografía postcuántica y los estándares en evolución.

Controles que no se deben omitir: Rotación, revocación, separación de funciones y aislamiento de edificios.

Incluso en programas que parecen maduros, se omiten cuatro controles, ya que no aparecen hasta que algo los obliga a activarse. Nombrarlos explícitamente, en lugar de incluirlos en "gestión de claves" o "control de acceso", facilita su verificación.

Rotación de claves

Almacenar una clave en un HSM indica dónde se encuentra, no cuánto tiempo permanece sin cambios. Un programa maduro define un calendario de rotación por clave, vinculado a la renovación del certificado dentro del período de validez actual de al menos 460 días, y trata la rotación como un evento rutinario y automatizado, en lugar de algo que se activa solo ante una posible vulneración. Si su programa solo puede responder a la pregunta "¿cuándo se rotó por última vez esta clave de firma específica?" comprobando la fecha de caducidad del certificado, la rotación no se gestiona como un control independiente.

Preparación para la revocación

Un plan de respuesta a incidentes documentado no es lo mismo que uno probado. La preparación para la revocación implica saber, antes de un incidente, exactamente qué artefactos ha firmado un certificado determinado, poder generar esa lista en el plazo de una hora si se sospecha una vulneración y haber confirmado previamente que la revocación del certificado no interrumpe silenciosamente un canal de distribución que no verifica el estado de revocación. Para obtener información sobre la mecánica específica de la revocación, las implicaciones de la marca de tiempo y la nueva firma tras una vulneración, consulte el documento « Establecimiento de un marco de firma de firmware para el cumplimiento de la CRA».

Separación de tareas

El control de acceso basado en roles (RBAC) determina quién tiene permiso para firmar; la separación de funciones determina si una misma identidad puede solicitar y aprobar la misma operación de firma. Un programa puede tener un RBAC granular y aun así no cumplir con la separación de funciones si el rol del desarrollador principal incluye ambos permisos. La verificación técnica es sencilla: ¿puede una cuenta, actuando sola, obtener la firma de un artefacto sin la participación de una segunda identidad? Si la respuesta es afirmativa, se trata de una brecha de la Etapa 2 que utiliza herramientas de la Etapa 3.

Construir aislamiento

Este es el control del que carecía el entorno de compilación de 3CX, y es el que suelen pasar por alto la mayoría de las autoevaluaciones de madurez, ya que se encuentra antes de la operación de firma. El aislamiento de la compilación implica que el entorno que produce el artefacto es efímero y de un solo uso, no un servidor de compilación persistente que una ejecución comprometida puede contaminar para cada compilación posterior. Se trata de un control del proceso de compilación, no de un control de la plataforma de firma, razón por la cual es fácil que una revisión de madurez centrada en la firma lo omita. Consulte « Fortalecimiento de la seguridad de la cadena de suministro con SLSA Nivel 3 y firma de código» para obtener información sobre cómo SLSA Nivel 3 formaliza este requisito.

Las cuatro etapas de madurez de la firma de código

Etapa 1: Ad Hoc — Firma sin estructura

La primera etapa es donde la mayoría de las organizaciones realizan la firma de código, pero no la gestionan como un sistema dedicado adecuado. Esto incluye:

• Uno o un pequeño grupo de desarrolladores poseen el certificado de firma de código y la clave privada, que a menudo se almacenan en una máquina local, un token USB o como un archivo en un servidor de compilación compartido.
• No existe una política formal que documente quién está autorizado a firmar, qué se puede firmar ni bajo qué condiciones debe procederse a la firma.
• El seguimiento de la caducidad de los certificados se realiza de forma informal, dependiendo de si el desarrollador lo recuerda (o no), y la renovación es reactiva, a menudo motivada por un fallo en la firma en lugar de una gestión proactiva.
• Si se le preguntara "¿qué firmó el trimestre pasado?", la respuesta requeriría una búsqueda manual en los registros de compilación, si es que esos registros y el registro de auditoría existen.
• La firma es un paso manual que realiza un desarrollador cuando llega el momento de preparar una versión y no está integrada en ningún proceso automatizado.
• No existe ningún plan para lo que sucede si el certificado se ve comprometido o si el desarrollador que posee la clave de firma abandona la organización.

En esta etapa, la infraestructura de firma está prácticamente desprotegida. Las claves privadas, ubicadas en lugares accesibles mediante software, son vulnerables a cualquier atacante que acceda a la estación de trabajo del desarrollador o al servidor de compilación. No existe separación de funciones; la misma persona que escribe el código puede firmarlo sin ninguna revisión independiente. No hay visibilidad de los eventos de firma, por lo que las firmas no autorizadas pasarían desapercibidas. Y, al no existir una política documentada, no hay nada que auditar.

Este es el entorno que los atacantes explotaron en los ataques a SolarWinds y 3CX. No se trataba de sofisticados ataques de día cero contra los algoritmos criptográficos, sino de un acceso sin protección al paso de firma en un entorno de compilación no supervisado.

Etapa 2: Definida — Existen políticas, pero persisten las deficiencias

Las organizaciones en la Etapa 2 han reconocido que la firma de código ad hoc representa un riesgo y han tomado medidas para formalizarla. Existe un documento de política y las claves se almacenan de forma más segura. Sin embargo, las prácticas no se aplican de manera consistente y persisten deficiencias, particularmente en la automatización, la cobertura de auditoría y la gestión del ciclo de vida de los certificados. Esta etapa presenta lo siguiente:

• Existe una política escrita de firma de código que describe los requisitos de almacenamiento de claves, quién está autorizado a firmar y cómo deben gestionarse los certificados. Sin embargo, el cumplimiento de esta política es inconsistente, ya que se aplica mediante la concienciación y la costumbre, en lugar de controles técnicos.
• Las claves privadas se han movido fuera de las máquinas de los desarrolladores. Las claves se pueden almacenar en tokens de hardware USB que cumplen con FIPS 140-2 Nivel 2, que cumple CA / Foro del navegador cumple con los requisitos, pero introduce desafíos logísticos, especialmente bajo el nuevo período de validez del certificado de 460 días, donde los tokens deben reemplazarse aproximadamente cada 15 meses.
• Existe cierto control de acceso que impide que todos puedan firmar, y se han designado certificados específicos para entornos concretos (desarrollo frente a producción). Sin embargo, este control no es detallado ni se aplica a nivel técnico, y depende de que los desarrolladores sigan procedimientos documentados.
• El inventario de certificados existe de alguna forma, como una hoja de cálculo, un recordatorio en un calendario compartido o un ticket en un sistema de gestión de proyectos, pero se mantiene manualmente y es propenso a quedar obsoleto.
• La firma digital puede estar parcialmente integrada en los procesos de compilación de algunos productos, pero los pasos de firma manual persisten para otros, en particular para los productos heredados o los gestionados por equipos más pequeños.
• Existen algunos registros de auditoría donde los eventos de firma pueden capturarse en los registros de compilación, pero estos no están centralizados, no se supervisan activamente y no se utilizan para detectar anomalías.

El principal riesgo en la Etapa 2 radica en la brecha entre la política y la práctica. Las políticas que no se aplican rigurosamente no constituyen controles efectivos. Si una política establece que «las claves no deben almacenarse en las estaciones de trabajo de los desarrolladores», pero nada impide que un desarrollador copie un archivo de clave a su computadora portátil por comodidad, la política ofrece una falsa sensación de seguridad. De igual modo, un modelo de control de acceso que se basa en que las personas sigan procedimientos documentados es vulnerable tanto a amenazas internas como a intrusiones externas.

Etapa 3: Gestionada — Centralizada, controlada y auditada

En la Etapa 3, la firma de código ha evolucionado de una política documentada a una disciplina técnicamente aplicada y gestionada centralmente. Los controles no solo están escritos, sino que se implementan en la infraestructura y los sistemas. El acceso se rige por RBAC, configurado y aplicado en una plataforma de firma con claves en HSM y no en tokens. Además, cuenta con un registro de auditoría completo y supervisado activamente.

• Las claves de firma privadas se generan internamente y nunca salen. Certificación FIPS 140-2 Nivel 3. Módulos de seguridad de hardwareEl HSM físico o en la nube es administrado por el equipo de seguridad, no por desarrolladores individuales. La exportación de claves está técnicamente deshabilitada a nivel de política del HSM.
• Una plataforma de firma centralizada aplica un control de acceso basado en roles, donde los roles designados con permisos definidos rigen quién puede solicitar una operación de firma, quién debe aprobarla y qué artefactos se pueden firmar con qué certificado.  
• La gestión del ciclo de vida de los certificados de firma de código es sistemática, con un inventario de todos los certificados, sus fechas de vencimiento, propietarios asignados y productos y flujos de trabajo asociados. Este inventario se mantiene en un sistema de gestión, no en una hoja de cálculo. Las alertas de renovación son automáticas y se activan con suficiente antelación al vencimiento.
• La firma digital está integrada en los procesos de CI/CD para todos los artefactos de producción y es una etapa controlada y sujeta a políticas en el proceso de lanzamiento, no un paso manual iniciado por un desarrollador, con la aplicación consistente del sello de tiempo RFC 3161 en todas las operaciones de firma.
• Cada evento de firma genera una entrada inmutable en el registro de auditoría que captura el hash del artefacto, el certificado utilizado, la marca de tiempo, la identidad del solicitante y la cadena de aprobación. Los registros están centralizados, se revisan periódicamente y los eventos de firma anómalos generan alertas en tiempo real.
• Existe un plan documentado de respuesta ante incidentes de vulneración de claves de firma, que abarca qué claves pueden ser revocadas y reemplazadas mediante mecanismos de software, cuáles requieren reemplazo de hardware y cómo es el cronograma de comunicación y remediación.

En la Etapa 3, la infraestructura de firma es realmente difícil de vulnerar. Un atacante que comprometa una cuenta de desarrollador puede ser bloqueado e impedido de realizar operaciones de firma. Una amenaza interna que intente firmar un artefacto no autorizado generará una alerta de anomalía. Un certificado próximo a caducar activará un flujo de trabajo de renovación automática en lugar de caducar silenciosamente y provocar un fallo en la producción. Con un registro de auditoría adecuado, permite revisar, rastrear e investigar cualquier evento de firma histórico.

Etapa 4: Optimizada: automatizada, resiliente y preparada para el futuro.

Las organizaciones de este nivel no solo han implementado controles rigurosos, sino que han creado un programa de firmas que mejora continuamente, se adapta de forma proactiva a los cambios del sector y está diseñado para mantenerse resistente ante futuros desarrollos, incluida la migración a la criptografía postcuántica y la continua evolución regulatoria.

• La infraestructura de firma está totalmente automatizada, y el descubrimiento, la renovación, la implementación y la revocación de certificados se gestionan mediante sistemas integrados sin intervención manual.
• La organización ha implementado la criptoagilidad en su infraestructura de firma. Las migraciones de algoritmos y tamaños de clave se pueden ejecutar en todo el conjunto de certificados sin necesidad de actualizar individualmente los flujos de trabajo ni realizar reconfiguraciones manuales.
• Criptografía post-cuántica La firma está en producción o en fase piloto activa para artefactos de ciclo de vida largo. El NIST finalizó algoritmos como ML-DSA (FIP 204), SLH-DSA (FIP 205), y LMS (NIST SP 800-208) como algoritmos de firma post-cuántica aprobados.  
• El programa de firma de código participa en el marco de seguridad de la cadena de suministro de la organización, integrándose con la generación de la lista de materiales de software (SBOM), el seguimiento de la procedencia binaria y los procesos de gestión de vulnerabilidades.
• La organización lleva a cabo pruebas adversarias periódicas de su infraestructura de firma, como ejercicios de equipo rojo que intentan eludir los controles RBAC, introducir eventos de firma no autorizados o extraer material clave, para validar que los controles funcionan según lo previsto en condiciones de ataque realistas.
• Los planes de respuesta ante posibles fallos de seguridad se ensayan mediante simulacros, con objetivos de tiempo de recuperación documentados para cada categoría de clave de firma y certificado.

En la Etapa 4, el programa de firmas no solo protege contra patrones de ataque conocidos, sino que también es arquitectónicamente resistente a los ataques futuros. La transición poscuántica, que requerirá un trabajo de infraestructura significativo para la mayoría de las organizaciones a finales de la década de 2020, ya está en marcha. Los cambios regulatorios que exigen evidencia de cumplimiento demostrable, como la certificación NIST SSDF, los registros de auditoría para contratos de software federales y los requisitos específicos del sector, pueden cumplirse a partir de datos operativos en lugar de requerir documentación retroactiva.

Cuadro de mando de autoevaluación

Califica cada dimensión según la etapa que mejor se ajuste a la práctica actual, no a la etapa a la que aspiras. Sé específico: «Tenemos RBAC» solo se considera Etapa 3 si se aplica técnicamente y abarca la separación de funciones, no solo si está documentada.

Dimensión	Etapa 1 (Ad Hoc)	Etapa 2 (Definida)	Etapa 3 (Gestionada)	Etapa 4 (Optimizada)
Custodia de llaves	Máquina local o archivo compartido	Token de hardware, en posesión individual	HSM, exportación deshabilitada	HSM con rotación automatizada y criptoagilidad
Control de acceso	Sin restricción	Informal, basado en procedimientos	RBAC con aplicación técnica	RBAC más pruebas de separación de funciones ensayadas
Revocación	Ningún plan	Documentado pero no probado	Plan probado, existe mapeo de artefacto a certificado.	Ensayado con objetivos de tiempo de recuperación definidos.
Construir aislamiento	Servidor de compilación persistente y compartido	Servidor persistente, cierto endurecimiento del acceso	Aislado por compilación, verificado manualmente	Efímero por defecto, alineado con SLSA
Registro de auditoría	Registros de construcción inexistentes o informales	Existen registros, pero no están centralizados.	Centralizado, inmutable, revisado activamente	Integrado con SIEM y alertas de anomalías.

Cómo realizar la evaluación

1. Califique cada dimensión de la tabla anterior de forma independiente; la mayoría de las organizaciones se ubican en diferentes etapas en diferentes dimensiones, lo cual es normal y más informativo que una única puntuación general.
2. Identifique la dimensión con la puntuación más baja, no el promedio; un programa de Etapa 3 con preparación para la revocación de Etapa 1 tiene un incidente de Etapa 1 en potencia.
3. Compare cada puntuación con una fecha límite externa que la haga urgente: el plazo de validez del certificado de 460 días afecta a la puntuación de custodia y rotación de claves; los próximos requisitos de certificación del NIST SSDF afectan a la puntuación de la pista de auditoría y las políticas.
4. Elabore una hoja de ruta que aborde primero la dimensión con la puntuación más baja, no la más fácil; una victoria rápida en una dimensión que ya estaba en la Etapa 3 no reduce el riesgo real.

Limitaciones

La puntuación de madurez es una autoevaluación, no un hallazgo de auditoría, y su precisión depende de la honestidad de quienes la evalúan. Una revisión de controles técnicos o un ejercicio de equipo rojo (parte de la Etapa 4) revelarán las deficiencias que una autoevaluación no detecta. Alcanzar la Etapa 3 o 4 tampoco hace que una organización sea inmune a las vulnerabilidades; simplemente dificulta la explotación de modos de fallo específicos y bien conocidos (claves compartidas, control de acceso basado en roles no aplicado, firma sin supervisión), mientras que las técnicas de ataque nuevas o imprevistas siguen siendo posibles independientemente de la etapa.

¿Cómo puede ayudar CodeSign Secure de Encryption Consulting?

CodeSign Secure es la plataforma centralizada de firma de código con políticas de Encryption Consulting. Está diseñada para brindar soporte a las organizaciones en cada etapa de su desarrollo, proporcionando la infraestructura y los controles necesarios para alcanzar la Etapa 3 y las capacidades avanzadas requeridas para lograr la Etapa 4.

CodeSign Secure ofrece a las organizaciones que provienen de prácticas de firma ad hoc o parcialmente definidas un camino inmediato hacia los controles fundamentales que caracterizan la Etapa 3:

Gestión de claves respaldada por HSM: Las claves de firma privadas se generan internamente y nunca salen de los módulos de seguridad de hardware (HSM) con certificación FIPS 140-2 Nivel 3. CodeSign Secure se integra con Thales Luna, Entrust nCipher, Utimaco, Securosys y HSM en la nube de AWS y Azure. La exportación de claves está deshabilitada a nivel de política. El modelo de token USB, con todos sus desafíos logísticos de renovación y gestión de acceso, se reemplaza por una infraestructura de firma centralizada y accesible mediante API.

Control de acceso basado en roles (RBAC) y flujos de trabajo de aprobación: El modelo de control de acceso basado en roles de CodeSign Secure permite a los administradores definir con precisión quién puede solicitar una operación de firma, qué documentos pueden firmar, qué certificado se utiliza y qué pasos de autorización deben cumplirse antes de proceder con la firma. Estos controles se aplican mediante programación y no dependen de que las personas sigan procedimientos documentados.

Gestión de certificados de firma de código: La plataforma mantiene un inventario centralizado de todos los certificados gestionados, con alertas de renovación automatizadas configuradas para dar a los equipos tiempo suficiente durante el nuevo período de validez de 460 días.

Para las organizaciones que ya han establecido controles fundamentales y están avanzando hacia la optimización y la Etapa 4:

Integración de la canalización CI/CD: CodeSign Secure se integra de forma nativa con Azure DevOps , Jenkins , GitLab CI y otros sistemas de canalización importantes. Las operaciones de firma se gestionan mediante API, gracias a la integración con herramientas de firma de terceros y al cumplimiento del estándar de sellado de tiempo RFC 3161.

Compatibilidad con criptografía postcuántica: CodeSign Secure v3.02 introduce compatibilidad lista para producción con ML-DSA (FIPS 204, disponible en los niveles de seguridad ML-DSA-44, ML-DSA-65 y ML-DSA-87) como firmas separables, lo que permite a las organizaciones comenzar la transición a la criptografía postcuántica.

Registro y generación de informes de auditoría: Cada evento de firma en CodeSign Secure genera una entrada de registro inmutable que captura el hash del artefacto, el certificado, la marca de tiempo, la identidad solicitante y la cadena de aprobación. Los registros se integran con plataformas SIEM como Splunk y Grafana Loki a través de Opentelemetry para la detección de anomalías en tiempo real.

Tanto si empiezas desde la Etapa 1 y necesitas establecer controles básicos rápidamente, como si te encuentras en la Etapa 3 y estás avanzando hacia la automatización completa y la preparación post-cuántica, CodeSign Secure proporciona la infraestructura necesaria para respaldar ese proceso.

Conclusión

La madurez en la firma de código no es un destino, sino un proceso que se debe alcanzar. Cada organización se encuentra en algún punto de este camino, y cada etapa de mejora reduce significativamente el riesgo y la exposición operativa.

En Encryption Consulting, creamos CodeSign Secure para que esta transición sea práctica en cada etapa del proceso. La pregunta "¿son maduros sus procesos de firma de código?" no tiene una respuesta simple de sí o no. Pero sí tiene una respuesta específica y práctica: identificar en qué punto se encuentra, identificar qué componentes están más rezagados y crear una hoja de ruta priorizada para subsanar las deficiencias.

En 2026, la urgencia de esa hoja de ruta viene definida por desarrollos del sector como la validez de los certificados de 460 días, que hace insostenible la gestión manual del ciclo de vida; los ataques a la cadena de suministro, que siguen explotando la débil gobernanza de la firma; los requisitos del NIST SSDF, que exigen prácticas de desarrollo seguras demostrables; y la inminente transición post-cuántica, que requerirá cambios en la infraestructura que la mayoría de las organizaciones aún no han comenzado.

Preguntas frecuentes

¿Puede una organización encontrarse en diferentes etapas de madurez para diferentes controles?

Sí, y este es el caso habitual, no la excepción. Un programa suele tener una sólida custodia de claves respaldada por HSM (Etapa 3), mientras que su plan de revocación nunca se ha probado (Etapa 2) o su entorno de compilación no está aislado (Etapa 1 o 2). Califique cada dimensión de forma independiente en lugar de asignar una puntuación global.

¿Es suficiente con tener una política de firma de código por escrito para alcanzar la Etapa 3?

No. Una política escrita que no se aplica técnicamente, donde nada impide que alguien la eluda, es una característica de la Etapa 2. La Etapa 3 requiere que los controles se implementen en la infraestructura (política de HSM, aplicación de RBAC, seguimiento automatizado de certificados) en lugar de depender de que las personas sigan procedimientos documentados.

¿Por qué el aislamiento de la construcción no formaba parte de las ocho dimensiones originales?

El aislamiento de compilación se ubica antes de la operación de firma, en el proceso de compilación y no en la plataforma de firma, razón por la cual las revisiones de madurez centradas en la firma suelen pasarlo por alto. Es el control del que carecía el entorno de compilación de 3CX, y debe incluirse en cualquier evaluación que busque prevenir este modo de fallo, y no solo mejorar la custodia de claves.

¿Cuál es la diferencia entre este modelo de madurez y una lista de verificación de mejores prácticas?

Una lista de verificación enumera las prácticas a adoptar; un modelo de madurez diagnostica su situación actual en cada una y cuál sería el siguiente paso concreto, de modo que el esfuerzo se centre primero en la dimensión con la puntuación más baja en lugar de distribuirse uniformemente en una lista plana. Para la versión de lista de verificación plana, consulte las Mejores Prácticas de Firma de Código en el SDLC.