Implement §5.3 Implementation Status restriction in ¶1 (mutually exclusive choices).

[GaryGapinski]

In order to ensure control implementations are properly represented in an OSCAL SSP, control implementation status values are (mostly) mutually exclusive. This is discussed in Guide to OSCAL-based FedRAMP System Security Plans §5.3.

Add validation assertions that match the exclusions.

• [x] Create schematron assertions adding to the existing related ones
• [x] Create matching unit tests
• [x] Populate assertions with affirmative (general) and diagnostic (technical) messages

Definition of Done

Struck-through items are not applicable.

• [x] Acceptance criteria met - Each user story should meet the acceptance criteria in the description
• [x] Unit test coverage of our code > 90% (from QASP) this may be fuzzy and hard to prove
• [x] Code quality checks passed - Enable html tidy with XML code standards as part of the build (from QASP) - [ ] Accessibility: (from QASP) as we create guidance or documentation and reports (semantic tagging including aria tags): demonstrate with 0 errors reported for WCAG 2.1 AA standards using an automated scanner and 0 errors reported in manual testing
• [x] Code reviewed - Code reviewed by at least one other team members (or developed by a pair)
• [x] Source code merged - Code that’s demoed must be in source control and merged
• [x] Code must successfully build and deploy into staging environment (from QASP): this may evolve from xslt sh pipline into something more ~~- [ ] Security reviewed and reported - Conduct vulnerability and compliance scanning. threat modeling? ~~ - [ ] Code submitted must be free of medium- and high-level static and dynamic security vulnerabilities (from QASP) - [ ] Usability tests passed - Each user story should be easy to use by target users (development community? FedRAMP FART team) - [ ] Usability testing and other user research methods must be conducted at regular intervals throughout the development process (not just at the beginning or end). (from QASP)
• [x] Code refactored for clarity - Code must be clean, self-documenting
• [x] No local design debt
• [x] Load/performance tests passed - test data needed - saxon instrumentation - [ ] Documentation generated - update readme or contributing markdown as necessary. - [ ] Architectural Decision Record completed as necessary for significant design choices

[GaryGapinski]

Status of partial requires planned. Status of planned does not require partial. All other statuses are mutually exclusive.