List view
Release Milestone
Overdue by 6 month(s)•Due by January 31, 2025•4/4 issues closedRelease Milestone
Overdue by 7 month(s)•Due by January 17, 2025•1/1 issues closedThis milestone captures issues that ultimately align to objectives or features required for impact to users or other integration pathways that enable Lula adoption more broadly.
Overdue by 8 month(s)•Due by December 20, 2024•9/13 issues closedMaturing the API domain to be more capable
Overdue by 7 month(s)•Due by December 31, 2024•6/6 issues closed- No due date•14/14 issues closed
Lula as a tool in the critical path towards authorization will become more apparent as we enable fully end-to-end workflows for distributed data -> system implementation. As such reporting on data that provides concise insights to various personas will both be important as well as required when tooling wants to retrieve insights for visualization purposes. ## Objectives - Support for retrieving and ingesting a catalog - Support for retrieving and ingesting a profile (if applicable) - Support for applying profile against catalog (if applicable) - Support for Calculating % controls satisfied / not-satisfied / not evaluated in the CLI - Support for creating a visual representation (static file) for the above findings ## Evidence of Value > Do we know how many controls it covers? I am interested in tracking so we can see how much real time validation we are building up to over time
No due date•2/2 issues closed## Purpose As scale plays a role in technology and the evidence required to accredit systems - it is increasingly important to enable maintainable workflows for both the initial creation of OSCAL artifacts as well as enabling hybrid workflows where human-authored compliance information can co-exist with automation. Lula should be able to generate OSCAL artifacts that enable full or templated starting and continual state. ## Objective Imperative and Declarative generation of OSCAL artifact templates. Ability to keep existing data in-place over successive executions. ## Thoughts Given the unmarshalling process for a given OSCAL artifact - if we want to enable human authored content to persistent changes: - If an OSCAL artifact already exists (either specified or under the default name) - Unmarshall the existing document to the applicable model - Update any fields that automation establishes ownership - Some fields may be expected to be owned by automation - others we can hash for changes? - Marshall back to the applicable artifact name/type In doing this - all manually authored information should persist.
Overdue by 8 month(s)•Due by December 20, 2024•11/20 issues closed