ENISA el futuro de la seguridad demostrable (III) de la evidencia documental a la evidencia procesable

Cómo las atestaciones procesables por máquinas pueden transformar la forma de relacionar afirmaciones, evidencias, verificaciones y decisiones de seguridad

Durante buena parte de las últimas décadas, la demostración de la seguridad de un producto se ha apoyado en documentos: informes de pruebas, matrices de riesgos, registros de vulnerabilidades, inventarios de componentes, actas de aprobación, resultados de auditoría o documentación técnica. Esa documentación sigue siendo necesaria y, en muchos casos, jurídicamente exigible. El problema aparece cuando la velocidad con la que evolucionan el software, sus dependencias y las amenazas obliga a tomar decisiones sobre evidencias que se encuentran repartidas entre repositorios, pipelines, sistemas de tickets, herramientas de análisis, SBOM, plataformas GRC y expedientes de conformidad.

El segundo artículo de esta serie analizaba precisamente cómo los 22 playbooks del ENISA Secure by Design and Default Playbook permiten acercar la seguridad al momento de la liberación, conectando principios, acciones, evidencias y criterios de GO/NO-GO. Esa lógica permitía superar la idea de que una versión está preparada para ser liberada simplemente porque su desarrollo funcional ha terminado. Sin embargo, una vez alcanzado ese punto surge una cuestión adicional: si disponemos de controles, pruebas y evidencias suficientes para justificar una decisión, ¿deben seguir siendo interpretados y relacionados manualmente cada vez que necesitamos evaluar una nueva versión, revisar una vulnerabilidad o verificar una condición de despliegue?

La sección 5 del documento de ENISA introduce aquí una evolución especialmente interesante mediante las denominadas machine-processable attestations. Su importancia no reside tanto en el formato utilizado como en la posibilidad de expresar determinadas afirmaciones de seguridad de manera estructurada, vinculándolas con evidencia, contexto y metadatos que otros sistemas puedan interpretar y verificar. El verdadero cambio, por tanto, no consiste en sustituir un PDF por un fichero JSON, sino en hacer explícitas relaciones que tradicionalmente permanecían implícitas dentro de documentos y procesos.

Desde esta perspectiva, el problema central puede formularse de manera sencilla: una organización no necesita únicamente conservar evidencia, sino también preservar el significado de esa evidencia, su alcance y su relación con la decisión que pretende sustentar.

De la afirmación a la evidencia verificable

Una atestación procesable por máquinas puede entenderse como una declaración estructurada, emitida por un sujeto identificable, que afirma el cumplimiento de un requisito o la existencia de una determinada propiedad de seguridad y que vincula esa afirmación con evidencia y metadatos que pueden ser interpretados y verificados por otros sistemas. Esta definición permite evitar una simplificación frecuente: considerar que la procesabilidad depende únicamente de utilizar un formato legible por software.

Imaginemos, por ejemplo, que un fabricante declara que una determinada versión ha superado el análisis de vulnerabilidades requerido antes de su liberación. Para una persona, esa afirmación puede resultar comprensible, pero para que otro sistema pueda utilizarla necesita conocer, al menos, a qué versión concreta se refiere, qué artefacto fue analizado, cuál fue el alcance de la prueba, qué herramienta se utilizó, cuándo se ejecutó, quién emitió la afirmación y qué resultado produjo.

Esto permite comprender que la verdadera transformación no se encuentra en la digitalización de la evidencia, sino en la estructuración de sus relaciones. Una evidencia solo adquiere valor operativo cuando podemos saber qué afirma, sobre qué objeto, bajo qué condiciones y con qué alcance.

La propuesta de ENISA resulta especialmente útil porque obliga a distinguir entre conceptos que con frecuencia se confunden. Una cosa es formular una afirmación; otra, verificar determinados aspectos de esa afirmación y de la evidencia asociada; y otra diferente, evaluar si los controles y las evidencias disponibles son realmente suficientes frente al riesgo. La atestación puede vincular una afirmación con su evidencia, la verificación puede comprobar integridad, vigencia, alcance o consistencia, y una evaluación puede ir más allá para determinar si todo ello resulta adecuado para el producto y el contexto analizado.

Esta separación es esencial porque una máquina puede verificar perfectamente una firma criptográfica, comprobar que un determinado hash corresponde a un artefacto o confirmar que una evidencia fue generada dentro de un período concreto, sin que de ello se desprenda automáticamente que el producto sea seguro o que la evidencia disponible resulte suficiente.

Una de las ideas centrales del artículo debería formularse, por tanto, de manera clara:

Una firma puede demostrar quién afirmó algo y que la afirmación no ha sido alterada; no demuestra necesariamente que aquello que se afirma sea cierto ni suficiente.

El ejemplo de las vulnerabilidades permite verlo con claridad. Una formulación rigurosa no diría simplemente que “no existen vulnerabilidades críticas”, sino que “el análisis realizado sobre los componentes incluidos en el alcance definido no identificó vulnerabilidades clasificadas como críticas conforme a los criterios aplicados”. La diferencia no es meramente semántica: introduce el alcance, el método y los límites de la conclusión. Todavía será necesario saber qué componentes fueron analizados, qué fuentes de vulnerabilidades se utilizaron, qué quedó fuera del perímetro, qué versión de la herramienta se empleó y si el análisis se realizó sobre el artefacto final o sobre una etapa intermedia.

La evidencia, por tanto, no debe interpretarse como una verdad absoluta, sino como información cuya capacidad probatoria depende de su contexto.

De la evidencia a la decisión

Esta lógica puede representarse mediante una cadena sencilla:

afirmación → evidencia → verificación → evaluación → decisión

La utilidad de esta secuencia aparece cuando determinados elementos pueden ser formalizados de manera suficiente como para que una parte de la decisión pueda automatizarse.

Supongamos que una organización establece como política que ningún artefacto pueda desplegarse si no dispone de una atestación válida que confirme la superación del análisis exigido. Un sistema puede comprobar automáticamente si la atestación existe, si la firma es válida, si corresponde al artefacto correcto, si sigue vigente y si el resultado satisface la regla establecida. A partir de esas comprobaciones puede bloquear o permitir el despliegue.

Pero conviene interpretar correctamente lo que ha ocurrido. El sistema no ha determinado que el producto sea seguro en sentido general; únicamente ha comprobado si se satisface una condición previamente definida.

Por eso, automatizar una release gate no significa automatizar el juicio sobre la seguridad, sino automatizar comprobaciones previamente formalizadas dentro de los límites de la regla, de la evidencia disponible y del nivel de confianza exigido. La evaluación de suficiencia, la aceptación de riesgo residual o la autorización de determinadas excepciones pueden seguir requiriendo intervención humana.

En realidad, esta distinción prolonga una idea ya desarrollada en el segundo artículo: automatizar aquello cuya decisión ha sido suficientemente definida y reservar el juicio para aquello que requiere contexto, ponderación y responsabilidad.

La evidencia no es estática

Otro aspecto relevante es la dimensión temporal. La evidencia puede ser auténtica, correcta y coherente en el momento en que se genera y, sin embargo, dejar de ser suficiente más adelante.

Una versión puede haber sido analizada hoy sin detectar vulnerabilidades críticas conocidas y verse afectada mañana por la publicación de una nueva CVE. La evidencia anterior no se vuelve falsa por ese motivo. Sigue reflejando correctamente lo que se conocía en el momento de su generación. Lo que cambia es su utilidad para adoptar una nueva decisión.

Por esta razón, cualquier sistema de evidencia procesable debería permitir responder al menos a cinco preguntas: si la evidencia ha sido alterada, a qué producto o versión se refiere, si continúa siendo vigente, si resulta coherente con el resto de la información disponible y quién la emitió bajo qué controles.

La integridad, el alcance, la vigencia, la consistencia y el origen no son atributos accesorios. Forman parte del significado de la evidencia.

Esta dimensión temporal resulta especialmente importante porque obliga a abandonar una concepción estática de la seguridad. La seguridad demostrable no puede consistir únicamente en conservar fotografías correctas del pasado; necesita mecanismos que permitan identificar cuándo un cambio de contexto obliga a revisar una afirmación previa.

Demostrabilidad y exposición de información

La existencia de evidencia estructurada tampoco implica que toda la información deba hacerse pública. Algunas pruebas pueden contener configuraciones internas, parámetros de compilación, logs, resultados técnicos detallados o información criptográfica cuya divulgación indiscriminada aumentaría el riesgo.

ENISA contempla precisamente esta tensión al distinguir conceptualmente entre información que puede formar parte de una capa pública de atestación y evidencia técnica que puede mantenerse bajo acceso restringido. La primera puede contener afirmaciones verificables, información de procedencia o firmas; la segunda puede conservar resultados detallados de pruebas, parámetros o configuraciones disponibles únicamente para quienes tengan una necesidad legítima de acceso.

La demostrabilidad, por tanto, no debe confundirse con transparencia absoluta. La exigencia razonable consiste en que las afirmaciones puedan ser verificadas y que la evidencia necesaria pueda ser accesible para quienes estén legitimados para evaluarla, no en que todos los detalles técnicos deban quedar expuestos públicamente.

Del documento aislado al grafo de evidencia

Esta evolución permite introducir una idea que puede resultar especialmente útil para comprender hacia dónde se dirige el modelo.

Tradicionalmente, una organización puede gestionar un registro de riesgos, un SBOM, resultados de escaneo, informes de pruebas, tickets, excepciones y expedientes de liberación como instrumentos separados. Cada uno contiene información relevante, pero el valor real aparece cuando es posible reconstruir las relaciones entre ellos.

Una versión contiene componentes. Algunos componentes pueden verse afectados por vulnerabilidades. Esas vulnerabilidades modifican determinados riesgos. Los riesgos se tratan mediante controles. Los controles se verifican mediante pruebas. Las pruebas generan evidencias. Las evidencias sustentan decisiones y, en determinados casos, excepciones.

Podemos representar esa relación como:

producto → versión → componente → riesgo → control → prueba → evidencia → decisión

A partir de esta lógica puede resultar útil hablar de un grafo de evidencia de seguridad. No se trata de un estándar propuesto por ENISA, sino de una forma conceptual de entender la evolución desde documentos aislados hacia relaciones estructuradas y verificables.

El valor del modelo no estaría en acumular más información, sino en poder responder preguntas que actualmente requieren reconstrucción manual: qué evidencia sustenta un determinado control, qué versiones están afectadas por una vulnerabilidad, qué decisión se adoptó a partir de una prueba concreta o qué controles deben revisarse cuando cambia un componente.

La transformación fundamental puede expresarse así:

No se trata de digitalizar documentos, sino de hacer explícitas, trazables y verificables las relaciones entre producto, riesgo, control, evidencia y decisión.

Un ecosistema tecnológico todavía heterogéneo

El interés de esta idea aumenta porque ya existen estándares y herramientas que cubren distintos fragmentos del problema.

Los SBOM y especificaciones como SPDX o CycloneDX permiten representar componentes y relaciones de un producto. VEX facilita la comunicación sobre el estado de determinadas vulnerabilidades respecto de productos o componentes. SLSA introduce requisitos orientados a fortalecer la procedencia y determinados aspectos del proceso de construcción, mientras que in-toto proporciona un marco más general para representar y verificar metadatos de actividades de la cadena de suministro. Sigstore y Cosign aportan mecanismos para firmar y verificar artefactos y atestaciones. OSCAL, desarrollado por NIST, permite estructurar controles, implementaciones y resultados de evaluación, y CycloneDX Attestations extiende la lógica de transparencia hacia la representación de requisitos, afirmaciones, evidencias y otros elementos de evaluación.

Estas tecnologías no son equivalentes ni resuelven el mismo problema. Tampoco deben entenderse como piezas perfectamente interoperables de un sistema ya maduro. El panorama es más realista si se reconoce que existe un ecosistema relevante de estándares y herramientas cuya adopción, interoperabilidad y madurez siguen siendo desiguales.

Su interés reside precisamente en que permiten comenzar a construir una infraestructura en la que la evidencia pueda conservar su contexto, relacionarse con otros elementos y ser reutilizada en procesos diferentes.

La confianza depende también de quién afirma

La procesabilidad técnica no resuelve por sí sola el problema de la confianza.

Una atestación puede proceder del propio fabricante, de su pipeline de CI/CD, de un proveedor, de una herramienta independiente, de un laboratorio o de un organismo de evaluación. Una firma válida puede permitir identificar al emisor, pero no determina automáticamente la competencia, la independencia o la fiabilidad de ese emisor.

Por ello, cualquier sistema de atestaciones debe considerar también quién puede emitir una afirmación, bajo qué controles, con qué independencia y para qué tipo de decisión. Una autoatestación puede ser perfectamente adecuada para determinadas decisiones internas y resultar insuficiente para otras que requieran evaluación independiente o un procedimiento formal de conformidad.

La confianza, por tanto, no debería tratarse como una propiedad binaria. Lo relevante es determinar qué nivel de confianza resulta razonable en función del riesgo, de la criticidad del producto y de las consecuencias de una decisión equivocada.

De la cadena de suministro documental a un seguimiento más continuo

La evidencia procesable adquiere especial interés cuando las relaciones superan los límites de una sola organización.

Un fabricante puede proporcionar a un integrador o comprador información sobre la composición del producto, vulnerabilidades conocidas, procedencia, resultados de determinadas pruebas, estado de soporte o propiedades de seguridad. Si esa información puede ser procesada automáticamente, determinadas verificaciones dejan de depender exclusivamente de una revisión manual realizada en el momento inicial de la contratación.

Cuando aparece una nueva vulnerabilidad, por ejemplo, puede ser posible identificar qué versiones utilizan el componente afectado, qué evidencias existen sobre su exposición y qué decisiones deberían revisarse.

La contratación no deja de requerir análisis ni juicio profesional, pero puede evolucionar desde una fotografía realizada al inicio de la relación hacia un seguimiento más continuo del riesgo tecnológico.

Esta capacidad es especialmente relevante en cadenas de suministro complejas, donde el estado de seguridad de un producto puede cambiar mucho después de haber sido adquirido.

Qué cambia para GRC y auditoría

Desde la perspectiva de GRC y auditoría, la evolución es igualmente relevante. Buena parte del trabajo actual consiste en reconstruir retrospectivamente qué ocurrió: localizar documentos, revisar registros, comparar fechas, solicitar evidencias y tratar de vincular una determinada prueba con el control que debía demostrar.

Si esas relaciones se preservan desde el origen, parte de ese esfuerzo puede reducirse. Sin embargo, eso no elimina la necesidad de aseguramiento; modifica su foco.

El auditor deberá seguir analizando si los controles están bien diseñados, si la herramienta que genera la evidencia está correctamente configurada, si el pipeline puede eludirse, si las claves están adecuadamente protegidas, si la evidencia puede manipularse, si su alcance es suficiente y si el emisor merece el nivel de confianza exigido.

Por ello, la automatización puede reducir el coste de recopilar evidencia, pero no elimina la necesidad de valorar su calidad. Incluso puede desplazar parte del trabajo de auditoría desde el documento hacia la arquitectura que genera, relaciona, protege y actualiza esa evidencia.

Este cambio es importante porque introduce una perspectiva más cercana al aseguramiento continuo, aunque conviene evitar identificar automáticamente verificación continua con continuous assurance. La disponibilidad permanente de evidencia puede facilitar modelos de aseguramiento más dinámicos, pero la conclusión sobre suficiencia y confianza sigue requiriendo criterios, responsabilidades y, en determinados casos, independencia.

Evidencia procesable y Cyber Resilience Act

La relación con el Cyber Resilience Act debe analizarse con especial prudencia.

Las atestaciones procesables pueden contribuir a mejorar la trazabilidad de controles, resultados de pruebas, componentes, vulnerabilidades o decisiones de diseño. También pueden aportar elementos útiles para mantener actualizada la documentación técnica.

Sin embargo, una atestación no sustituye las obligaciones jurídicas del fabricante.

La conformidad con el Reglamento (UE) 2024/2847 exige identificar y evaluar los riesgos de ciberseguridad, determinar qué requisitos esenciales resultan aplicables, demostrar su cumplimiento, elaborar y mantener la documentación técnica correspondiente y seguir el procedimiento de evaluación de conformidad que resulte procedente.

Por ello, la formulación más correcta sería:

Una atestación procesable puede aportar elementos útiles para la documentación técnica y para la trazabilidad de las medidas adoptadas, pero no sustituye la evaluación de riesgos, la determinación de los requisitos aplicables, el procedimiento de evaluación de conformidad ni la declaración UE de conformidad.

La evidencia técnicamente verificable y la conformidad jurídica pueden relacionarse, pero no son equivalentes.

La seguridad demostrable como capacidad de justificar decisiones

Después de analizar atestaciones, firmas, SBOM, SLSA, OSCAL, pipelines y evidencia estructurada, conviene volver a la cuestión fundamental.

Ninguno de estos mecanismos puede demostrar que un producto está absolutamente libre de riesgo, ni ese debería ser el objetivo.

Lo que sí pueden mejorar es la capacidad de una organización para explicar qué sabía cuando tomó una decisión, qué afirmaciones realizó, qué pruebas ejecutó, qué evidencia tenía disponible, qué limitaciones conocía, qué riesgos permanecían abiertos y bajo qué condiciones debía revisarse la decisión.

Desde esta perspectiva, la seguridad demostrable no consiste en eliminar la incertidumbre, sino en gobernarla mejor.

La seguridad demostrable no consiste en convertir una afirmación firmada en una verdad ni en eliminar el riesgo. Consiste en poder justificar, de manera trazable y verificable, qué se sabía, qué se comprobó, qué evidencia respaldaba cada afirmación, qué incertidumbres permanecían y por qué la decisión adoptada resultaba razonable en ese momento.

Los tres artículos de esta serie describen, en realidad, un mismo proceso de maduración. El primero situaba la seguridad dentro de la arquitectura y de las decisiones de diseño. El segundo llevaba los controles y las evidencias hasta el momento de la liberación. Este tercero añade una nueva dimensión: determinadas afirmaciones y evidencias pueden empezar a estructurarse de manera que otros sistemas puedan interpretarlas, verificarlas y reutilizarlas.

La evolución puede resumirse como un recorrido continuo:

diseñar → implementar → demostrar → estructurar → verificar → decidir → revisar

No estamos ante la sustitución del juicio humano por decisiones automáticas, sino ante la posibilidad de construir sistemas en los que tanto las personas como las herramientas puedan tomar decisiones sobre una base probatoria mejor relacionada, más actualizada y más fácil de verificar.

La cuestión que queda abierta es, por ello, menos tecnológica de lo que puede parecer:

¿Estamos preparados para pasar de organizaciones que documentan su seguridad a organizaciones capaces de gobernar evidencia suficientemente fiable como para sostener, explicar y revisar sus decisiones de seguridad?

Bibliografía

ENISA, Secure by Design and Default Playbook: A Practical Guide to Secure by Design and Default Principles for SMEs, versión 1.0, 30 de julio de 2026.
ENISA Secure by Design and Default Playbook ENISA

Unión Europea, Reglamento (UE) 2024/2847 del Parlamento Europeo y del Consejo, de 23 de octubre de 2024, relativo a los requisitos horizontales de ciberseguridad para los productos con elementos digitales, Cyber Resilience Act.
Reglamento (UE) 2024/2847 — EUR-Lex Eur-Lex

NIST, Open Security Controls Assessment Language (OSCAL). National Institute of Standards and Technology.
NIST OSCAL pages.nist.gov

OWASP CycloneDX, CycloneDX Attestations (CDXA).
CycloneDX Attestations cyclonedx.org

OWASP CycloneDX, Authoritative Guide to Attestations, First Edition, 9 de abril de 2024.
Authoritative Guide to Attestations cyclonedx.org

SPDX, SPDX Specifications. Linux Foundation. La versión 3.0 incorpora perfiles específicos, entre ellos el perfil de seguridad.
SPDX Specifications spdx.dev

SPDX, Security Profile. Información estructurada sobre vulnerabilidades, severidad, impacto y disponibilidad de correcciones.
SPDX Security Profile spdx.dev

SLSA, SLSA Specification, version 1.2. Especificación sobre seguridad de la cadena de suministro y niveles de garantías crecientes.
SLSA Specification v1.2 SLSA

SLSA, Provenance, version 1.2. Especificación para información verificable sobre dónde, cuándo y cómo se produjo un artefacto.
SLSA Provenance v1.2 SLSA

in-toto, in-toto: A framework to secure the integrity of software supply chains.
in-toto

Sigstore, In-Toto Attestations — Cosign. Documentación sobre creación, firma y verificación de atestaciones in-toto mediante Cosign.
Sigstore Cosign — In-Toto Attestations Sigstore

SPDX, Capturing Software Vulnerability Data in SPDX 3.0, 6 de noviembre de 2023.
Capturing Software Vulnerability Data in SPDX 3.0 spdx.dev

SLSA, Build: Distributing Provenance, versión 1.2. Documento sobre distribución y verificación de metadatos de procedencia y su relación con los artefactos construidos.
SLSA — Distributing Provenance

Autor y responsable editorial: Leocadio Marrero Trujillo.
El enfoque, la arquitectura, los criterios de análisis y las conclusiones de este artículo han sido definidos y validados por el autor. Durante su elaboración se han utilizado herramientas de inteligencia artificial generativa como apoyo para la estructuración, reformulación, edición y creación de determinados elementos gráficos.

El contenido ha sido sometido a revisión humana sustantiva, comprobación de fuentes y validación jurídica y técnica. El autor ha aprobado la versión definitiva y asume íntegramente la responsabilidad editorial sobre su contenido