Change policy and procedure attachment checking constraints from catalog data

[aj-stein-gsa]

Constraint Task

As a developer of OSCAL-enabled tooling, to make identification of control statements with required attachments more robust without hard-coding attachment identifiers out-of-band, I want constraints to check for prop[@ns="http://fedramp.gov/ns/oscal" name="required-attachment"] and check its @value to supply as messages for constraint violations.

Intended Outcome

• Replace the processing of let[@var="control-statement-ids"], let[@var="policy-messages"], and let[@var="procedure-messages"] with processing from the catalog props once implemented in Add policy and procedure attachment props directly to baselines for attachment tracking #1185.
• Update test logic and message message to build from the content of the prop[@ns="http://fedramp.gov/ns/oscal" name="required-attachment"]/@value for the following constraints:
  • expect[@Id="has-policy"]
  • expect[@Id="has-procedure"]

Syntax Type

This is a FedRAMP constraint in the FedRAMP-specific namespace.

Allowed Values

There are no relevant allowed values.

Metapath(s) to Content

/catalog/control/part[prop[@ns="http://fedramp.gov/ns/oscal" and name="required-attachment" and @class="policy"]

/catalog/control/part[prop[@ns="http://fedramp.gov/ns/oscal" and name="required-attachment" and @class="procedure"]

Purpose of the OSCAL Content

No response

Dependencies

• Add policy and procedure attachment props directly to baselines for attachment tracking #1185

Acceptance Criteria

• All OSCAL adoption content affected by the change in this issue have been updated in accordance with the Documentation Standards.
  • Explanation is present and accurate
  • sample content is present and accurate
  • Metapath is present, accurate, and does not throw a syntax exception using oscal-cli metaschema metapath eval -e "expression".
• All constraints associated with the review task have been created
• The appropriate example OSCAL file is updated with content that demonstrates the FedRAMP-compliant OSCAL presentation.
• The constraint conforms to the FedRAMP Constraint Style Guide.
  • All automated and manual review items that identify non-conformance are addressed; or technical leads (David Waltermire; AJ Stein) have approved the PR and “override” the style guide requirement.
• Known good test content is created for unit testing.
• Known bad test content is created for unit testing.
• Unit testing is configured to run both known good and known bad test content examples.
• Passing and failing unit tests, and corresponding test vectors in the form of known valid and invalid OSCAL test files, are created or updated for each constraint.
• A Pull Request (PR) is submitted that fully addresses the goals section of the User Story in the issue.
• This issue is referenced in the PR.

Other information

No response

[aj-stein-gsa]

I need to keep experimenting locally and look into this with updated versions of the pre-release CLI tools. I can conform the performance regression but I am not sure there is a way around it. I will formally mark it as blocked and decide if we need to back out the constraint and leave the catalog props anyway by Monday before COB.