[jmeridth]

What/Why

OSPS-BR-07.01 and OSPS-VM-02.01 list only maturity-1. Every other level 1 requirement also lists levels 2 and 3. Tools that assess a project at level 2 or 3 skip both, so a level 2 project is never checked for secrets in version control or for documented security contacts. This adds maturity-2 and maturity-3 to both, the same fix as #223, #225 and #239.

• BR-07.01 was added level 1 only in feat: add control OSPS-BR-07 for secrets management #373, and the review didn't discuss levels. BR-07.02 is level 3 only and asks for a policy, so nothing covers prevention at level 2.
• VM-02.01 became level 1 only when Added revised controls.yaml #193 converted the single level value into a list, and Revising Vuln Management controls based on feedback #205 kept it that way when renumbering.

Proof it works

go run . compile in cmd/ succeeds, and the compiled Gemara catalog passes cue vet -d '#OSPSBaseline'.

Risk

Low. Data only: two levels added to two requirements, and no requirement text changes. Projects assessed at level 2 or 3 will now be checked against these two.

AI role

Claude Opus 5.5 traced the history of both requirements and made the edit. I reviewed the findings and the diff.

Review focus

• Whether VM-03.01 is meant to replace VM-02.01 at levels 2 and 3. It assumes security contacts exist but doesn't require documenting them. Make explicit when a control builds on an earlier control #423 touches on this.
• Whether this needs a "Modified controls" entry for the next release. The earlier fixes didn't add one.

cc @trumant @SecurityCRob

[trumant]

This makes logical sense to me. Thanks for identifying and proposing a fix for the inconsistency

[SecurityCRob]

Thanks for the patch! +1

[eddie-knight]

Good catch.

Our approach doesn't leave room for anything to be level 1 only. If it's L1, it's L2 and L3 as well.