Replies: 5 comments
-
A folder called |
Beta Was this translation helpful? Give feedback.
-
@marcusburghardt Is this still valid? |
Beta Was this translation helpful? Give feedback.
-
The proposal is still valid but, I am only not sure if the CaC/content would be the best option to store OSCAL component definition files. We probably need to discuss more on this. What do you think @jpower432 ? |
Beta Was this translation helpful? Give feedback.
-
I agree. Perhaps we could explore if it makes more sense to store and distribute the OSCAL Component Definitions from one of the OSCAL repositories in the CaC org. @Mab879 @marcusburghardt Would it be preferable to move this topic to a GitHub Discussion or keep this issue open to continue the dicussion? |
Beta Was this translation helpful? Give feedback.
-
I will move this issue a discussion. |
Beta Was this translation helpful? Give feedback.
-
Share the context
Utilities were added to the content repository to create OSCAL Component definitions from the compliance data stored in YAML.
This allows user/devs to create OSCAL Component Definitions for products on an as-needed basis with the profiles and catalogs that exist in the trestle workspace under
shared/references/oscal
.Description of problem:
In order to get component definitions from this repository, a user would have to clone the repository and create it through the utilities.
Problems with this:
Proposed change:
Choose products and available profile combinations to generate OSCAL component definitions and add it as a release artifact so can be easily imported into an SSP or workspace (e.g.
trestle import
).References:
Related to #11106
A repository I created for demonstrate the transformation - https://github.com/jpower432/oscal-authoring-demo
Beta Was this translation helpful? Give feedback.
All reactions