Skip to content

au-2_prm_2 parameter label propagates unresolvable hyperlink to consumers #328

Description

@mogul

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?

  1. 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).

  2. 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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    Status
    Needs Triage

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions