Security Controls - SSP by-component assemblies with certain implementation-status have remarks

[Rene2mt]

Constraint Task

As a consumer of FedRAMP automated completeness checks, I want to make sure that SSP statements include (via by-component assembly) with the following implementation status (partial, planned, alternative, or not-applicable) have remarks.

Intended Outcome

• If the implementation status is partial, planned, alternative, or not-applicable, then the CSP must provide remarks to provide additional context (e.g., for assessors and reviewers).

Syntax Type

This is a mix of required, optional, and/or extended syntax.

Allowed Values

There are only NIST-defined allowed values.

Metapath(s) to Content

Every by-component/implementation-status/@state with one of the following allowed value must also have remarks:

- partial, planned, alternative, not-applicable (the only exclusion to this rule is implemented)
- context='//control-implementation/implemented-requirement/statement/by-component'
- target='./implementation-status[@state=('partial', 'planned', 'alternative', 'not-applicable' )]'
- exists(./remarks)

Purpose of the OSCAL Content

No response

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

See #810 (comment) for additional details.