You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As summarized most recently in usnistgov/OSCAL#2072, there are instances where the FedRAMP Automation Team discovers overly generic, specific, or incorrect model requirements in the core NIST OSCAL models. In most cases, FedRAMP constraints can extend core model requirements more specifically. In unique cases, as evidenced by specific items in #2072, the incorrect constraints in core NIST OSCAL models will still remain errors for conformant Metaschema-based processors that process an OSCAL document. FedRAMP cannot override those requirements. They are inherently in conflict. If NIST does not release a new version of the models with the recommended fix, FedRAMP stakeholders will never have correct OSCAL content in packages that conform to core NIST OSCAL and FedRAMP requirements at the same time.
Risk Mitigation Strategy
Strategy: Mitigation
The FedRAMP Automation Team will continue to work with NIST maintainers of the core OSCAL models to report and fix bugs in latest stable release of OSCAL models and create new major, minor, and patch releases as appropriate. FedRAMP is developing more precise constraints to correlate FedRAMP requirements to a minimally required OSCAL version per #847 and #833 to ensure FedRAMP can have more agility in evaluating and pinning a reliable minimally required OSCAL version.
The text was updated successfully, but these errors were encountered:
david-waltermire
changed the title
NIST will not release changes NIST OSCAL models that conflict with FedRAMP constraints
NIST will not release changes in NIST OSCAL models that conflict with FedRAMP constraints
Nov 15, 2024
NIST release v1.1.3 during the last week. We found other bugs and important fixes that will soon block current and upcoming constraint development in the near future. Initial feedback on inconsistent application of unwritten policies in usnistgov/OSCAL#2080 regarding which upstream schemas and software NIST does or does not support is cause for concern on this risk again. It would seem we need to monitor this and go from accepting the risk to planning a mitigation if a possible move to improve Metaschema specs and the fork is rejected by NIST, with or without clear reasoning.
usnistgov/OSCAL#2084
this PR attempts to introduce an integration testing framework so that these bugs can be squashed in a way that we can verify before proceeding with another release. I am curious to see how nist responds
Risk Summary
As summarized most recently in usnistgov/OSCAL#2072, there are instances where the FedRAMP Automation Team discovers overly generic, specific, or incorrect model requirements in the core NIST OSCAL models. In most cases, FedRAMP constraints can extend core model requirements more specifically. In unique cases, as evidenced by specific items in #2072, the incorrect constraints in core NIST OSCAL models will still remain errors for conformant Metaschema-based processors that process an OSCAL document. FedRAMP cannot override those requirements. They are inherently in conflict. If NIST does not release a new version of the models with the recommended fix, FedRAMP stakeholders will never have correct OSCAL content in packages that conform to core NIST OSCAL and FedRAMP requirements at the same time.
Risk Mitigation Strategy
Strategy: Mitigation
The FedRAMP Automation Team will continue to work with NIST maintainers of the core OSCAL models to report and fix bugs in latest stable release of OSCAL models and create new major, minor, and patch releases as appropriate. FedRAMP is developing more precise constraints to correlate FedRAMP requirements to a minimally required OSCAL version per #847 and #833 to ensure FedRAMP can have more agility in evaluating and pinning a reliable minimally required OSCAL version.
The text was updated successfully, but these errors were encountered: