Compendium

Government / Civic-Tech / Cyber-Compliance DSLs Family Index

13 min read

Government / Civic-Tech / Cyber-Compliance DSLs Family Index

type: language-family-index family: government-civictech languages_catalogued: 30 tags: [language-reference, family-index, government-civictech, akoma-ntoso, oscal, stix-taxii, csaf, sbom, sigma, mitre-attack, dcat]

Government / Civic-Tech / Cyber-Compliance — Family Index

Family overview

This family covers the textual languages used by governments, regulators, and the security community to encode legislation, exchange threat intelligence, attest software supply chains, and publish open data. None of these are general-purpose programming languages — they are domain-specific schemas, vocabularies, and rule formats, almost all serialised in XML, JSON, YAML, or RDF, and almost all the product of an international standards body (OASIS, NIST, W3C, OWASP, Linux Foundation, MITRE) under heavy regulatory pressure. The defining tension across the family is machine-readability vs. legal-text fidelity: a statute, a security advisory, and an SBOM all exist as authoritative human-readable artifacts that must also round-trip through automated pipelines, and the schemas in this family encode the painful compromises that result.

The legislative-XML lineage anchors one end. Akoma Ntoso (OASIS LegalDocML 1.0, 2018) grew out of the UN-DESA “Africa i-Parliaments” programme in the mid-2000s and is now the legislative format of choice for the European Parliament, the UK Parliament, the German Bundestag, the Brazilian Senate, the Italian Senate, Kenya, Uganda, and the Hague-based international tribunals. LegalRuleML adds rule modelling on top (OASIS, 2021), CEN MetaLex provides a higher interoperability shim, and the US House and Senate publish their own USLM schema as a parallel evolution. EU ELI (European Legislation Identifier) and ECLI (European Case Law Identifier) provide the URI layer that lets these documents reference each other across borders.

The cyber-threat-intelligence ecosystem is the most active subfamily by velocity. STIX 2.1 + TAXII 2.1 (OASIS, June 2021) are the de facto standards for representing and exchanging structured threat intelligence; MISP (community, current major v2.5.x in 2026) is the dominant open-source platform that both consumes and produces STIX. MITRE’s knowledge bases (ATT&CK currently at v19 as of April 2026, plus CWE, CAPEC, D3FEND) provide the taxonomies everyone else maps onto. The detection-rule layer — Sigma (vendor-neutral YAML), YARA (file/memory pattern matching), and Google Chronicle’s YARA-L — sits on top, with Sigma in particular growing rapidly as the SIEM-portability standard. CSAF 2.0 (OASIS Recommendation 2022, approved as ISO/IEC 20153 in May 2025) and the various VEX flavours (CSAF-VEX, CycloneDX-VEX, OpenVEX) cover vendor advisories; CSAF 2.1 is in OASIS Committee Specification Draft as of 2026.

The SBOM and compliance subfamily is the youngest and most regulation-driven. US Executive Order 14028 (May 2021) and the EU Cyber Resilience Act (in force 2024, full applicability 2027) effectively turned SBOM from a nice-to-have into a procurement gate. SPDX 3.0 (Linux Foundation, April 2024; current minor 3.0.1) and CycloneDX 1.6 (OWASP, April 2024, now an ECMA standard as ECMA-424) split the field — SPDX dominant in upstream Linux distribution and license-compliance workflows, CycloneDX dominant in application-security and CI/CD tooling. NIST OSCAL (currently 1.1.3) is the parallel machine-readable language for the controls side of compliance — turning NIST 800-53, 800-171, FedRAMP baselines, and ISO 27001 mappings into JSON/XML/YAML that GRC platforms can ingest. The open-data side — W3C DCAT 3 (2024) + DCAT-AP 3.0.1 (EU SEMIC, 2024), SDMX (UN/IMF/ECB statistical exchange), Frictionless Data tabular packages, and CKAN — does the same thing for public datasets that OSCAL does for controls and SBOMs do for software. Across all of these, the political driver is the same: regulators want machine-checkable artifacts, not PDFs.

In our deep library

None catalogued. These are all schema-and-vocabulary DSLs that sit on top of XML, JSON, YAML, or RDF host serialisations and do not have standalone deep-library notes.

Cross-reference:

  • identity-auth-policy — OSCAL and STIX both touch the policy-and-access-control DSL family (OSCAL profiles overlap with policy authoring; threat intel feeds into policy engines).
  • citation-formats — ELI / ECLI legal-document URIs are the legal-citation cousin of BibTeX, CSL, and OpenCitations.
  • api-description — TAXII 2.1 is a REST API (OpenAPI-describable), and CSAF/STIX feeds are typically distributed via HTTP APIs.
  • network-protocol-dsls — YARA and Sigma sit at the boundary; YARA matches file/memory patterns, Sigma matches log events, and the closely-related Snort/Suricata rule languages live in the network-protocol family.
  • notation-spec — LegalRuleML and the formal-grammar side of legislative drafting are adjacent to formal-specification notations.
  • financial-regulatory — XBRL, FIX, SDMX, and the various financial-regulatory reporting DSLs share the “regulator-mandated machine-readable filings” pattern.
  • build-devops — SBOM generation (CycloneDX, SPDX) is now a CI/CD pipeline step in essentially every regulated build, with cdxgen, Syft, and Trivy as the dominant generators.
  • healthcare-clinical — HL7 FHIR and the healthcare-regulatory family share the “OASIS/HL7 government-mandated XML/JSON exchange” pattern.

Tier 3 family table — Legislative & legal documents

FormatFirst appearedOriginTypeStatus (2026)URL
Akoma Ntoso (OASIS LegalDocML)2004 (UN-DESA Africa i-Parliaments), 1.0 OASIS Standard 2018-08-29Monica Palmirani, Fabio Vitali, Grant Vergottini, Roger SperbergXML vocabulary for parliamentary, legislative, and judicial documentsActive; 1.0 is the current OASIS Standard; widely used across EU + Africa + Latin Americahttps://docs.oasis-open.org/legaldocml/akn-core/v1.0/akn-core-v1.0-part1-vocabulary.html
LegalRuleML2012 first OASIS draft, 1.0 OASIS Standard 2021OASIS LegalRuleML TC (Palmirani et al.)XML rule-modelling layer on top of legal documents (deontic logic, defeasibility)Active, niche academic + EU pilot usagehttps://docs.oasis-open.org/legalruleml/legalruleml-core-spec/v1.0/os/legalruleml-core-spec-v1.0-os.html
CEN MetaLex2010 (CEN Workshop Agreement)CEN (European Committee for Standardization), Hoekstra/Boer/WinkelsXML “interoperability layer” above national legal-doc XML schemasLegacy, mostly superseded by Akoma Ntoso in EU usagehttps://www.metalex.eu/
USLM (United States Legislative Markup)2013US House Office of the Law Revision CounselXML schema for US Code, House, and Senate billsActive; xml.house.gov publishes bills natively in USLMhttps://github.com/usgpo/uslm
NIEM / NIEMOpen2005 (DOJ + DHS), NIEMOpen transition to OASIS 2023, v6.0 in progress under NIEMOpenUS DOJ + DHS, transitioned to OASIS NIEMOpen TC in 2023, community-run since Oct 2025XML (and JSON) data-exchange model for US federal/state/local agenciesActive; NIEMOpen 6.0 in development with new forensics + analytical-lab domainshttps://niemopen.org/
EU ELI (European Legislation Identifier)2012 (Council conclusions)EU Publications OfficeURI scheme + metadata vocabulary for legislationActive; mandatory for EU institutions, widely adopted in member stateshttps://eur-lex.europa.eu/eli-register/about.html
ECLI (European Case Law Identifier)2011 (Council conclusions)EU Council + Publications OfficeURI scheme for case law citations across EU member statesActivehttps://e-justice.europa.eu/175/EN/european_case_law_identifier_ecli
PolicyML / Pol-D2010s researchAcademic (LegalRuleML adjacent)Research-only DSLs for policy modellingMarginalhttps://www.oasis-open.org/committees/legalruleml/

Tier 3 family table — Cyber threat intelligence

FormatFirst appearedOriginTypeStatus (2026)URL
STIX 2.12014 (STIX 1.0 MITRE), 2.0 in 2017, 2.1 OASIS Standard 2021-06-10MITRE → OASIS CTI TCJSON serialisation of cyber threat intel (SDOs, SROs, SCOs)Active; 2.1 is the current OASIS Standardhttps://docs.oasis-open.org/cti/stix/v2.1/os/stix-v2.1-os.html
TAXII 2.12013 (TAXII 1.0), 2.1 OASIS Standard 2021-06-10MITRE → OASIS CTI TCREST/HTTPS application-layer protocol for STIX exchangeActive; 2.1 is the current OASIS Standardhttps://docs.oasis-open.org/cti/taxii/v2.1/os/taxii-v2.1-os.html
MISP core format2011CIRCL (Luxembourg) + MISP communityJSON event/attribute format for community-driven threat-intel sharingVery active; current v2.5.37 (May 2026), introduces redesigned Event Templating; STIX 2 export via misp-stixhttps://www.misp-project.org/
OpenIOC2011Mandiant (now Google Cloud)XML format for indicators of compromiseLegacy, largely superseded by STIX 2.xhttps://github.com/mandiant/OpenIOC_1.1
MITRE ATT&CK2013 (internal), public 2015MITRE (PRE-, Enterprise, Mobile, ICS matrices)JSON taxonomy of adversary tactics/techniques/proceduresVery active; current v19 (April 2026); v19 split Defense Evasion into Stealth + Defense Impairmenthttps://attack.mitre.org/
MITRE D3FEND2021MITRERDF/OWL knowledge graph of defensive countermeasures, paired with ATT&CKActivehttps://d3fend.mitre.org/
MITRE CWE (Common Weakness Enumeration)2006MITREXML weakness catalogue (CWE-79, CWE-89, etc.)Activehttps://cwe.mitre.org/
MITRE CAPEC (Common Attack Pattern Enumeration and Classification)2007MITREXML attack-pattern catalogue, paired with CWEActivehttps://capec.mitre.org/

Tier 3 family table — Compliance frameworks & SBOM

FormatFirst appearedOriginTypeStatus (2026)URL
OSCAL (Open Security Controls Assessment Language)2017 prototype, 1.0.0 GA 2021NISTJSON / XML / YAML for controls, profiles, components, assessments, SSPs, POA&MsActive; current 1.1.3; FedRAMP automation backbonehttps://pages.nist.gov/OSCAL/
CSAF 2.0 (Common Security Advisory Framework)2017 (CSAF 1.x continuation of CVRF), CSAF 2.0 OASIS Recommendation 2022-11OASIS CSAF TCJSON for vendor security advisories; integrates SBOM + VEX profileActive; ISO/IEC 20153 since May 2025; CSAF 2.1 in CSD01 (2026)https://docs.oasis-open.org/csaf/csaf/v2.0/os/csaf-v2.0-os.html
CSAF VEX profile2022 (within CSAF 2.0)OASIS CSAF TCVEX statements embedded in a CSAF advisoryActivehttps://docs.oasis-open.org/csaf/csaf/v2.0/os/csaf-v2.0-os.html#45-profile-5-vex
OpenVEX2023OpenSSF (with Chainguard)Minimal JSON-LD standalone VEX formatActivehttps://github.com/openvex/spec
CycloneDX VEX2022 (within CycloneDX 1.4+)OWASP CycloneDX projectVEX statements embedded in or decoupled from a CycloneDX SBOMActivehttps://cyclonedx.org/capabilities/vex/
CycloneDX2017 (1.0)OWASPXML / JSON / Protobuf BOM standard; SBOM, SaaSBOM, HBOM, ML-BOM, CBOMActive; 1.6 current (April 2024); standardised as ECMA-424https://cyclonedx.org/
SPDX2010 (1.0), 2.x series 2011–2022, 3.0 April 2024Linux FoundationRDF / JSON-LD / tag-value / YAML SBOM standard; ISO/IEC 5962:2021 (for 2.2.1)Active; current 3.0.1; 3.0 was a major remodel (profiles + namespace-based model)https://spdx.dev/
OpenChain (ISO/IEC 5230)2016 founded, ISO/IEC 5230:2020Linux Foundation OpenChain ProjectSupply-chain license-compliance process standard; uses SPDX/CycloneDX as dataActivehttps://www.openchainproject.org/

Tier 3 family table — Open government data

FormatFirst appearedOriginTypeStatus (2026)URL
W3C DCAT (Data Catalog Vocabulary)2014 (DCAT 1), DCAT 2 in 2020, DCAT 3 W3C Recommendation 2024-08W3C Dataset Exchange WGRDF vocabulary for describing datasets and data services in cataloguesActive; DCAT 3 adds Dataset Series + versioninghttps://www.w3.org/TR/vocab-dcat-3/
DCAT-AP (Application Profile)2015 (1.0)European Commission SEMICEU profile of W3C DCAT for open-government-data portalsActive; 3.0.1 current, aligned with DCAT 3https://semiceu.github.io/DCAT-AP/releases/3.0.1/
SDMX (Statistical Data and Metadata eXchange)2001 founded, 1.0 in 2004, 3.0 in 2022BIS, ECB, Eurostat, IMF, OECD, UN, World BankXML / JSON statistical data + metadata exchangeActive; ISO 17369:2013 (for 2.1); SDMX 3.0 widely adopted by central bankshttps://sdmx.org/
Frictionless Data — Tabular Data Package2016Open Knowledge FoundationJSON schema for tabular datasets (datapackage.json + table-schema)Activehttps://frictionlessdata.io/
CKAN package format2007Open Knowledge FoundationJSON metadata model used by the dominant open-data portal softwareActivehttps://docs.ckan.org/en/latest/api/
OSCRE (Open Standards Consortium for Real Estate)2002OSCRE InternationalXML / JSON data standards for real-estate transactions (gov + private)Activehttps://www.oscre.org/

Tier 3 family table — Detection & adversary modelling

FormatFirst appearedOriginTypeStatus (2026)URL
YARA2007Victor Alvarez (VirusTotal, then Google)DSL for malware classification via byte/string/regex pattern matchingVery active (network-protocol-dsls sibling)https://yara.readthedocs.io/
YARA-L2020Google ChronicleYARA-inspired DSL adapted for log/event detection in Chronicle SIEMActive (vendor-specific)https://cloud.google.com/chronicle/docs/detection/yara-l-2-overview
Sigma2017Florian Roth + Thomas PatzkeVendor-neutral YAML detection-rule language; converts to 25+ SIEM backends via pySigmaVery active; the de facto SIEM portability standard; pySigma 3.x (2026)https://sigmahq.io/
OSQuery configuration2014 (Facebook)Facebook (now Meta) → Linux Foundation osquery projectJSON configuration + SQL-as-DSL for endpoint queryingActivehttps://osquery.readthedocs.io/

Notable threads

  • Akoma Ntoso’s reach is now genuinely global. Originally an Africa-focused UN-DESA project in the mid-2000s, Akoma Ntoso passed through the African Union, the Inter-Parliamentary Union, and the Italian Senate’s “Normattiva” portal before becoming an OASIS Standard in 2018. As of 2026 it is the legislative format used by the European Parliament’s EUR-Lex (via AKN4EU), the UK Parliament, the German Bundestag, the Brazilian, Chilean, and Italian Senates, multiple African parliaments (Kenya, Uganda, South Africa drafts), and several international tribunals at The Hague. The US is the major holdout — USLM is a parallel evolution from the House Office of the Law Revision Counsel that solves the same problem with overlapping but incompatible vocabulary. Cross-walking USLM ⇄ Akoma Ntoso is an active area of work but no production tool fully bridges them.

  • STIX 2.1 + TAXII 2.1 are the de facto threat-intel exchange standards, with MISP as the open-source default. The 2021 OASIS Standard publication of STIX/TAXII 2.1 effectively closed the “format wars” of the 2010s (STIX 1.x XML vs. OpenIOC vs. CybOX vs. proprietary feeds). What’s left is implementation drift: MISP has its own native JSON format and exports to STIX 2.1 via the misp-stix library, CrowdStrike and Mandiant produce STIX-shaped JSON with vendor extensions, and US CISA’s Automated Indicator Sharing (AIS) feed normalises everything to TAXII 2.1. The hardest part of STIX 2.1 in practice is the relationship model — SROs (Sighted-by, Indicates, Attributed-to) carry the analytical value, and most producers undersupply them.

  • CSAF 2.0 / VEX is the modern vendor-advisory format, and the ISO stamp in May 2025 is what tipped the procurement scale. CSAF 2.0 displaced its predecessor CVRF (Common Vulnerability Reporting Framework) because CVRF was XML-only and pre-SBOM. The major shift in 2024–2025 was government and large-enterprise procurement: CISA mandated CSAF 2.0 for ICS advisories starting late 2024, the US Department of Defense added it to procurement guidance in 2025, and ISO/IEC 20153 (the ISO form of CSAF 2.0) approved in May 2025 made it the international standard. CSAF 2.1, currently in OASIS Committee Specification Draft, tightens the VEX profile, adds a CSAF-VEX-only document type, and improves the relationship model with SBOMs.

  • SBOM mandate convergence: SPDX vs. CycloneDX in practice. US Executive Order 14028 (May 2021) directed NIST and NTIA to define minimum SBOM elements; the result was a “format-neutral” minimum that accepts SPDX, CycloneDX, or SWID. The EU Cyber Resilience Act (in force 2024) similarly accepts both. In practice the field has bifurcated by ecosystem: SPDX dominates upstream Linux distribution work, kernel licence compliance, and the FOSSology / ScanCode toolchain, because SPDX’s licence-expression DSL (SPDX-License-Identifier:) was the original 2010 reason the standard existed. CycloneDX dominates application security, Kubernetes / cloud-native CI/CD (Trivy, Syft → CycloneDX by default), and now extends to SaaSBOM, HBOM (hardware), CBOM (cryptographic — the IBM-led 1.6 addition), and ML-BOM. CycloneDX 1.6’s elevation to ECMA-424 in 2024 was a deliberate move to give it standards parity with SPDX’s ISO/IEC 5962:2021.

  • NIST OSCAL is the FedRAMP automation backbone, even if adoption outside .gov is slower. OSCAL solves a different problem from SBOMs: not “what’s in this software” but “what controls apply, in which baseline, with which assessments, on which components, with which open POA&M items.” The catalogue + profile + SSP + component-definition + assessment-plan + assessment-results + POA&M layered model maps directly onto the FedRAMP authorisation lifecycle. As of 2026 (OSCAL 1.1.3), FedRAMP is OSCAL-mandatory for new authorisations, and StateRAMP, DoD CMMC 2.0, and HHS HIPAA Security Rule assessments increasingly accept OSCAL packages. GRC vendors (Drata, Vanta, Tugboat, RegScale) all expose OSCAL import/export.

  • Sigma’s rapid rise as the vendor-neutral detection-rule lingua franca. Sigma (2017, Florian Roth + Thomas Patzke) solved the “write once, detect everywhere” problem for log-based detections that Snort/Suricata solved for network detections. By 2026 Sigma rules can be converted via pySigma 3.x to Splunk SPL, Elastic ESQL/EQL, Microsoft Sentinel KQL, Chronicle YARA-L, QRadar AQL, CrowdStrike Falcon LogScale, Sumo Logic, Devo, and ~20 more backends, with the SigmaHQ GitHub repository carrying 3000+ public rules. The interesting tension is between Sigma’s vendor-neutral YAML and per-SIEM idiomatic queries — pySigma’s pipeline backends accept that a Sigma rule has to be tuned per backend rather than mechanically translated, which is a pragmatic concession to the reality that no SIEM has identical field semantics.

  • DCAT-AP as the EU open-government-data backbone, and the W3C DCAT 3 re-alignment. The European Commission’s SEMIC programme has shipped DCAT-AP since 2015 as the application profile that EU member states use for their open-data portals (data.europa.eu federates ~50 national + regional catalogues). W3C DCAT 3 (Recommendation 2024-08) introduced the Dataset Series concept and a versioning vocabulary, and DCAT-AP 3.0.1 (2024) realigned the EU profile to match. The deeper pattern: every government open-data initiative — US data.gov, UK data.gov.uk, EU data.europa.eu, Australia data.gov.au — has converged on DCAT-shaped metadata, with CKAN as the dominant software backend and Frictionless Data tabular-package schemas as the row-level dataset descriptor.

Citations

Graph View