Constraints on catalog links to related controls in catalogs from resolved profiles yield confusing errors

[aj-stein-gsa]

Describe the bug

For users of the NIST SP 800-53 OSCAL catalogs provided by NIST and 1.0.0-1.1.3 OSCAL models for catalog and profile, there is a frequently reoccurring error from a constraint that checks for controls with link[@rel="related"] and a URI reference (like HTML anchor) to related controls in the catalog. For catalogs resolved from profiles, the resulting catalog can reference controls in the original full catalog of all controls but the related control is no long in the resolved catalog, leading to errors.

Constraint:

OSCAL/src/metaschema/oscal_catalog_metaschema.xml

Lines 250 to 253 in b123c11

	<index-has-key name="catalog-groups-controls-parts"
	target="link[@rel=('related','required','incorporated-into','moved-to') and starts-with(@href,'#')]">
	<key-field target="@href" pattern="#(.*)"/>
	</index-has-key>

Catalogs subsequently resolved from profiles that drop controls referenced like this

          {
            "id": "cp-2",
            "class": "SP800-53",
            "title": "Contingency Plan",
            "links": [
              {
                "href": "#sa-20",
                "rel": "related"
              },
          }

will then report errors because the "target" of that relation is no longer in the resulting catalog.

[ERROR]  FedRAMP_rev5_MODERATE-baseline-resolved-profile_catalog-min.json:39104:17
Key reference [sa-20] not found in index 'catalog-groups-controls-parts' for item at path '/catalog/group[6]/control[2]/link[24]'

Proposed Solutions

There are different solutions to this issue, but I assume classifying this as a bug in the constraint is the easier, less risk-prone approach.

1. Changing the severity of the constraint to level="WARNING" for instances where the referenced control exists. (lower risk, least complexity)
2. Rewriting the catalogs in usnistgov/oscal-content to remodel the links outside of the control with novel assembly design or with specialized props in the RMF namespace that avoid link usage this way. (higher risk, higher complexity)

Who is the bug affecting

Users and developers of OSCAL-enabled software that process catalogs, especially those resolved from tailoring profiles, with controls removed from the original SP 800-53B comprehensive catalog.

What is affected by this bug

Metaschema, Modeling, OSCAL Content

How do we replicate this issue

# Clone `develop` branch
git clone https://github.com/GSA/fedramp-automation.git -b develop
# Check current version of FedRAMP repository at the time of this bug report
git rev-parse HEAD
63d34247d463aa1fd3a038ee60712660952dd190
# Resolve profile for updated content
oscal-cli \
  resolve-profile \
    --to xml --overwrite \
    '/home/me/fedramp-automation/src/content/rev5/baselines/xml/FedRAMP_rev5_MODERATE-baseline_profile.xml' \
    '/home/me/fedramp-automation/dist/content/rev5/baselines/xml/FedRAMP_rev5_MODERATE-baseline-resolved-profile_catalog.xml'
# Validate and observe error with checking URI reference links
oscal-cli \
  validate \
   '/home/me/fedramp-automation/dist/content/rev5/baselines/xml/FedRAMP_rev5_MODERATE-baseline-resolved-profile_catalog.xml'

Expected behavior (i.e. solution)

Constraint violations that exist are WARNING levels or not exist at all (see above for different solutions).

NOTE: there is no surefire way, with a mandatory elements in a catalog, to know it is a resolved catalog profile. There is an optional resolution-source in /catalog/links/.[@rel="resolution-source]` but as it is optional and not mandatory in the model use or profile resolution spec, this limits are options to be more tactical and even less risk-prone with constraint processing to change the behavior on "raw" versus "catalogs resolved from profiles." I hope this context is helpful. I am also amenable to other options.

Other comments

No response

Revisions

No response