Describe the bug
The au-2_prm_2 parameter in the SP 800-53 Rev 5 catalog has an inline <a> element in its <label> that cross-references #au-2_smt.a:
<label>organization-defined event types (subset of the event types defined in <a href="#au-2_smt.a">AU-2a.</a>) along with the frequency of (or situation requiring) logging for each identified event type</label>
This is the only parameter label in the entire catalog that contains a hyperlink. While au-2_smt.a is a valid part ID within the catalog, parameter labels are substituted inline into control statement prose in downstream OSCAL documents (resolved profiles, SSPs). In those contexts the #au-2_smt.a anchor target does not exist, producing a broken link.
Who is the bug affecting?
Anyone rendering an SSP or resolved profile containing AU-2 to markdown, PDF, or DOCX using OSCAL tooling (e.g., compliance-trestle).
What is affected by this bug?
Rendered SSP output for AU-2. The broken cross-reference produces:
- Broken
[AU-2a.](#au-2_smt.a) links in rendered markdown
- Non-functional hyperlinks in generated DOCX
undefined reference warnings in LaTeX/pandoc PDF generation
When does this occur?
Whenever a tool resolves a profile against this catalog and renders AU-2's control statement prose, substituting the au-2_prm_2 label inline. The anchor #au-2_smt.a only exists as a part ID within the catalog structure itself — downstream renderers don't emit per-statement-part anchors.
This affects both the JSON and XML catalog formats (the JSON equivalent is [AU-2a.](#au-2_smt.a)).
How do we replicate the issue?
-
The broken link is directly visible in the catalog source and its resolved profile outputs:
git clone --depth 1 https://github.com/usnistgov/oscal-content.git
cd oscal-content
grep 'au-2_smt.a' nist.gov/SP800-53/rev5/json/NIST_SP-800-53_rev5_catalog.json
This shows the au-2_prm_2 label containing [AU-2a.](#au-2_smt.a).
-
The link target au-2_smt.a exists as a part ID in the catalog, but when the label is substituted into control prose in downstream documents (SSPs, resolved profiles), no corresponding anchor is emitted. For example, in the resolved LOW baseline catalog already in this repo:
grep 'au-2_smt.a' nist.gov/SP800-53/rev5/json/NIST_SP-800-53_rev5_LOW-baseline-resolved-profile_catalog.json
The label with its broken link is carried through into the resolved output.
For a real-world example of being affected by this and working around it in a downstream project, see GSA-TTS/docker-trestle#74.
Expected behavior (i.e. solution)
The label should use plain text instead of a hyperlink, consistent with every other parameter label in the catalog:
<label>organization-defined event types (subset of the event types defined in AU-2a.) along with the frequency of (or situation requiring) logging for each identified event type</label>
This preserves the human-readable reference to AU-2a without relying on an anchor that only exists within the catalog's own structure.
Other Comments
The same issue exists in both the XML and JSON catalog formats (v5.2.0, last modified 2025-08-26). We searched all parameter labels in the catalog and confirmed this is the only one containing a hyperlink.
co-authored by Anthropic Claude Opus 4.6
Describe the bug
The
au-2_prm_2parameter in the SP 800-53 Rev 5 catalog has an inline<a>element in its<label>that cross-references#au-2_smt.a:This is the only parameter label in the entire catalog that contains a hyperlink. While
au-2_smt.ais a valid part ID within the catalog, parameter labels are substituted inline into control statement prose in downstream OSCAL documents (resolved profiles, SSPs). In those contexts the#au-2_smt.aanchor target does not exist, producing a broken link.Who is the bug affecting?
Anyone rendering an SSP or resolved profile containing AU-2 to markdown, PDF, or DOCX using OSCAL tooling (e.g., compliance-trestle).
What is affected by this bug?
Rendered SSP output for AU-2. The broken cross-reference produces:
[AU-2a.](#au-2_smt.a)links in rendered markdownundefined referencewarnings in LaTeX/pandoc PDF generationWhen does this occur?
Whenever a tool resolves a profile against this catalog and renders AU-2's control statement prose, substituting the
au-2_prm_2label inline. The anchor#au-2_smt.aonly exists as a part ID within the catalog structure itself — downstream renderers don't emit per-statement-part anchors.This affects both the JSON and XML catalog formats (the JSON equivalent is
[AU-2a.](#au-2_smt.a)).How do we replicate the issue?
The broken link is directly visible in the catalog source and its resolved profile outputs:
This shows the
au-2_prm_2label containing[AU-2a.](#au-2_smt.a).The link target
au-2_smt.aexists as a part ID in the catalog, but when the label is substituted into control prose in downstream documents (SSPs, resolved profiles), no corresponding anchor is emitted. For example, in the resolved LOW baseline catalog already in this repo:grep 'au-2_smt.a' nist.gov/SP800-53/rev5/json/NIST_SP-800-53_rev5_LOW-baseline-resolved-profile_catalog.jsonThe label with its broken link is carried through into the resolved output.
For a real-world example of being affected by this and working around it in a downstream project, see GSA-TTS/docker-trestle#74.
Expected behavior (i.e. solution)
The label should use plain text instead of a hyperlink, consistent with every other parameter label in the catalog:
This preserves the human-readable reference to AU-2a without relying on an anchor that only exists within the catalog's own structure.
Other Comments
The same issue exists in both the XML and JSON catalog formats (v5.2.0, last modified 2025-08-26). We searched all parameter labels in the catalog and confirmed this is the only one containing a hyperlink.
co-authored by Anthropic Claude Opus 4.6