Ran the OpenSSF Baseline audit (audit_openssf_baseline, level 3, OSPS v2026.02.19) against a private GitHub repository - a governance-first monorepo where every push carries signed evidence, main is behind a ruleset requiring PR + two status checks, actions are SHA-pinned, dependencies are exactly pinned and allowlisted, CODEOWNERS is in place. Result: 26 pass / 21 fail / 17 warn / 2 error. Most of the fails are the baseline being shaped for public open-source projects, which makes the score misleading for the growing class of private, agent-heavy repos that arguably need this tooling most.
Fails that don't apply to a private repo, or can't
OSPS-LE-01/03 LICENSE, GV-03 CONTRIBUTING, DO-03/04/05 SUPPORT / EOL / release verification, QA-02.02 SBOM in releases, DO-02 bug-report template - all release/community surface a private repo may legitimately not have (yet).OSPS-VM-03.01 "enable private vulnerability reporting" - the GitHub feature is unavailable on private repos (/private-vulnerability-reporting returns 404). The check can't pass; it should be N/A or accept a SECURITY.md contact instead.
False positives worth fixing regardless of profile
OSPS-QA-05.01/05.02 "generated executables / binaries in repository" flagged 1,281 and 64,997 files - all under gitignored target/ and __pycache__/. The check scans the working tree; it should scan tracked files (git ls-files) or honour .gitignore.OSPS-SA-01.01 "no architecture documentation" - the repo has design/*.md (component maps + an SDLC overview). The pattern seems to want ARCHITECTURE.md specifically.OSPS-DO-06.01 "dependency management process not documented" - the repo has a reviewed dependency-allowlist.yaml with a per-dependency why: and a CI check that fails on any unlisted dependency. The pattern seems to want a prose DEPENDENCIES.md.
What a private profile could emphasise instead
The controls that actually distinguish a well-run private repo, several of which the baseline already has and which did pass here: branch protection with required checks (AC-*, BR-*), SHA-pinned actions, pinned + reviewed dependencies (BR-05/06), CODEOWNERS (GV-01/04), workflow linting (BR-01 via zizmor - which is also currently an ERROR: Command not found when zizmor isn't installed, rather than a skip with guidance), secret scanning, signed commits or signed evidence on push, and - increasingly relevant - distinct identities for automated/agent contributors, so "who authored this" is answerable.
Happy to provide the full JSON report or test a candidate profile against this repo.
Ran the OpenSSF Baseline audit (
audit_openssf_baseline, level 3, OSPS v2026.02.19) against a private GitHub repository - a governance-first monorepo where every push carries signed evidence,mainis behind a ruleset requiring PR + two status checks, actions are SHA-pinned, dependencies are exactly pinned and allowlisted, CODEOWNERS is in place. Result: 26 pass / 21 fail / 17 warn / 2 error. Most of the fails are the baseline being shaped for public open-source projects, which makes the score misleading for the growing class of private, agent-heavy repos that arguably need this tooling most.Fails that don't apply to a private repo, or can't
OSPS-LE-01/03LICENSE,GV-03CONTRIBUTING,DO-03/04/05SUPPORT / EOL / release verification,QA-02.02SBOM in releases,DO-02bug-report template - all release/community surface a private repo may legitimately not have (yet).OSPS-VM-03.01"enable private vulnerability reporting" - the GitHub feature is unavailable on private repos (/private-vulnerability-reportingreturns 404). The check can't pass; it should be N/A or accept aSECURITY.mdcontact instead.False positives worth fixing regardless of profile
OSPS-QA-05.01/05.02"generated executables / binaries in repository" flagged 1,281 and 64,997 files - all under gitignoredtarget/and__pycache__/. The check scans the working tree; it should scan tracked files (git ls-files) or honour.gitignore.OSPS-SA-01.01"no architecture documentation" - the repo hasdesign/*.md(component maps + an SDLC overview). The pattern seems to wantARCHITECTURE.mdspecifically.OSPS-DO-06.01"dependency management process not documented" - the repo has a revieweddependency-allowlist.yamlwith a per-dependencywhy:and a CI check that fails on any unlisted dependency. The pattern seems to want a proseDEPENDENCIES.md.What a
privateprofile could emphasise insteadThe controls that actually distinguish a well-run private repo, several of which the baseline already has and which did pass here: branch protection with required checks (
AC-*,BR-*), SHA-pinned actions, pinned + reviewed dependencies (BR-05/06), CODEOWNERS (GV-01/04), workflow linting (BR-01via zizmor - which is also currently anERROR: Command not foundwhen zizmor isn't installed, rather than a skip with guidance), secret scanning, signed commits or signed evidence on push, and - increasingly relevant - distinct identities for automated/agent contributors, so "who authored this" is answerable.Happy to provide the full JSON report or test a candidate profile against this repo.