Security Controls - SSP by-component assemblies have implementation-status

[Rene2mt]

Constraint Task

As a consumer of FedRAMP automated completeness checks, I want to make sure that SSP statements include (via by-component assembly) valid implementation status.

Intended Outcome

• Every by-component assembly must have an implementation-status field with an @state attribute` that must be set to one of the core OSCAL allowed values.

Syntax Type

This is optional core OSCAL syntax.

Allowed Values

There are only NIST-defined allowed values.

Metapath(s) to Content

- context='//control-implementation/implemented-requirement/statement/by-component'
- target='./implementation-status/@state'
- Allowed Values (Allow Others = "no")
  - implemented: The control is fully implemented.
  - partial: The control is partially implemented.
  - planned: There is a plan for implementing the control as explained in the remarks.
  - alternative: There is an alternative implementation for this control as explained in the remarks.
  - not-applicable: This control does not apply to this system as justified in the remarks.

Purpose of the OSCAL Content

This validation check helps reviewers ensure that only allowed values are provided for the by-component implementation-status.

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.