-
Notifications
You must be signed in to change notification settings - Fork 7
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
Update to latest OSCAL and define maintenance and sync process #35
Comments
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. |
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"? |
Right now yes the CSV is the system of record. I am open to this changing. It was a simple place to start |
Without another interface... CSV may be the human readable form 🤔 |
controls-catalog/csv_to_oscal.py
Line 81 in 641bf45
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
The text was updated successfully, but these errors were encountered: