OSCAL: Frameworks as Code

ISO 27001, NIS2, DORA, CRA, AI Act, BSI C5, PCI DSS — cada marco se publica en su propio formato, su propio idioma y su propio esquema de numeración. Los equipos leen extensos PDF a mano, las hojas de cálculo mapean marco contra marco celda a celda y, con cada nueva versión, el trabajo empieza de cero. Los documentos no interoperan: cada correspondencia es pegamento humano. Al mismo tiempo, los propios supervisores exigen ya datos estructurados: el registro de información de DORA sobre terceros proveedores de servicios TIC debe presentarse anualmente desde 2025 en formato xBRL-CSV. El cumplimiento como pila de documentos ya no escala — ni para las empresas ni para los auditores.

La Open Security Controls Assessment Language es un estándar del NIST abierto y neutral respecto a fabricantes, desarrollado junto con la industria y mantenido abiertamente en GitHub. Nació de un dolor concreto: los paquetes de autorización, como los de FedRAMP, eran voluminosas pilas de documentos que ninguna máquina podía verificar. Desde la primera versión estable 1.0.0, del 7 de junio de 2021, el estándar evoluciona de forma continua — la versión actual es la 1.2.3, del 7 de agosto de 2026. Cada modelo existe de forma equivalente en JSON, XML y YAML, convertible entre formatos, definido mediante el framework Metaschema del NIST, que genera esquemas, conversores y documentación desde una única fuente. La esencia en una frase: un framework se convierte en datos en lugar de PDF — las mismas palabras, ahora direccionables y consultables.

OSCAL organiza el cumplimiento en tres capas: la Control Layer describe qué dice un framework (Catalog), qué partes se seleccionan y adaptan (Profile) y — desde la versión 1.2.0 — cómo se relacionan los frameworks entre sí (Control Mapping). La Implementation Layer describe cómo los sistemas implementan los controles (Component Definition, System Security Plan). La Assessment Layer describe cómo se evalúa y qué se ha encontrado (Assessment Plan, Assessment Results, POA&M). El ejemplo público de referencia es FedRAMP: el catálogo SP 800-53 se recorta mediante un perfil de baseline, un SSP implementa la selección, los assessments verifican contra ella y el POA&M hace seguimiento de las brechas — cada paso referencia al anterior de forma legible por máquina. La misma cadena funciona para cualquier framework en cuanto existe un catálogo en forma de datos.

Un catálogo OSCAL refleja la estructura del documento fuente: los groups representan capítulos, dominios o artículos; los controls son los requisitos direccionables con ID estable; las parts contienen el texto literal — statement, guidance, objetivo de evaluación — referenciable de forma individual; los params convierten los huecos «organization-defined» de un framework en campos de datos rellenables; las props aportan etiquetas y ordenación; y en el back-matter puede residir el propio documento fuente, asegurado con hashes. Lo decisivo es la identidad estable: un control como «ac-1» sigue siendo la misma referencia a través de versiones y mappings — herramientas, perfiles y evidencias apuntan de forma permanente al mismo objeto en lugar de a un número de página.

Cinco propiedades imposibles con un PDF y triviales con datos: comparable — ¿qué ha cambiado exactamente entre dos versiones de un framework? Consultable — filtrar, contar, seleccionar y generar informes sobre todos los controles. Mapeable — relacionar controles entre frameworks: implementar una vez, cumplir varias veces. Trazable — cada elemento puede apuntar al pasaje exacto de la fuente de la que procede. Automatizable — las herramientas consumen los datos directamente, sin reintroducción manual y sin la deriva del copiar y pegar. Para los equipos de GRC esto significa: los cambios de versión se convierten en diffs en lugar de empezar de cero, las auditorías acceden a referencias verificables y el cumplimiento múltiple se convierte en una operación de datos.

El NIST publica SP 800-53 de forma nativa en OSCAL — actualmente la release 5.2.0, junto con los procedimientos de evaluación de SP 800-53A y las cuatro baselines. El motor de adopción más potente es FedRAMP: tras las fases piloto de 20x (26 y 14 presentaciones legibles por máquina), la decisión de marzo de 2026 obliga a más de 500 proveedores Rev5 existentes a entregar paquetes de autorización legibles por máquina o semiestructurados — con fecha límite el 1 de noviembre de 2027; en paralelo, el programa 20x sustituye la documentación narrativa por 46 Key Security Indicators verificables de forma automatizada. En el plano internacional, el Signals Directorate de Australia publica el ISM con perfiles de Essential Eight en OSCAL, GovTech (Singapur) adopta el estándar a escala gubernamental, CIS ofrece los Controls v8/v8.1 y la Cloud Security Alliance su CCM v4.1 en formato legible por máquina; AWS, según su propio anuncio, proporciona desde la primavera de 2026 sus informes SOC 1 y SOC 2 adicionalmente en OSCAL. Desde febrero de 2025, la OSCAL Foundation (con AWS y Cisco, entre otros, en su Steering Committee) aglutina a la comunidad; el proyecto de herramientas OSCAL Compass es CNCF Sandbox desde junio de 2024.

Desde el 30 de septiembre de 2025, el BSI ofrece su Stand-der-Technik-Bibliothek en GitHub — normativas legibles por máquina sobre base OSCAL, bajo licencia libre CC-BY-SA-4.0 y organizadas según las capas de OSCAL. El sucesor del IT-Grundschutz, Grundschutz++, nace OSCAL-first: unos 1.000 requisitos en 20 prácticas (build piloto a mediados de 2026), fase piloto hasta el 30 de septiembre de 2026, presentación oficial en la it-sa el 27 de octubre de 2026, y a partir de 2027 está prevista una certificación ISO 27001 sobre esta base. También el C5:2026 — 168 criterios en 17 áreas temáticas, alineado estructuralmente con el EUCS — está disponible por primera vez en formato legible por máquina. A escala de la UE, los proyectos Horizon MEDINA y EMERALD (Certification-as-a-Service, con duración hasta octubre de 2026) y la comunidad EUROSCAL impulsan el uso de OSCAL para la certificación cloud automatizada; en la ECSO se reunió por primera vez, en septiembre de 2025, una European OSCAL Task Force. Un límite honesto: para ISO 27001 no existe un catálogo oficial de libre distribución debido a los derechos de autor de ISO — ISO e IEC trabajan con la iniciativa SMART en sus propias normas legibles por máquina.

Con la versión 1.2.0, de diciembre de 2025, el modelo de Control Mapping se convirtió en el octavo modelo de OSCAL: las mapping-collections conectan catálogos o perfiles a nivel de control o incluso de statement — con seis tipos de relación basados en la teoría de conjuntos (equal-to, equivalent-to, subset-of, superset-of, intersects-with, no-relationship), justificación obligatoria (syntactic, semantic o functional según NIST IR 8477) y calificadores para coberturas parciales e incompatibilidades. Lo complementa el programa OLIR del NIST, con referencias oficiales de CSF 2.0 hacia ISO/IEC 27001, CIS Controls y PCI DSS, así como metaframeworks como el Secure Controls Framework, con más de 200 marcos mapeados según sus propios datos. La consecuencia práctica: quien debe cumplir a la vez NIS2, AI Act, ISO 27001, ISO 42001 y CRA consolida mediante mapping en un conjunto de controles interno — el análisis de brechas combinado se convierte en una consulta, y cinco proyectos de implementación pasan a ser uno. Algo sigue siendo esencial: los mappings rara vez son 1:1 — precisamente por eso el modelo exige tipo de relación y justificación, en lugar de equiparar controles de forma tácita.

En el modelo de Assessment Results, las propias evidencias se convierten en datos: los findings se vinculan mediante observations con referencias a evidencias, y los archivos de prueba residen como recursos de back-matter — enlazados y asegurados con hashes criptográficos o incrustados directamente. Esa es la base para assessments continuos, hasta llegar a conceptos de Continuous ATO como los que el Departamento de Defensa de EE. UU. definió en 2022 mediante un memorando. Para la cadena de suministro, la Component Definition es la clave: un proveedor de software o cloud describe una sola vez, de forma legible por máquina, cómo su producto soporta los controles — y los clientes importan ese bloque directamente en su System Security Plan, en lugar de responder el siguiente cuestionario. Las herramientas maduran: compliance-trestle gestiona OSCAL como código en pipelines de CI/CD, Compliance-to-Policy genera a partir de Component Definitions políticas nativas para Kyverno u Open Cluster Management y normaliza los resultados de verificación de vuelta a Assessment Results; de forma complementaria, CycloneDX 1.6 conecta con sus attestations el SBOM con la evidencia de cumplimiento. Seamos honestos: la complejidad del estándar es real — su valor surge cuando una plataforma la encapsula en lugar de trasladarla a los usuarios.