Es lunes por la mañana y los clientes de un banco global no pueden acceder a sus cuentas. Las mesas de operaciones están bloqueadas, las transferencias bancarias congeladas y los centros de atención telefónica saturados. El culpable no es un ransomware, un ataque DDoS ni un sabotaje interno. Es un único certificado caducado integrado en una biblioteca de software de terceros.

¿Qué sucedería si ese mismo certificado defectuoso no fuera exclusivo de un banco, sino que estuviera integrado en un paquete de software de terceros ampliamente utilizado y adoptado por docenas de otras instituciones financieras?. En cuestión de horas, las interrupciones se propagan por los mercados. Los reguladores están al teléfono, la prensa circula y la junta directiva exige respuestas.

Esto no es solo un escenario hipotético. Es exactamente lo que le ocurrió a Alaska Airlines el año pasado. Lo que parecía un descuido menor fue, de hecho, un fallo en la gobernanza del ciclo de vida de los certificados con un amplio impacto operativo.

La conclusión es clara: la cadena de suministro de certificados digitales es un problema sistémico de resiliencia. Sin embargo, con demasiada frecuencia, la gestión del ciclo de vida de los certificados (CLM) se sigue considerando una tarea de TI de bajo nivel. En realidad, es un tema prioritario en la agenda de la junta directiva.

Capa oculta de la cadena de suministro.

Las aplicaciones modernas se asemejan a piezas de Lego. Los desarrolladores incorporan bibliotecas de terceros, componentes proporcionados por proveedores y paquetes de código abierto a gran escala. Cada una de estas dependencias lleva sus propios certificados digitales. Algunos son emitidos por autoridades de certificación reconocidas, otros son autofirmados y otros pueden ser de larga duración o estar mal gestionados.

En teoría, los certificados garantizan la autenticidad y la confianza. En la práctica, muchas organizaciones carecen de mecanismos de validación. Los proveedores pueden proporcionar software firmado con certificados caducados, emitidos incorrectamente o incluso diseñados para durar un siglo. Los paquetes de código abierto pueden basarse en certificados autofirmados con un cifrado débil.

Estas vulnerabilidades crean superficies de ataque ocultas: puntos de entrada que los adversarios pueden explotar para infiltrarse no solo en una empresa, sino en ecosistemas completos de clientes.

No es solo un problema de TI.

Cuando un certificado caduca, los primeros en enterarse suelen ser los equipos de operaciones de TI, ya que la interrupción les afecta directamente. Los sitios web se caen, las aplicaciones dejan de autenticarse y los clientes no pueden realizar transacciones. El equipo de TI recibe las solicitudes de emergencia, pero la causa principal suele estar en la falta de gobernanza de los componentes y certificados de terceros.

Por eso, llamarlo un problema de TI es un error. La falla en la gobernanza de certificados expone la incapacidad de una organización para garantizar la continuidad operativa. En sectores como los servicios financieros, la atención médica y las infraestructuras críticas, estas fallas no son solo inconvenientes, sino riesgos existenciales. Una interrupción o una vulneración puede dañar la confianza de los clientes, generar escrutinio regulatorio y costar millones en pérdidas de negocios.

La resiliencia operativa recae, en última instancia, en el liderazgo. Al igual que las juntas directivas supervisan los controles financieros o la logística de la cadena de suministro, deben exigir responsabilidades por las cadenas de suministro de certificados digitales. Sin ese mandato jerárquico, las organizaciones siguen siendo vulnerables a fallos evitables.

El desafío de la escala y la visibilidad.

Entonces, ¿por qué es tan difícil gestionar el riesgo de la cadena de suministro de certificados?. La respuesta reside en la escala y la fragmentación. Las grandes empresas pueden tener cientos de miles de certificados en sistemas internos, servicios en la nube, API, dispositivos IoT y software de terceros. Los certificados pueden estar dispersos en silos, gestionados de forma diferente por desarrolladores, equipos de DevOps y operaciones de seguridad, con escasa coordinación.

Esta falta de visibilidad crea puntos ciegos. El departamento de TI puede saber que un certificado está a punto de expirar, pero no sabe dónde se encuentra en la cadena de dependencias ni qué proceso empresarial crítico protege. Los desarrolladores pueden incorporar nuevas bibliotecas de código abierto sin verificar la fiabilidad de sus certificados, lo que deja a los CISO sin un inventario centralizado ni una visión clara de los riesgos.

Lo que dificulta la operación de los fallos de certificados es que nadie tiene el mapa completo. Sin una gobernanza centralizada, un certificado a punto de expirar o que no sea de confianza puede propagarse a aplicaciones críticas, provocando interrupciones, exponiendo datos confidenciales y magnificando el riesgo mucho más allá del ámbito técnico.

Inventarios de certificados más inteligentes.

El primer paso para abordar este problema es la visibilidad. Las empresas necesitan inventarios que tengan en cuenta las dependencias: no solo una lista de certificados, sino una comprensión de qué protege cada certificado, dónde se origina y a qué dependencias afecta.

Un inventario con conocimiento de dependencias revela:

• Si un certificado está autofirmado, caducado o emitido por una autoridad no confiable.

• Qué sistemas críticos, API o servicios de cara al cliente respalda.

• Qué proveedor o tercero es responsable de su emisión y mantenimiento.

Esta comprensión del contexto transforma la gestión de certificados (CLM) de una lucha reactiva a una gobernanza proactiva. Permite a los CISO y a las juntas directivas considerar los certificados no como artefactos técnicos aislados, sino como parte de la columna vertebral operativa del negocio.

Automatización de la aplicación de políticas de certificados.

La visibilidad por sí sola no es suficiente. Una vez que las organizaciones conocen qué certificados tienen y qué protegen, deben aplicar políticas de forma consistente. Esto significa:

• Exigir una vida útil corta de los certificados para reducir la exposición.

• Aplicar comprobaciones de revocación para detectar certificados comprometidos.

• Requerir algoritmos de cifrado robustos.

• Autenticar continuamente los certificados proporcionados por el proveedor mediante revisiones de seguridad y cumplimiento.

Igualmente importante, estos procesos deben automatizarse. El error humano suele ser la causa de fallos relacionados con los certificados, ya sea por incumplimiento de la fecha límite de renovación o por pasar por alto un paso de validación. La automatización de CLM garantiza que el descubrimiento, la renovación, la revocación y la aplicación de políticas se realicen sistemáticamente, sin depender de la supervisión manual.

Orquestando un marco de confianza.

Aquí es donde deben centrarse las juntas directivas: CLM ya no se trata solo de renovar certificados que vencen. Se trata de orquestar la confianza en toda la cadena de suministro de software. Los certificados actúan como el tejido conectivo de la confianza digital.

Al redefinir CLM como orquestación de la confianza de la cadena de suministro, las organizaciones pueden convertir la gestión de certificados en un elemento fundamental de la resiliencia operativa. Cuando la gobernanza de certificados falla, no es el departamento de TI el que paga las consecuencias. Es la empresa, los clientes y la confianza que los une.