-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: initial poc for report #372
Conversation
✅ Deploy Preview for lula-docs canceled.
|
Still need to add functionality for grabbing all controls from source profile to get a percentage mapped. All other report types SSP/SAP/SAR would be added once we have those to pull data from. Still need to add tests. |
For posterity - we had discussed this being blocked/dependent on the generation work. After re-review, I believe that is short-sighted on my part. While not untrue for the code - I think there is more that we could be doing to effectively identify the problem. I appreciate what you have done here - I think what we lack currently is what the intent of Lula Reporting really entails. You have created some flexibility wherein we can report on different models or targets - which may very well be a part of what we need. To make this more actionable - I believe we need a higher-level picture of what is valuable and that we want to accomplish with the |
I agree on the design session, I didn't want to get too in-depth with what is being reported and how its gotten. How much is by default, do we go with a detailed/summary, do we go with a way to add more or remove from those. I can see the need to provide tons of details. How many controls total, how many in X family, tech vs admin, new term portable vs non-portable (if you piece mill it or use another CSP what do you lose/keep), various frameworks/ILs, how many are validated, how many failed, and tons of correlations of each of these. All of that for every layer component definition, SSP, SAP/SAR, POAM Figuring out what is the most important to start with and what is needed to do it. I think Daniel will have a lot of awesome insights on what could be initially needed to show. I only think its "blocked" in the sense we just need a working OSCAL with some example data of each to report against. I believe we could run it along side generate functionality. Possibly use report to test the correctness of generate's output. |
@CloudBeard Do we still need this Draft given #599 ? |
Nope ill close this one. I used a mix of your draft and this draft to get started. |
Description
Initial POC for report command. Currently only reports controls from component definition. Outputs json by default but also supports yaml. Support the ability to create output file if needed and stdout. This allows for broader use of the report but also ability to send JSON/YAML into a processor for visualization.
Currently can create a detailed and/or summary report based on needs.
Related Issue
Relates to #223 and #247
Type of change
Checklist before merging