Un análisis de la Universidad Masaryk revela que las certificaciones Common Criteria y FIPS-140 no garantizan seguridad continua en el tiempo
Mariia Bakhtina, especialista en investigación de la Universidad Masaryk, presentó hallazgos que cuestionan la interpretación habitual de las certificaciones de seguridad en tecnología. Su equipo analizó productos con certificaciones Common Criteria y FIPS-140 y encontró que aproximadamente 6 de cada 10 vulnerabilidades asociadas a estos productos fueron divulgadas después de la fecha en que obtuvieron la certificación. El análisis excluyó smartcards para evitar sesgos por categorías de producto con dinámicas de vulnerabilidad particulares.
El hallazgo expone una desconexión entre lo que una certificación promete — validación de seguridad en un momento específico bajo condiciones controladas — y lo que compradores y responsables de adquisiciones suelen asumir: que un producto certificado mantiene ese nivel de seguridad de forma indefinida. La certificación funciona como una fotografía, no como un monitoreo continuo. Una vez emitida, no se actualiza automáticamente cuando aparecen nuevas vulnerabilidades en el código o en las dependencias del producto.
Por qué las vulnerabilidades llegan después de la certificación
El patrón identificado por el equipo de Bakhtina no implica necesariamente que los procesos de certificación sean deficientes en su ejecución. Las certificaciones Common Criteria y FIPS-140 evalúan un producto en una versión específica, bajo una configuración determinada, en un momento dado. Después de ese punto, el software evoluciona: se agregan funcionalidades, se actualizan bibliotecas, se descubren técnicas de ataque que no existían cuando se realizó la evaluación original.
Una vulnerabilidad divulgada meses o años después de la certificación puede estar presente en el código desde el inicio — y haber pasado desapercibida durante la auditoría — o puede haber sido introducida en actualizaciones posteriores que ya no están cubiertas por el certificado original. En ambos casos, el comprador que confía exclusivamente en la vigencia del certificado como garantía de seguridad actual opera con información desactualizada.
Este desfase temporal entre certificación y exposición real afecta especialmente a sectores que dependen de ciclos de adquisición largos y que renuevan infraestructura cada varios años. En América Latina, donde organismos públicos y entidades financieras suelen exigir certificaciones internacionales como requisito de compra, la práctica habitual es verificar la existencia del certificado al momento de la licitación, pero no establecer mecanismos de monitoreo posterior sobre el estado de seguridad del producto ya desplegado.
Herramientas abiertas para auditar certificaciones
El equipo de Bakhtina desarrolla dos herramientas de código abierto — sec-certs y SCRUTINY — diseñadas para analizar certificaciones de seguridad de forma sistemática. Estas herramientas permiten cruzar datos de certificados con bases de vulnerabilidades públicas, identificar qué productos certificados tienen CVE posteriores a su fecha de certificación, y rastrear patrones en los procesos de evaluación.
La disponibilidad de estas herramientas en código abierto habilita a equipos de seguridad internos y auditores independientes a realizar verificaciones propias sobre productos que están considerando adquirir o que ya tienen en producción. En lugar de asumir que un certificado de 2023 garantiza seguridad en 2026, un responsable de compras puede consultar si el producto acumula vulnerabilidades conocidas desde entonces y si el fabricante las ha parcheado.
La pregunta que los compradores deberían hacer
Bakhtina propone que los compradores formulen una pregunta específica a los proveedores: qué proceso tiene la empresa para mantener la seguridad del producto después de la certificación. La respuesta debería incluir frecuencia de actualizaciones, política de divulgación de vulnerabilidades, tiempo promedio de respuesta ante hallazgos críticos, y si el fabricante recertifica el producto cuando introduce cambios significativos.
Un proveedor que solo exhibe el certificado como credencial estática, sin documentar un proceso continuo de gestión de vulnerabilidades, está ofreciendo una garantía que ya expiró en términos prácticos. La certificación sigue siendo válida formalmente, pero su utilidad como indicador de seguridad actual disminuye con cada mes que pasa sin actualización del proceso de evaluación.
Nuestro análisis
El hallazgo de la Universidad Masaryk confirma un patrón que ya se observa en incidentes documentados: productos con certificaciones vigentes que sufren compromisos por vulnerabilidades posteriores a la fecha de evaluación. La certificación no es inútil — sigue siendo evidencia de que el producto pasó por un proceso de auditoría en algún momento — pero su valor como indicador de seguridad presente decae rápidamente si no se complementa con monitoreo activo y gestión de vulnerabilidades por parte del fabricante.
Para compradores en América Latina, donde las certificaciones internacionales suelen ser requisito no negociable en licitaciones públicas y contratos con entidades reguladas, este análisis plantea la necesidad de reformular los criterios de evaluación. Un pliego que exige certificación Common Criteria o FIPS-140 sin especificar antigüedad máxima del certificado, sin requerir evidencia de gestión continua de vulnerabilidades, y sin establecer cláusulas de actualización obligatoria ante CVE críticos, está comprando una ilusión de seguridad. ¿Cuántos contratos vigentes en la región incluyen hoy mecanismos para invalidar una adjudicación si el producto certificado acumula vulnerabilidades sin parchear después de la firma?