This repository has been archived by the owner on Dec 12, 2023. It is now read-only.
forked from GSA/fedramp-automation
-
Notifications
You must be signed in to change notification settings - Fork 8
Architectural Overview
Daniel Naab edited this page Oct 7, 2022
·
13 revisions
- Architectural Decisions were recorded
- Release and versioning strategy - Releases are published via Github Releases and versioned with "Spock versioning."
- Team permissions management - Project followed GSA TTS Recommendations for GitHub team organization
- Usage metrics data collection - Collection of usage metrics is performed by the Digital Analytics Program, and previously, Google Forms.
- XML and Schematron - XML was originally chosen as the basis for validations due to the usage of XML technologies in OSCAL. This was continued throughout the project, which allowed easier integration with the NIST toolchain.
- XSLT Library - The choice of Schematron for validation required the usage of an XSLT processor. Several processors were evaluated, with the Saxon suite chosen as the only viable XSLT 3.0 option.
- XSLT integration within Schematron - To augment the limited functionality of Schematron, XSLT is directly utilized.
- Shell-based validation pipeline - The decision was made to focus on shell-based development as the needs of the community had not (and still have not) been fully expressed.
- XProc pipelining was investigated - Ultimately the level of effort required was deemed outside the scope of the project and likely to interfere with FedRAMP validation development.
- Client-side validation web interface - Initially intended for internal testing, as a proof-of-concept, and as a readable report to review validation results. It evolved into a tool used by vendors, Cloud Service Providers (CSPs), and third-party assessment organizations (3PAO) for validation of OSCAL deliverables.
- Attachment validation policy is minimal - Due to complexity of inputs and considerable number of possible filetypes, attachment validation was mostly left to post-validation processes (as yet undefined) and manual review by FedRAMP reviewers as is current practice.
- Multi-document Validation Rules - This was a major aspect of the Phase 4 work. Basic validations are available, based on existing FedRAMP OSCAL Guides, for the four types of OSCAL documents.
- Remote Resources - available via XSLT param element
- DNS Validation - available in schematron validation rules.
- SchXSLT - Port to use of this for Schematron evaluation. Current transpilation tool is no longer being developed.
- Saxon-EE integration This would allow for web based OSCAL Schema validation. Has a monetary cost and not tested for use with the current online tool.