Encontrar salió barato. El resto del ciclo de vida no. Un ciclo de vida de gestión de vulnerabilidades tiene las mismas etapas, sea cual sea el marco del que se dibuje: identificar candidatos, dictaminar cuáles son reales y con qué gravedad, decidir qué hacer con cada uno, subsanar, verificar la corrección, notificar a quien corresponda una notificación, y conservar el expediente. Según nuestra lectura, la etapa cara solía ser la primera. Hoy un escáner, un fuzzer, una plataforma de revisión o un asistente produce candidatos más rápido de lo que cualquier equipo puede dictaminarlos, y el ciclo de vida se rompe en las etapas siguientes, donde un candidato bien redactado tiene que convertirse en una decisión que alguien deberá justificar más adelante.
Esta nota recorre las etapas, dice qué exige en cada una el Cyber Resilience Act europeo, el Reglamento (UE) 2024/2847, y dice dónde se sitúa una revisión adversarial independiente. Su peso está en las etapas posteriores a la primera.
Identificar: donde no vendemos
Los candidatos vienen de todas partes: análisis estático, herramientas de dependencias y de nomenclatura de materiales, fuzzers, plataformas de revisión, asistentes, sus propios ingenieros y quienes informan desde fuera. Una revisión adversarial también produce candidatos (las nuestras han incluido defectos corregidos después aguas arriba), pero encontrar es lo que un encargo rinde por el camino, no aquello por lo que se cobra. Una práctica situada aquí competiría con su escáner en volumen.
Qué exige el CRA aquí. El fabricante debe identificar y documentar las vulnerabilidades y los componentes presentes en el producto, también mediante la elaboración de una nomenclatura de materiales de los programas informáticos (anexo I, parte II, punto 1), y debe proporcionar una dirección de contacto para informar y facilitar el intercambio de información sobre posibles vulnerabilidades (anexo I, parte II, punto 6). Son obligaciones del fabricante; los hallazgos de un revisor externo las alimentan y no las liberan.
Dictaminar: de la opinión bien redactada al peldaño de evidencia
Esta es la primera etapa donde el ciclo de vida se rompe, porque todas las herramientas anteriores emiten opiniones sobre el código con la misma fluidez, sea o no alcanzable el camino. El dictamen es la etapa donde esas opiniones se zanjan o se gradúan. Nuestra regla es: primero el oráculo. Una afirmación decidible (¿se ejecuta este camino?, ¿permite la especificación este valor?) va a aquello que puede responderla, una ejecución, un compilador o la especificación, antes de pedir a nadie una opinión al respecto. Lo que sobrevive se gradúa por el peldaño de evidencia que realmente alcanzó (rastro en el código fuente, prueba de compilación, test, reproducción en ejecución real, y para cualquier afirmación probabilística una tasa con intervalo y los registros de cada ensayo), o se marca como solo plausible. La gravedad sigue entonces a la prueba, no a la confianza de un modelo. Un hallazgo no es un veredicto es el tratamiento extenso.
Qué exige el CRA aquí. Llevar a cabo exámenes y pruebas eficaces y periódicos de la seguridad del producto (anexo I, parte II, punto 3), y, en la documentación técnica, informes de las pruebas realizadas para verificar la conformidad del producto y de los procesos de gestión de vulnerabilidades (anexo VII, punto 6). Un informe de pruebas realizadas es un informe de qué se examinó, cómo y qué se estableció, que es lo que un expediente graduado por evidencia es y una lista ordenada por gravedad no. Y durante algún tiempo esos informes se escribirán antes de que sea citable la norma armonizada que define «eficaces y periódicos», así que tendrán que sostenerse por sus propios méritos: Las normas pueden deslizarse, la fecha de notificación no.
Decidir: cuando la herramienta y el equipo discrepan
La segunda ruptura. Una herramienta marca una vulnerabilidad crítica; ingeniería dice que el marco de trabajo la mitiga; el equipo de seguridad no tiene tiempo para demostrarlo ni autoridad para imponerse a un plazo, y el ticket se cierra por agotamiento. Nuestras reglas de cierre son las de la página revisión de código adversarial: un recuento nunca establece nada; donde los revisores discrepan sobre qué hace el código, decide el código fuente; donde un rechazo descansa en «incierto», la afirmación pasa a una cola conservada con un responsable, un vencimiento y un criterio de reapertura, y se expone de nuevo a un linaje fresco. Esa cola existe para que incierto no pueda convertirse en silencio en riesgo aceptado. Qué zanja un hallazgo trata la primera de esas reglas, incluido el caso en que lo revisado era nuestra propia herramienta.
Qué exige el CRA aquí. El fabricante debe abordar y subsanar las vulnerabilidades sin demora, también mediante la provisión de actualizaciones de seguridad (anexo I, parte II, punto 2), y debe poner en marcha y aplicar una política de divulgación coordinada de vulnerabilidades (anexo I, parte II, punto 5). Una decisión de no corregir es una decisión que el expediente técnico tendrá que explicar; una entrada en la cola conservada, con responsable y criterio de reapertura, es esa explicación, escrita en su momento.
Subsanar y verificar
Nuestro papel aquí es apoyar, no asumir: podemos acompañar los parches y verificar cada corrección frente al hallazgo al que apunta, en el commit que lo cerró, registrada como resultado propio. Una corrección verificada releyendo no es una corrección verificada volviendo a ejecutar; el expediente nombra el peldaño que alcanzó la propia verificación.
Qué exige el CRA aquí. Distribución segura de las actualizaciones, y parches de seguridad difundidos sin demora y de forma gratuita, acompañados de información de aviso (anexo I, parte II, puntos 7 y 8); divulgación pública de las vulnerabilidades solucionadas una vez esté disponible una actualización (anexo I, parte II, punto 4).
Notificar: donde el tercero gana sus honorarios
La tercera ruptura, y aquella por la que los compradores suelen venir. Una ejecución interna (con cuantos modelos se quiera, por aislados que estén) produce su propia palabra sobre su propio código. Según nuestra experiencia, tres de las cuatro partes que leerán su expediente no lo aceptan: los abogados de un adquirente en la diligencia debida, el suscriptor de una aseguradora cibernética, el equipo de seguridad de un cliente corporativo. Lo que compran es independencia organizativa: un expediente dictaminado y firmado por una persona con nombre ajena a su organización, que puede ser citada y que se retracta por escrito si un hallazgo no resiste. Esa es la propiedad que ningún equipo puede aportar sobre su propio trabajo, y es la totalidad de lo que vendemos.
La cuarta parte, el regulador, es la excepción, y corta en el sentido contrario: a menudo aceptará su autoevaluación, y después le exigirá cada registro que la sostiene.
Qué exige el CRA aquí. Dos vías de notificación, ambas a través de la plataforma única de notificación y ambas en vigor desde el 11 de septiembre de 2026 (artículo 14). Para una vulnerabilidad explotada activamente: una alerta temprana en las 24 horas siguientes a tener conocimiento, una notificación en 72 horas, y un informe final a más tardar 14 días después de que esté disponible una medida correctora o de mitigación. Para un incidente grave: los mismos pasos de 24 y 72 horas, y un informe final en el plazo de un mes desde la notificación. Una revisión externa no es una notificación ni ocupa su lugar; lo que sí puede hacer es convertir el «qué sabíamos, cuándo y cómo lo establecimos» que hay detrás de una notificación en un registro y no en una reconstrucción. Aparte de eso, los productos clasificados como importantes (anexo III) o críticos (anexo IV) se someten a procedimientos de evaluación de la conformidad conforme al artículo 32 que pueden implicar a un organismo notificado, que no somos, y al que nada de esta página sustituye.
Conservar
La documentación técnica y la declaración UE de conformidad se mantienen a disposición durante un mínimo de diez años a partir de la introducción del producto en el mercado, o durante el período de soporte si este plazo fuera más largo (artículo 13, apartado 13). Un expediente conservado una década lo leerá alguien que no estuvo en la sala, con más tiempo y menos benevolencia que quienes lo escribieron. Cada afirmación del nuestro nombra el peldaño de evidencia que alcanzó, cada superficie examinada y hallada sólida nombra el método y el control, cada retirada se escribe, porque ese es el lector para el que está construido.
Una frase
Las herramientas generan candidatos. Lo que nosotros generamos es el expediente firmado y graduado por evidencia que dice a su adquirente, a su aseguradora y a su regulador qué se estableció sobre su código, en qué peldaño, qué sigue siendo incierto y quién responde de decirlo. No lo que es cierto (ningún revisor puede prometerlo) sino lo que se mostró, y cómo.
Los límites que corresponden aquí: no hemos demostrado que un panel encuentre más defectos reales que un solo buen revisor y no lo afirmamos; la independencia de nuestras instancias está acotada por el procedimiento y no medida; nuestro banco de revisión son dos personas; formamos parte de un grupo que construye infraestructura de pagos y custodia, y lo declaramos por escrito antes de cualquier encargo; no somos un organismo notificado y nada de esto es asesoramiento jurídico. Las referencias al reglamento remiten al Reglamento (UE) 2024/2847, cotejadas con el texto español oficial antes de publicar esta nota; la lectura del ciclo de vida y la afirmación sobre qué etapa solía ser la cara son nuestras. Si una referencia es incorrecta, la corregimos aquí, por escrito.