defenseunicorns / component-generator Goto Github PK

Should the capabilities that we build here be part of a greater OSCAL toolkit? Current functionality and focus are very component-definition focused - but there may be actions we want to build in the future to support other OSCAL models and activities.

Opening and reading files with the tool is currently using the directory the tool is executed from - rather this should be in relation to the configuration file.

Ensure that feature parity has been met for replacing bigbang-oscal-component-generator

Given the existing format for aggregation of component-definitions - could this same declarative file not also be used to create a system security plan template?

Need to investigate what transient data moves from component definitions to SSP's.

The component generator does not diff the back matter. In instances where only a change is made to the back matter it is not picked up.

Noticed as part of a DUBBD PR where I updated BB upstream back matter for NeuVector. Changed from Prisma to NeuVector

defenseunicorns/uds-package-dubbd#481

The aggregate document only translates the child components and does not aggregate other data from the child artifacts.

Should the tool translate and aggregate metadata?

Review the inputs for working with OSCAL objects and look to minimize required type awareness.

IE Can we pass in []bytes instead of a known type after reading in the document?

Objective: make the publicly exposed functions better suited to other projects that may not want/need awareness of the same types as this project.

Version currently is open to be any specified value. The tool should likely establish error checking for what is being specified.

While doing this work - we should consider bounding it to the available versions in Go-oscal and using those models in the generation.

For valid Schema we need to update code so that when we combine component-definition files each unique party-uuids is added to the Parties UUID in the metadata.

Ability to generate the aggregate document through only a single CLI invocation.

--remote --remote --local

Review required fields and implement a baseline of requirements for imperative runtime.

Would like to investigate the ability to check for deltas between an existing artifacts and a newly generated (in memory) artifact to check for changes before generation of a new UUID.

Does this artifact UUID really need to change?

Something along the workflow of:

• state name of file to generate (example: my-file.yaml)
• If that file exists in the generation location:
  • Collect the required information for performing a diff
  • Likely top-level UUID / top-level metadata / child UUID's
  • generate the new artifact (in memory)
  • perform a comparison between existing data and new data
  • Only generate new data if there was an update

Continue to support component-generator or consume it as an internal function within Lula?

Potential blockers would be getting functionality included and cut an initial release of Lula.

Similar to defenseunicorns/lula#96

Create a packing and release process.

As we use components from various repos each include a starting control-implementations which points to the compliance framework (Currently just NIST 800-53). When we combine these component files this field is duplicated.

May need to look at sorting/grouping based on control-implementations frameworks for the event we start to map to multiple frameworks.