Update to latest OSCAL and define maintenance and sync process

[sunstonesecure-robert]

controls-catalog/csv_to_oscal.py

Line 81 in 641bf45

oscal_version="1.0.4",

ATM this is now OSCAL 1.1.2 but probably by the time this gets going this will change. So a second aspect of this is how to maintain ongoing updates to OSCAL - wait for GHIs to be filed by users? or add version-specific scripts to find breakages? both? neither?

Also this is a good community volunteer item for wg-compliance to recruit help

[JonZeolla]

Right now we don't have any compatibility guarantees, so I would lean towards updating as volunteers have time to complete the work, but if there are valid use cases to support multiple we could also consider parametrization and adding a matrix of supported versions to the pipeline.

[brandtkeller]

Is there an expectation that the CSV file is always the source of truth?

Contemplating tooling to support CSV to OSCAL (and reverse use-cases) more generically but much of the reason for using OSCAL is the defined format for data vs CSV being arbitrary (without some standard in place).

I'd be willing to prototype some implementations and workflows around generation and maintenance - as well as possibly some stances (IE many versions of OSCAL vs updating to latest).

What is meant by "sync process"?

[JonZeolla]

Right now yes the CSV is the system of record. I am open to this changing. It was a simple place to start

[brandtkeller]

Without another interface... CSV may be the human readable form 🤔