NIST OSCAL is a cybersecurity-artifact data specification language that provides a set of data schemas used.
The OSCAL data structures are versioned according to a "metaschema XML". This metaschema XML further defines the data structure across the JSON, YAML and XML implementation formats. i.e. the "Metaschema" is defined in XML, and this "Metaschema" dictates how the resulting "OSCAL JSON", "OSCAL YAML", and "OSCAL XML" data schema looks like.
These are the particulars about the OSCAL Metaschema:
- The metaschema is versioned, e.g. 1.0, 1.0.1, 1.0.4.
- The metaschema changes
- There are multiple metaschemas for OSCAL (Catalog, Assessment Plan, etc)
We need to generate the (Ruby) object accessors in the "oscal" gem, because:
-
Currently, the Ruby "oscal" gem implements only the "OSCAL Catalog" data schema at a particular version (one of the data schemas provided by the Metaschema). Once we have this, it means that we can support 1.0, 1.0.1, 1.0.4 etc versions in the same gem.
-
Allows us to use one implementation across all Metaschema versions. Users need to parse/build not only the latest version, but also older versions.
-
Allows the "oscal" Ruby gem to parse and build all the data schema objects across JSON, YAML and XML.
The relevant input to this task are:
The approach is:
- Use the
metaschema gem to parse the OSCAL Metaschema XML.
- For each data schema and each schema version, through meta-programming using the
lutaml-model gem, develop a set of classes based on lutaml-model. For example, a round-trip for Catalog version 1.0.4 is possible through Oscal::Catalog.version_class('1.0.4').parse(catalog_xml).to_xml.
We will need to reimplement the internals of the current gem because we need to generate the classes depending on the metaschema XML.
Let's first do the Catalog metaschema (with multiple metaschema versions):
The other metaschemas can be found at:
NIST OSCAL is a cybersecurity-artifact data specification language that provides a set of data schemas used.
The OSCAL data structures are versioned according to a "metaschema XML". This metaschema XML further defines the data structure across the JSON, YAML and XML implementation formats. i.e. the "Metaschema" is defined in XML, and this "Metaschema" dictates how the resulting "OSCAL JSON", "OSCAL YAML", and "OSCAL XML" data schema looks like.
These are the particulars about the OSCAL Metaschema:
We need to generate the (Ruby) object accessors in the "oscal" gem, because:
Currently, the Ruby "oscal" gem implements only the "OSCAL Catalog" data schema at a particular version (one of the data schemas provided by the Metaschema). Once we have this, it means that we can support 1.0, 1.0.1, 1.0.4 etc versions in the same gem.
Allows us to use one implementation across all Metaschema versions. Users need to parse/build not only the latest version, but also older versions.
Allows the "oscal" Ruby gem to parse and build all the data schema objects across JSON, YAML and XML.
The relevant input to this task are:
The approach is:
metaschemagem to parse the OSCAL Metaschema XML.lutaml-modelgem, develop a set of classes based on lutaml-model. For example, a round-trip for Catalog version 1.0.4 is possible throughOscal::Catalog.version_class('1.0.4').parse(catalog_xml).to_xml.We will need to reimplement the internals of the current gem because we need to generate the classes depending on the metaschema XML.
Let's first do the Catalog metaschema (with multiple metaschema versions):
The other metaschemas can be found at: