feat: initial lula report #599
Conversation
|
Quick feedback loop - I can trace the code but I would always recommend starting with docs on a new feature. Capture the purpose - let people challenge that intent. I don't believe this needs an ADR - so docs would be sufficient. At the same time I think we should keep challenging if we know enough to pursue it further. Does this provide enough value to be of use or does some infrastructure require more maturation first. Transparently I do not know if we have enough context to make the result meaningful. |
|
Still need to add tests but want to figure out where/what packages to create to tidy up the main report code. |
There was a problem hiding this comment.
Trending in the right direction now that we're getting to core of what we need (or can provide currently).
I think we're still missing a bit of big picture vision -> Which I/the team can help define.
See my comment about the context that drives the reporting (as we see it today). Ideally we as a team need to provide a clearer deliverable on our issues (WIP) - but I appreciate you pursuing this nonetheless.
My current take:
Reporting should be a function of collecting available context and reporting accordingly.
- First iteration starts with component-definition and reports controls available.
- With the presence of a catalog/profile -> we can overlay that control information to calculate percentages.
- with the presence of assessment-results we can check satisfied/not-satisfied
Given that - we can start migrating functionality to the oscal model libraries for each model as applicable to get the context we need to return here for collective reporting.
My opinion is that reporting is not singly-model focused and rather total context driven. I may be very wrong - let's chat as a team if anyone feels otherwise.
CloudBeard
requested review from
mike-winberry and
meganwolf0
as code owners
There was a problem hiding this comment.
No issues with the current direction.
I would remove the current documentation and run a lula internal gen-cli-docs in order to generate the new CLI docs for this command. Iterate as necessary to try and capture all context in the CLI command code as possible. If you need additional docs place them outside the docs/cli-commands directory.
Otherwise this gets us moving in the right direction - as I mentioned previously, I expect future iterations to be less of a model-by-model reporting structure and rather wholistic reporting of all models - but that is out of scope currently.
|
Just tested locally - is this |
Yea that would make sense. Ill fix that real quick-ish |
Description
Adds report functionality starting with component definition.
Will report how many controls are mapped per source and per framework for each component. There is the possibility that a component-definition file has multiple sources and multiple frameworks. The current report will list how many controls are in each and will give a % mapped based on the source provided for each.
Running
lula generate component --catalog-source https://raw.githubusercontent.com/GSA/fedramp-automation/master/dist/content/rev5/baselines/json/FedRAMP_rev5_MODERATE-baseline-resolved-profile_catalog.json --component 'Keycloak' --requirements ac-12,ac-2,ac-2.1,ac-2.3,ac-2.4,ac-2.5,ac-2.7,ac-3,ac-5,ac-6,ac-6.1,ac-6.2,ac-6.5,ac-6.9,ac-6.10,ac-7,ac-8,au-2,au-3,au-3.1,au-8,au-9.4,au-12,cm-5.1,cm-5.5,ia-2,ia-4.4,ia-5.1,ia-5.2,ia-6,ia-8.1,ia-11,sc-13 --remarks assessment-objective --framework il4Will show that ac-2 is fixed but also show that other controls aren't broken as a side effect of the fix.
Related Issue
Relates to #223 and #247
Type of change
Checklist before merging