A couple of things to think about as we move towards the idea of Compliance As Code and acentral CLI/WebUI.1. We are moving away from authoring content in XML and towards a YAML style format which
was shown at Defense in Depth last year. Many people were smiling and liking the idea.
Even now, playing with YAML as the authoring language at DevConf has people smiling and
exclaiming how easy it is to use. There is no perfect format, but we have had too muchfeedback over the dislike of XML for authoring.
actually consume Inspec content..... or maybe it should. Also, just to be clear, SCAP formatsconsumed by the engine of your choice. Don't think that the OpenSCAP scanner should2. One guide authoring language to many outputs. In essence, the build system would consume
the YAML guides (migrated from XCCDF), Ansible, BASH, Inspec, OVAL (possibly migrating
writing this in YAML), etc. to output in DS, XCCDF, Ansible/Bash roles, Inspec, etc. to bewould still be generated as output for consuming in SCAP scanners.
3. DB would most likely be used for this central CLI/WebUI as a way to store, manipulate, and
potentially generate the data/content for SSPs, SCAP reports, etc.
OpenControl allows you to code and generate a SSP. What else could be an addon orcould be used in the future to solve security issues in the disconnected space? For example4. Think beyond a CM tool. That would just one potential component of this. What other tooling
integrated?