OpenSSF Scorecard hit v5.1 in 2025, the first feature release after the major v5.0.0 cut that restructured the project around "structured results." Scorecard has been the de-facto open source security health metric since its 2020 origins inside Google's open-source group, and v5.1 is a quieter but operationally important release. It adds experimental support for Azure DevOps repositories — the first non-Git-forge backend after years of GitHub-only operation — and introduces a new --file-mode flag that switches between archive-based and git-based file fetching. For practitioners scoring large internal monorepos or migrating from GitHub Enterprise to Azure DevOps, v5.1 is the version that finally makes Scorecard scoring viable across the enterprise SCM landscape.
What was the structural change in v5.0 that v5.1 builds on?
v5.0 broke the existing 19 Scorecard checks into individual heuristics — "probes" — so users can pick and choose which signals they care about rather than receiving a monolithic score. The Go package layout moved from github.com/ossf/scorecard/v4/pkg to github.com/ossf/scorecard/v5/pkg/scorecard, and the entrypoint RunScorecard was renamed to Run with an Option pattern that replaces the previous "pass every client and arg" calling convention. The new API lets a probe collect its own data from repo clients rather than relying on a central data marshaling layer. v5.1 extends this architecture by introducing a backend abstraction that decouples probes from forge-specific assumptions, which is what makes Azure DevOps support possible without a fork.
What does Azure DevOps support actually cover in v5.1?
The Azure DevOps backend in v5.1 is explicitly marked experimental and supports a subset of the standard probe set. The supported probes cover roughly two thirds of the canonical Scorecard checks — Code-Review, Contributors, Dangerous-Workflow, License, Maintained, Packaging, Pinned-Dependencies, Security-Policy, Token-Permissions, and Webhooks all work. The three notable exclusions are:
| Check | Status on Azure DevOps in v5.1 | Reason | | --- | --- | --- | | Branch-Protection | Not supported | Azure DevOps policy model differs from GitHub branch protection | | SBOM | Not supported | Releases API does not surface SBOM attachments the same way | | Signed-Releases | Not supported | Release signing in Azure DevOps requires a separate API call not yet wired |
Practitioners running v5.1 against Azure DevOps should expect a partial score with those three checks reporting "unsupported" rather than failing the run. The Scorecard team has indicated full parity is a v5.2/v5.3 goal.
What does the new --file-mode flag actually do?
--file-mode controls how Scorecard fetches the contents of a repository when probes need to read files (workflow YAML, license texts, security policies). The two modes:
# Default: download the repo as a tarball archive
scorecard --repo=github.com/example/project --file-mode=archive
# Alternative: do a partial clone via git protocol
scorecard --repo=github.com/example/project --file-mode=git
archive mode is the default because it is faster for the common case — one HTTP request to the forge's archive endpoint pulls everything probes need. The trade-off is that archive tarballs apply .gitattributes export-ignore directives, so a file marked export-ignore in .gitattributes will simply not exist in the tarball. For repositories that mark CI definitions, test fixtures, or documentation as export-ignore, archive-mode Scorecard runs produce false negatives — the probe sees "file not present" and scores accordingly. git mode does an authenticated partial clone and reads the raw working tree, producing accurate results at the cost of higher latency and more API tokens consumed per run. For Scorecard's central public-data collection job (the one that powers the public api.scorecard.dev score lookup), archive remains the default; for internal Scorecard pipelines scoring private monorepos, the release notes recommend --file-mode=git.
How is the v5 probe model exposed to consumers?
A v5 run emits a structured JSON document that lists each probe by ID, its result, the remediation hint, and the raw evidence the probe collected:
{
"date": "2025-09-30",
"repo": { "name": "github.com/example/project", "commit": "a3f...c7" },
"scorecard": { "version": "v5.1.0", "commit": "abc123" },
"probes": [
{
"id": "branchProtectionAppliesToAdmins",
"outcome": "True",
"implementation": "GitHubAPI",
"evidence": "include_admins=true on protected branch main"
},
{
"id": "tokenPermissionsArePinnedToHashes",
"outcome": "False",
"remediation": "Pin all GitHub Actions to a specific SHA, not a tag"
}
]
}
Consumers can subscribe to individual probe results rather than the legacy 0-10 aggregate score. This matters for procurement teams who, for instance, only care about Pinned-Dependencies and Signed-Releases when assessing an OSS dependency — they can ignore the aggregate and route on probe-level signals.
What is the deps.dev integration story?
Google's deps.dev service ingests Scorecard results across the public open-source ecosystem and exposes per-package scores via REST API. v5.1 results began appearing in deps.dev in late September 2025. Procurement and security teams can query https://api.deps.dev/v3alpha/systems/{system}/packages/{name}/versions/{version} and read the embedded Scorecard probe results without running Scorecard themselves. This is the practical path for enterprises that want Scorecard-style signals on the thousands of OSS dependencies in a typical SBOM without spinning up internal scoring infrastructure.
Should I upgrade from v4 right now?
Yes, with one caveat. v4 reaches end-of-life six months after v5.0, which lands the cutoff in mid-2025. The v4 API surface is permanently frozen and will not get new probe types or forge support. The migration is mechanical: go.mod import update, RunScorecard becomes Run, and any custom probe code moves to the new option pattern. The one caveat is CI integration — if your CI pipeline parses the v4 text output for grep-based gates, you must port to the v5 JSON output before the cutover, because the text output schema changed.
How Safeguard Helps
Safeguard runs Scorecard v5.1 continuously across every public dependency surfaced in customer SBOMs and ingests the probe-level results into the unified findings graph. Policy gates can reference individual probes — for example "block any dependency whose Pinned-Dependencies probe is False and whose Signed-Releases probe is False" — rather than relying on the legacy aggregate score. Griffin AI answers "show me every npm package in my SBOM with a Code-Review probe failure and more than 50,000 weekly downloads" in one query, giving security teams a prioritized maintenance list. For Azure DevOps customers, Safeguard wires v5.1's experimental backend so internal repos receive the same scoring posture as public GitHub repos, with the unsupported checks surfaced explicitly rather than silently dropped.