Define the tooling that should be used by the group / open source community?

[mcleo-d]

Due date : 15th December 2023

This GitHub issues represents part of the roadmap defined by the OSCAL working group on #13

Tasks

Beta Give feedback

1. Define the tooling that should be used by the group / open source community?
2. Should OSCAL be written by hand?
3. How are the services described as OSCAL?
4. Are there any editorial tools that enable automation of OSCAL?
5. How should contributions be validated and accepted?
6. Maybe other collaboration and editing solutions are better for the team?

[robmoffat]

@iMichaela having an OSCAL tool to help with formatting would be useful in the long run. Simple examples can be easily written by hand, but this becomes problematic after a certain size.

@eddie-knight have we made clear the project's vision for OSCAL?

@iMichaela without tooling people are likely to become lost.

@eddie-knight It might be good to extract this from the white paper so that it's easy to read + absorb.

@iMichaela (the white paper) doesn't give a clear example of how the controls work yet. Once you have the controls in a catalog, each component can show how they implement those controls.

Various tools for styling / displaying OSCAL in a human-friendly way.

[robmoffat]

https://github.com/oscal-club/awesome-oscal

[robmoffat]

See also: https://oscal-compass.github.io/compliance-trestle/

[robmoffat]

Related:

• Define which cloud service providers are accepting the initial OSCAL definitions  #45

[crawfordchanel]

Closing: Mapped with issue #45