oscal-compass/compliance-trestle

Rules: Property use of field remarks to should be discontinued in favor of field group

Open

#1,873 opened on May 9, 2025

View on GitHub
 (7 comments) (0 reactions) (0 assignees)Python (103 forks)auto 404
event/slamexempt-from-stalehelp wantedpythonrefactor

Repository metrics

Stars
 (264 stars)
PR merge metrics
 (PR metrics pending)

Description

Issue description / feature objectives

Trestle has an opinionated implementation of Rules to fill the gap missing in OSCAL. It does so in a OSCAL compliant manner by employing sets of Property instances to define Rules. In doing so, collections of Rules are identified by having a remarks field comprising a rule_set prefix together with a suffix that is common to each collection that defines a single rule.

For example, a Property with remarks=rule_set_001, name=nameA, value=valueA and another Property with remarks=rule_set_001, name=nameB value=valueB belong to the same Rule.

Since the original implementation of rules by employing remarks, OSCAL has progressed by adding a new group field to Property. This seems like a much more suitable place to identify Rules.

The challenge is to migrate from using the remarks field to using the group field in a backward compatible manner. If an artifact, e.g. Component Definition, is already using remarks, that should still be supported. If a new Component Definition is created, it should employ group.

Also nice to have is a conversion utility to transform "old" OSCAL artifacts using remarks into "new" OSCAL artifacts using group.

Also to consider is that sets of checks employ opinionated trestle Property collections in similar fashion to Rules, likewise using the rule-set prefix. Perhaps better identified as check_set?

Caveats / Assumptions

  • code changes are likely needed to: tasks, core, transforms
  • it is unlikely that OSCAL itself will formerly support rules in the near future

Completion Criteria

  • existing test cases should continue to work with NO changes
  • new test cases should be added to cover the use of group
  • test cases for 100% coverage of new/modified code
  • commensurate documentation updates
  • commensurate demo updates (this may be accomplished by initiating a separate issue)

Contributor guide