feat: adds transformation from component definitions to assessment plans

[jpower432]

Description

The main feature added in the ComponentDefinitionsToAssessmentPlan function that will take one or more OSCAL Component Definitions are populate an Assessment Plan.

• A models package was added to support logic around specific OSCAL models or subsets (compliance-trestle partial equivalent)
• A transformers package was added with logic for OSCAL to OSCAL transformations (compliance-trestle equivalent, but scoped to OSCAL-to-OSCAL only)
• Logic updated in existing packages to support

Closes #32
To support oscal-compass/compliance-to-policy-go#43

Review Hints

• Recommend to review each commit individually.
• The Settings interface is remove and the RequirementsSettings struct is renamed to Settings because all other implementation were using the same type and methods to support the logic. An interface is not needed (yet) and can be added later if the use case arises.

How has this been tested?

• Unit tests added to cover new logic

Types of changes

• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Quality assurance (all should be covered).

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing tests pass locally with my changes
• All commits are signed-off.

[gvauter]

LGTM - one small thought for a future task.

[jpower432]

@vikas-agarwal76 @degenaro @yana1205 @butler54
Adding some additional context on the approach here. Please let me know if you have feedback/questions:

• The validation components are added under assessment assets. All original component properties are retained.
• The DefinedComponents are transformed to SystemComponents as required an placed under LocalDefinitions for the Component Definition to Assessment Plan and the SSP import value is set to the standard REPLACE_ME string. All original component properties are retained.
• An activity was added for each rule under Local Definitions where the relationship to controls from the Component Defintion control implementation is maintained and the checks were documented as activity steps.
• The component is documented as an Assessment subject and the rule activity is associated.
• Future Consideration: The defined activities could be used to populate the origin and subject information in Assessment Result Observations that are created from policy results.

[hbraswelrh]

LGTM, left a minor comment. Tested locally.

[vikas-agarwal76]

@vikas-agarwal76 @degenaro @yana1205 @butler54 Adding some additional context on the approach here. Please let me know if you have feedback/questions:

• The validation components are added under assessment assets. All original component properties are retained.
• The DefinedComponents are transformed to SystemComponents as required an placed under LocalDefinitions for the Component Definition to Assessment Plan and the SSP import value is set to the standard REPLACE_ME string. All original component properties are retained.
• An activity was added for each rule under Local Definitions where the relationship to controls from the Component Defintion control implementation is maintained and the checks were documented as activity steps.
• The component is documented as an Assessment subject and the rule activity is associated.
• Future Consideration: The defined activities could be used to populate the origin and subject information in Assessment Result Observations that are created from policy results.

@jpower432 I am not sure if acitivty corrsponds to each rule or the policy execution (which checks multiple rules). Same with associated activities in Tasks.

[degenaro]

LGTM

[jpower432]

@jpower432 I am not sure if acitivty corrsponds to each rule or the policy execution (which checks multiple rules). Same with associated activities in Tasks.

@vikas-agarwal76 documenting the outcome of our discussion here:

The rule-driven activity approach is acceptable for now. If needed, we can refine Assessment Plan approach as it gets more use.