-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Utilize OSCAL "metaschema" for parsing OSCAL #18
Comments
Maybe we can bridge this using the Shale gem? @HassanAkbar |
@ronaldtse Sure, will look into it after finalizing |
Hey, I am working on this with a couple of others (for python) here: https://github.com/Credentive-Sec/metaschema-python I have some design notes and there are weekly calls with the metaschema team to talk about the challenges and discuss ideas. Let me know if you're interested in joining. The more the merrier! |
Instead of the Shale gem we are looking at our own lutaml-model gem which has superseded Shale. |
This task is now active. We will first move this to the https://github.com/lutaml/ org to continue. |
This task is now handled by @hasaniskandar |
The 'metaschema-python' library is now the 'metaschema-codegen' library, expressly for the purpose of supporting multiple programming languages as output. Very happy to have a chat with you all anytime to talk about where it is and how to make it produce ruby libraries as an output. |
Thanks @RS-Credentive for the tip! We'd be more than happy to contribute to the metaschema-codegen after we complete implementation. Our goal here is to handle all versions of the OSCAL metaschemas using the same Ruby library, since we're trying to help our users on the other side (Metanorma) to handle OSCAL as simply as possible. The other goal we have is to improve our schema handling library (lutaml-model), so it's just a process we need to work through. |
I'm happy to share any tips or information that I have gleaned, so feel free to ping me. I highly recommend joining the once a week metaschema calls on Friday at 1 PM Eastern. If your team would like to participate, I can forward the invitation or put you in touch with the organizers. It's hosted by the ex NIST/OSCAL now GSA/Fedramp team that is writing metaschema. |
@RS-Credentive Happy to join the call for this week! My email is [email protected] if you don't mind communicating the details separately. P.S. Is Michaela etc now with the new team? |
Michaela is still manning the ship at NIST. Dave and AJ are building a team at FedRAMP. |
Thank you @RS-Credentive ! |
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:
Oscal::Catalog::Version104.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:
The text was updated successfully, but these errors were encountered: