access_control audit profile lists three undefined controls and omits OSPS-AC-04.01/04.02 #581

Summary

The access_control audit profile in openssf-baseline.toml lists three controls the framework does not define, and leaves out two that it does.

[audit_profiles.access_control]
description = "Access control domain — branch protection, MFA, permissions"
controls = [
    "OSPS-AC-01.01", "OSPS-AC-01.02", "OSPS-AC-01.03",
    "OSPS-AC-02.01", "OSPS-AC-02.02",
    "OSPS-AC-03.01", "OSPS-AC-03.02",
]

The AC controls the baseline defines are OSPS-AC-01.01, 02.01, 03.01, 03.02, 04.01 and 04.02.

Effect

• darnit profiles reports the profile as "7 controls".
• An audit with the profile runs 4. (On main the CLI ignores --profile altogether; this is with fix(cli): make darnit audit --profile filter the controls #576, which connects it. The MCP tools already apply profiles, so they are affected today.)
• Nothing reports the gap. fix(cli): make darnit audit --profile filter the controls #576 adds a warning that names listed controls the framework does not define.
• A user who picks "access control" does not get the two AC-04 controls.

Why the tests pass

tests/darnit_baseline/test_profiles.py has test_access_control_profile and test_profile_control_ids_resolve. Both assert only that at least one ID is present or resolves, and that every ID starts with OSPS-AC-. Neither checks that each listed ID is a defined control.

Suggested direction

• Make the profile tag-based, like the other two: tags = { domain = "AC" }. That selects the six AC controls today and cannot go stale when controls are added or renumbered. If an explicit list is wanted instead, correct it to the six above.
• Add a test, over every shipped framework, that each ID a profile lists is a defined control.

I can send the PR if you agree with the tag-based form. I have not, because which controls belong in the profile is a content decision.

Environment

darnit main at 24a4fed.

Drafted with Claude; reviewed and filed by me.