Skip to content
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: add rules-to-control mappings to support implementation/requirement specific settings #30

Draft
wants to merge 4 commits into
base: main
Choose a base branch
from

Conversation

jpower432
Copy link
Member

@jpower432 jpower432 commented Dec 20, 2024

Description

Creates logic around reading OSCAL Control Implementation sets and the application of implementation or requirement specific options to RuleSets.

Partially closes #13

Reviewer Hints

  • Suggest to review by commit. Details for each change are in the commit message.
  • The main commit with the feature is the final commit. The first three are smaller refinements. They can go on their own PR, if desired.

Types of changes

  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)
    Small updates to the rules.Store interface. However, this codebase has not had an initial release yet.

Quality assurance (all should be covered).

  • My code follows the style guidelines of this project
  • I have performed a self-review of my own code
  • I have commented my code, particularly in hard-to-understand areas
  • I have made corresponding changes to the documentation
  • My changes generate no new warnings
  • I have added tests that prove my fix is effective or that my feature works
  • New and existing tests pass locally with my changes
  • All commits are signed-off.

Adding a trestle-defined namespace check ensures Rule
properties are only processed from trestle authored
documents.

Signed-off-by: Jennifer Power <[email protected]>
The All() method is removed from rules.Store to simplify the interface.
The rules.Store interface is for more focused queries.

Indexing is decoupled from the creation of the MemoryStore to
defer indexing until needed.

Signed-off-by: Jennifer Power <[email protected]>
This change adds support for processing OSCAL Control Implementations
and using that processed data to apply settings and context from requirements to
RuleSet results in a rules.Store implementation. The Settings interface is defined
to allow settings to be applied at the Implementation and Requirement levels.

Signed-off-by: Jennifer Power <[email protected]>
@jpower432 jpower432 added this to the OSCAL Utilities milestone Dec 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Feature: Get rule-to-control mapping data from OSCAL Components
1 participant