1.0.0
After evaluating the original Compliance Masonry for a few months we've uncovered a few pain points:
- Setup - Compliance Masonry is difficult to set up due to Python 2 v 3 issues and Windows compatibility. Go can be compiled so users don't have to build from source.
- Encoding errors in Python 2, the script can be unwieldy due to Python utf-8 encoding errors.
- Size, in order to solve installation issues we've dockerized Compliance Masonry, but the size of the docker images is quite large. Go would be smaller.
- Too inflexible: currently application developers have to either fork or reproduce the docs in opencontrols format. There should be a way to "import" documentation and also "compile" docs from multiple sources.
New Direction
Configuration VS Code
All opencontrols docs will be stored in components.yaml files. The organization for these files will not change from the older version found here. There will be, however, an opencontrols.yaml, which helps users define dependencies and define exportable "modules".
system_name: Application
components: # Components that can be exported
- ./somecomponent
- ./someothercomponent
dependencies: # Dependencies to import
certification: github.com/18F/LATO #LATO Certifications
components:
- github.com/18F/cg-complinace # Cloud.Gov
standards:
- standard: github.com/18F/NIST-800-53 # NIST-800-53 standardsThe opencontrols.yaml will serve as a packages.json file for node. Essentially the file allows for configuration, while the component.yaml files are for the actual code/documentation. Also, components, standards, and certifications that are imported will live in the opencontrols/ directory just like imports from npm live in the node_modules/ directory.
Import Model
Systems are amalgams of components and pointers to other components.
Versioning
The opencontrols.yaml will allow for versioning of all dependencies using github's versioning feature.
Go
Go can be cross-compiled, is great for CLI tooling, and struct feature is perfect for validation.