Optionality for validation/mapping of Comp-Def control-implementations

Context

TLDR: Add support for validating/mapping component-definitions with many control-implementations.

The component-definition exists as a layer below catalogs/profiles such that it captures more finely scoped context about specific components and the controls (implemented-requirements) that a component can potentially satisfy.

Lula adds a flavor of execution around component-definitions and allows for shifting compliance left given the existence of this single artifacts with validations Lula can perform.

As Lula looks to target validation of assessment-plans (mapped from component-definitions), the potential that Lula would want to support a component-definition with many control-implementations is more likely to occur. This also allows for treating component-definitions as another source of different standards mapping while allowing re-use of validations across standards

Objectives

lula validate flags for specification of which control-implementation to validate
Establish default behavior when not specified

Current thought is using Props on the control-implementation to identtify a way to use flags for varying compliance frameworks.

Ex.)

# add the descriptions inline
component-definition:
  uuid: cc873a43-e9fa-433b-8c20-222d733daf1e
  metadata:
    title: Istio Controlplane
    last-modified: "2024-01-18T16:41:56Z"
    version: "20240118"
    oscal-version: 1.1.1
    parties:
      - uuid: f3cf70f8-ba44-4e55-9ea3-389ef24847d3
        type: organization
        name: Defense Unicorns
        links:
          - href: https://defenseunicorns.com
            rel: website
  components:
    - uuid: e7e62a4f-8ae7-4fb0-812c-60ea6ae26374
      type: software
      title: Istio Controlplane
      description: |
        Istio Service Mesh
      purpose: Istio Service Mesh
      responsible-roles:
        - role-id: provider
          party-uuids:
            - f3cf70f8-ba44-4e55-9ea3-389ef24847d3
      control-implementations:
        - uuid: d2afb4c4-2cd8-5305-a6cc-d1bc7b388d0c
          source: https://raw.githubusercontent.com/GSA/fedramp-automation/93ca0e20ff5e54fc04140613476fba80f08e3c7d/dist/content/rev5/baselines/json/FedRAMP_rev5_HIGH-baseline-resolved-profile_catalog.json
          description: Controls implemented by Istio and authservice that are inherited by applications
         props:
         - name: 
           uuid:
           ns:
           value: 
           class:
           group: 
           remarks:

Lots of options to roll with in the props.

         props:
         - name: framework
           uuid: 3c2439b1-ea21-49ce-aa9a-340a10870902
           ns: https://lula.dev/ns/framework
           value:
           class: fedramp-high
           group: 
           remarks:

Not all pieces are required and we could use value, class, and group in a few different ways.

Just starting to see what fits best to designate various frameworks without text matching the source url for keywords.

Link to the reference model: https://pages.nist.gov/OSCAL-Reference/models/v1.1.2/component-definition/json-reference/#/component-definition/components/control-implementations/props

defenseunicorns / lula

Optionality for validation/mapping of Comp-Def control-implementations #327

Context

Objectives