chore(adr): add ADR for E2E intent and design

[brandtkeller]

Description

ADR for Lula E2E OSCAL design decisions and expectations.

To follow this ADR:

• Doc for the lifecycle of a software artifact
• Doc for the lifecycle of a target environment
• Future Docs for the generation of the remaining models and the inclusion of them in the lifecycles

Related Issue

Relates to #431

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Other (security config, docs update, etc)

Checklist before merging

• Test, docs, adr added or updated as needed
• Contributor Guide Steps followed

[netlify]

✅ Deploy Preview for lula-docs canceled.

Name	Link
🔨 Latest commit	b65eb90
🔍 Latest deploy log	https://app.netlify.com/sites/lula-docs/deploys/664e6f281dc3e80008eb0bde

[CloudBeard]

Should it be the assessment plan will aggregate one-to-one system-security-plan ?

Thinking the assessment plan links to the ssp which links to the components. It technically assess the admin controls too.

https://pages.nist.gov/OSCAL-Reference/models/v1.1.2/assessment-plan/json-reference/#/assessment-plan/import-ssp

[brandtkeller]

Good question - it may vey well be.

If the data flow is: component -> assessment plan -> system security plan then yes that may be the case?

But I see a lot of overlap between components and SSP that makes me wonder about this workflow.

I'm going to look at this ADR again - I don't want to focus too much on the solutioning (hence why there was mention of many possible workflows) - But I think I need to highlight another point - which is that we might use components to generate an AP & SSP - but when the generation of say the AP detects that an SSP exists - it can establish context sharing. So as you implement each model - you may have cross model connections being made.

[CloudBeard]

"we might use components to generate an AP & SSP - but when the generation of say the AP detects that an SSP exists - it can establish context sharing. So as you implement each model - you may have cross model connections being made."

^ This, 100% agree. I also agree there are several possibilities for our workflows.

I think OSCAL Data Flow viewpoint is

graph TD;
    A[Component Definition]
    B[Assessment Plan]
    C[System Security Plan]
    D[Assessment Results]
    E[POAM]

    A --> C --> B --> D --> E
 

Loading

This may show it a little better too. https://pages.nist.gov/OSCAL/resources/concepts/layer/assessment/assessment-results/#key-concepts

[CloudBeard]

Big fan of the mermaid flow chart.

[meganwolf0]

Looks good to me! I think the one thing thing missing for me was discussion of evaluate and how that fits into the end-to-end

[brandtkeller]

Looks good to me! I think the one thing thing missing for me was discussion of evaluate and how that fits into the end-to-end

That's a good mention. Evaluate does not produce any artifacts (yet), nor is it comprised of any specific artifact itself (IE like a validation).

Focusing on artifact strategy here - but am open to including process if we believe it is necessary and would warrant a later ADR?

[meganwolf0]

That's a good mention. Evaluate does not produce any artifacts (yet), nor is it comprised of any specific artifact itself (IE like a validation).

I was thinking that since it evaluates two assessment-results, it is kind of reliant on OSCAL data and would potentially fit within an E2E picture? But I realize that it's not actually producing any kind of recognized OSCAL data so maybe doesn't actually make sense here. I was more just thinking about enumerating the use case for evaluate being relevant in the full end to end.

I'm good to table the question on evaluate if it's out of scope for this