This is the third post of the GoComply series that introduces open source pipeline to produce and process OSCAL and FedRAMP documents. If You want to achieve continuous compliance at the lowest possible cost, GoComply project is here to help. With GoComply, You will rely on open source tooling and your data will be stored in standardized formats and thus you will have a enough head room and knee room to achieve your organizational goals.

Introduction to oscalkit

oscalkit is open source implementation of OSCAL (the language). GoComply/oscalkit is written in Go language and currently provides SDK and command-line tool. The SDK contains complete set of OSCAL models, XML and JSON parsers and marshalers, and various helper methods. The command line interface provides basic operations as info, validate and diff providing OpenSCAP-like information about OSCAL document, validate the document against the schema file and provide semantic comparison of two OSCAL documents.

You can get hands on the command-line interface quickly by running:

 podman run -it quay.io/gocomply/gocomply

Little bit of history

The oscalkit project was started by Docker, Inc. early after introduction of the OSCAL language at NIST. Unfortunately, oscalkit development slowed down after March 2019. At that time OSCAL (the language) took several incompatible changes, rendering all the prior oscalkit work obsolete.

I join the project about a year later and started effort to revive it. I have forked the project under the GoComply organization and rewrote various parts from scratch. You can still find original pieces of the project in the repository, unfortunately these pieces do not support the latest OSCAL and hence can be used barely as developer reference.

Developers: SDK Design patterns

Full Go Reference manual can be found at pkg.go.dev.

Important concepts to recognize are OSCALSource and OSCAL struct. The former is a flexible abstraction to manipulate OSCAL documents, it is heavily inspirited by design of oscap_source from OpenSCAP project. The latter is union like structure (Go lacks proper unions) that parses and holds the document.

Developers: OSCAL use of UUIDs

OSCAL language makes a heavy use of UUIDs on various elements within a document. Good example to look at would be FedRAMP High OSCAL SSP for OpenShift 4, in the file we can locate multiple occurrences of uuid= attribute and cross references between those.

This pattern is supposed to help whoever post-processes OSCAL documents from various sources that cross-reference each other. For instance OSCAL Profile or OSCAL SSP may refer to items in OSCAL Catalog, OSCAL PoA&M may refer to OSCAL Assessment Results, etc. If there was only one version of a each document there wouldn’t be a need for UUIDs. Since many versions of each document are to be expected, UUIDs are supposed to help connect pieces of information together and avoid confusion.

OSCAL requires use of Version 4 UUID as defined by RFC 4122. However, OSCAL allows for UUID to not change across the document revisions if the content of the element does not change materially. This presents certain challenge to whoever produces the OSCAL content as they have to always have the previous version of the content available around to check for the material differences within elements.

To help the content authors with this challenge, oscalkit tool is able to generate stable UUIDs for the elements that are exactly the same. This is achieved by hashing the element contents internally and producing UUID from the hash.

Conclusion

oscalkit is more of SDK and library than stand-alone tool at this point. The best way for an end user to benefit from oscalkit is to use GoComply/fedramp that integrates GoComply/oscalkit with opencontrol and official FedRAMP assets.