lower severity of dangling index

[wandmagic]

Committer Notes

This index can cause errors in resolved profiles due to dangling pointers in nist 80053 catalog
This approach lowers the severity of this index to a warning, because while we don't want invalid links, there are times where we still want to know about related controls even if they aren't included in our particular baseline.

Alternative approaches:

• navigate to the source catalog and assure there is a control to link there
  • source profile may not always be linked, so this is not reliable
• during profile resolution link to the fully qualified control if it's not included in the profile.
  • extra work and effort simply to adhere to this index

If we can't reduce the severity here, we'll have to adjust the resolver code to fully qualify links

All Submissions:

• Have you selected the correct base branch per Contributing guidance?
• Have you set "Allow edits and access to secrets by maintainers"?
• Have you checked to ensure there aren't other open Pull Requests for the same update/change?
• Have you squashed any non-relevant commits and commit messages? [instructions]
• Do all automated CI/CD checks pass?

By submitting a pull request, you are agreeing to provide this contribution under the CC0 1.0 Universal public domain dedication.

(For reviewers: The wiki has guidance on code review and overall issue review for completeness.)

Changes to Core Features:

• Have you added an explanation of what your changes do and why you'd like us to include them?
• Have you written new tests for your core changes, as applicable?
• Have you included examples of how to use your new feature(s)?
• Have you updated the OSCAL website and readme documentation affected by the changes you made? Changes to the OSCAL website can be made in the OSCAL-Pages and OSCAL_Reference repositories.

[wandmagic]

https://github.com/GSA/fedramp-automation/actions/runs/12833868311/job/35789876334
see here where this occurs after resolving a profile

[aj-stein-gsa]

For a bug report with detailed explanation and a recommendation to move forward with this solution, see #2093. @iMichaela and others, it would be nice to get this review as I imagine this breaks not just FedRAMP profiles, but others that more strictly followed the model constraints described when resolved profiles tailor out original controls.

[iMichaela]

For a bug report with detailed explanation and a recommendation to move forward with this solution, see #2093. @iMichaela and others, it would be nice to get this review as I imagine this breaks not just FedRAMP profiles, but others that more strictly followed the model constraints described when resolved profiles tailor out original controls.

Thank you. Will prioritize this work. Profile resolution testing is also a concern for #2090 . @wendellpiez - can you please assist with this PR?

[wendellpiez]

As far as I can see this would have no effect on profile resolution, as such - it looks good to me.

[wendellpiez]

I find the uniform prefix (oscal-) perfectly rational and sensible, as well as helpful to extenders. (And I can envision the Schematron rule to enforce this meta-rule.)

Also glad that adding use of the optional flag exposed some bugs needing fixing (sooner).

[aj-stein-gsa]

I find the uniform prefix (oscal-) perfectly rational and sensible, as well as helpful to extenders. (And I can envision the Schematron rule to enforce this meta-rule.)

Also glad that adding use of the optional flag exposed some bugs needing fixing (sooner).

Sorry we should probably take this to #2090, not #2095. I confused the matter because I quickly wrote up a comment in the wrong tab of tabs side-by-side.