GSA/fedramp-automation

Check that all resources are referenced in digital authorization package

Opened this issue · 0 comments

aj-stein-gsa commented

Constraint Task

As a maintainer of a digital authorization package, to ensure all package artifacts are referenced in a given SSP/POAM/SAP/SAR document so FedRAMP reviewers are only provided referenced material and not passback othererwise, I would like a check that any back-matter/resource is cited in the document(s).

Intended Outcome

Goal

Prevent "dangling" resources in the back-matter are not to be left unused.

Syntax

Use any index or index-has-key for a constraint (id="resource-is-referenced" and level="ERROR") that any given back-matter/resource/@uuidis referenced at least one by.//link/@href`.

Syntax Type

This is required core OSCAL syntax.

Allowed Values

There are no relevant allowed values.

Metapath(s) to Content

/(assessment-plan|assessment-results|plan-of-action-and-milestones|system-security-plan)//link/@href
/(assessment-plan|assessment-results|plan-of-action-and-milestones|system-security-plan)/back-matter/resource/@uuid

Purpose of the OSCAL Content

Integrity checks on any given use of a resource to be actually used in the document and not provided without rationale.

Dependencies

No response

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