Dangling anchor references should log warnings, not errors that halt profile resolution

[aj-stein-gsa]

Describe the bug

During debugging of profile resolution updates for GSA/fedramp-automation#1185 today, I encountered a cryptic error involving updates to the current FedRAMP tailoring profile in develop that customizes the upstream NIST SP 800-53 catalog 5.1.1 released as part of oscal-content v1.3.0. The following error occurs.

Error: OSCAL CLI process exited with code 1:
The anchor at '/catalog/group[11]/control[6]/control[2]/param[3]/guideline[1]/prose[1]' should reference a resource, control, group, or part identified by 'pe-06.02_odp.02', but the identifier was not found in the index.

This Metapath equates to the following content in the NIST upstream catalog.

        <param id="pe-06.02_odp.03">
          <prop name="alt-identifier" value="pe-6.2_prm_3"/>
          <prop name="label" class="sp800-53a" value="PE-06(02)_ODP[03]"/>
          <label>automated mechanisms</label>
          <guideline>
            <!-- Problem below is the value of the content of the <a href="#..." anchor -->
            <p>automated mechanisms used to recognize classes or types of intrusions and initiate response actions (defined in <a href="#pe-06.02_odp.02">PE-06(02)_ODP</a>) are defined;</p>
          </guideline>
        </param>

This error about a dangling error reference halts profile resolution as an error, and per discussion with @david-waltermire really represents a warning and should not stop processing, which is indicative in the current warning message phrased with a "should" and not a "must."

liboscal-java/src/main/java/gov/nist/secauto/oscal/lib/profile/resolver/policy/AnchorReferencePolicy.java

Lines 75 to 91 in dcb0e55

	protected boolean handleIndexMiss(
	@NonNull IModelNodeItem<?, ?> contextItem,
	@NonNull InlineLinkNode reference,
	@NonNull List<IEntityItem.ItemType> itemTypes,
	@NonNull String identifier,
	@NonNull ReferenceCountingVisitor.Context visitorContext) {
	if (LOGGER.isErrorEnabled()) {
	LOGGER.atError().log(
	"The anchor at '{}' should reference a {} identified by '{}', but the identifier was not found in the index.",
	contextItem.toPath(IPathFormatter.METAPATH_PATH_FORMATER),
	itemTypes.stream()
	.map(en -> en.name().toLowerCase(Locale.ROOT))
	.collect(CustomCollectors.joiningWithOxfordComma("or")),
	identifier);
	}
	return true;
	}

Profile resolution is incomplete in this edge case, and FedRAMP's Metaschema constraints fail to process properties in the catalog from the SSP's //import-profile and crash all other processing for a non-critical dereferencing issue.

Who is the bug affecting

Developers using liboscal-java's profile resolution to perform build or runtime-based profile resolution to process a SSP or other cross-linked data from a profile or catalog.

How do we replicate this issue

See the above description for how to use liboscal-java with a current version of this library from a snapshot to replicate this issue by resolving the FedRAMP tailoring profile.

oscal-cli --version
oscal-cli 2.5.0-SNAPSHOT built at 2025-04-02 01:56 from branch develop (f75c852) at https://github.com/metaschema-framework/oscal-cli
liboscal-java 5.2.0-SNAPSHOT built at 2025-04-02 01:49 from branch develop (dcb0e55) at https://github.com/metaschema-framework/liboscal-java
oscal  built at 2025-04-02 01:49 from branch develop (b39789e) at https://github.com/usnistgov/OSCAL.git
metaschema-java 2.2.0-SNAPSHOT built at 2025-04-01T21:37:59+0000 from branch develop (b881a64) at https://github.com/metaschema-framework/metaschema-java
metaschema 2.2.0-SNAPSHOT built at 2025-04-01T21:37:59+0000 from branch develop (c07df88) at https://github.com/metaschema-framework/metaschema.git

Expected behavior (i.e. solution)

Profile resolution for these edge cases occurs but reports a warning, not an error. Profile resolution successfully completes.

Other comments

No response