Future Development Considerations

Future development effort is required in a number of known areas. Some of these areas of development require architectural decisions to be made.

These future development paths are currently documented in the issue backlog, as well as proposed ADRs. This is a summary of known, future development considerations, with links to relevant background material.

Technical work

NIST SP 800-53 rev5

Relevant issue: Create FedRAMP validations for SP 800-53 rev5

Implement validations for NIST RMF revision 5. This requires a strategy for tagging target revisions, or managing the distinction between revisions.

Add rev 5 to the web documentation

Additionally, update the OSCAL guides for rev 5.

FedRAMP vs non-FedRAMP schematron validations

Relevant issue: Create FedRAMP/non-FedRAMP split

To enable a future split, FedRAMP-specific validation rules have been tagged with fedramp:specific="true". Future work should consider how/whether NIST RMF and Fedramp-specific rules should be modularized separately.

Refactor common schematron validations

Relevant issue: Refactor common schematron validations

SchXSLT

Relevant issue: Spike: consider usage of SchXslt

Due to lack of maintenance of the currently-utilized Schematron implementation, consider use of SchXSLT for future growth and maintainability

Address FedRAMP documentation deficiencies

At the time of writing, the remaining SAP and SAR Github issues are blocked by various FedRAMP Automation Guide issues.

Modularity of XSpec instances

Pull out contexts that are duplicative to reduce code length and complexity, perhaps use external context files.

Multi-document validation rules

Relevant ADR

Policy Considerations

FedRAMP Package

Submission structure

The structure of a complete FedRAMP OSCAL package is in need of definition. Such a definition would include:

• Required files
• Naming conventions
• Method of defining metadata, such as a manifest document

Document validation process

In addition to the application of ASAP validation rules, the multi-step validation process needs to be defined and documented in the official guides. Such a process is not complicated, and is generally agreed upon:

• Validate XML schema on all documents
• Validate each document
• Validate cross-document rules (unimplemented)
• Report on any validation errors

Technical Debt

• Existing Guide instructions are questionable in many cases. These will need to be examined once the new guide is made available. (Rev 4 and Rev 5)