OSSF Scorecard for Your Own Repositories: What the Checks Tell You

Security teams use the OSSF Scorecard to judge other people's code. Before adopting an open-source package or a third-party GitHub Action, someone checks whether the project protects its main branch, pins its dependencies and signs its releases. It is a sensible habit.

The same checks, pointed at your own repositories, are one of the fastest ways to find weak spots in your software supply chain. A default branch anyone can push to, a workflow that runs untrusted pull request code with write tokens, an action pulled by a mutable tag: none of these show up as a CVE, and all of them are how real supply-chain incidents start.

This post walks through what the OSSF Scorecard measures, which checks matter most when you run it against your own estate, how to read the results without chasing a perfect 10, and how to turn the score into work.

What the OSSF Scorecard is

The OpenSSF Scorecard is an open project from the Open Source Security Foundation that runs automated checks against a repository and scores each one from 0 to 10. The checks look at source control settings, CI configuration, release practice and project health. Each result comes with a reason, which is the part that makes it useful: "branch protection not enabled on the default branch" is a task, not just a number.

The full list of checks and their scoring logic is documented in the project's checks reference. The overall score is a weighted aggregate, with checks that indicate higher risk carrying more weight.

Why score your own repositories

Scorecard was designed with open-source consumers in mind, but the questions it asks apply to any repository that builds software your customers run:

• Can a change reach production unreviewed? That is a code integrity question, whether the code is public or not.
• Can a pull request compromise your CI? Workflow misconfigurations are an attack path into your build and your cloud credentials.
• Can your build be poisoned through a dependency you did not pin? Mutable references mean yesterday's reviewed code is not necessarily today's.
• Would you know if a dependency had a known vulnerability? Some projects have never checked.

Scoring your own estate also gives security and engineering a shared, neutral language. A score from a public standard is harder to dismiss than a finding from an internal policy.

The checks that matter most for internal repositories

Not every check carries the same weight for private code. These are the ones worth acting on first.

Branch-Protection and Code-Review

These two answer the most important question: can a change land on the default branch without a second person looking at it? Branch-Protection examines the protection settings on your default and release branches, such as required reviews and restrictions on force pushes. Code-Review looks at recent history to see whether changes were actually reviewed before merge. GitHub's documentation on protected branches covers the settings involved.

A low score here on a tier-one service is the most urgent result the Scorecard can give you.

Token-Permissions

This check looks at whether GitHub Actions workflows declare least-privilege token permissions. A workflow that inherits a broad default GITHUB_TOKEN gives every step, including every third-party action, write access it does not need. The fix is usually a few lines of YAML:

permissions: {contents: read}

Set a read-only default at the top of the workflow and grant write scopes only to the jobs that need them.

Dangerous-Workflow

This flags patterns that let untrusted input run with privilege, such as a pull_request_target workflow that checks out and executes code from a fork. GitHub Security Lab's write-up on preventing pwn requests explains the attack in detail. Any hit here deserves immediate attention.

Pinned-Dependencies

This checks whether dependencies are pinned to immutable references: GitHub Actions by full commit SHA, container images by digest, and install scripts that do not pull whatever the network serves at run time. A tag like v4 can be moved. A SHA cannot. For example:

uses: actions/checkout@v4 becomes uses: actions/checkout@<full-length-commit-sha> # v4

The reason text is often the most concrete in the whole report, telling you exactly how many GitHub-owned and third-party actions are pinned by SHA.

Vulnerabilities and SAST

Vulnerabilities checks whether the project has open, known vulnerabilities, using the OSV database. SAST checks whether static analysis runs on changes. For an internal estate, the useful reading is less "do we have findings" and more "is anything looking at this repository at all".

Checks that matter less, or read differently, for private code

Some checks were built around public open-source norms. Read them with that in mind:

• License. Important for published libraries, rarely relevant to a private service.
• CII-Best-Practices. Tracks the OpenSSF Best Practices badge, which internal projects seldom apply for.
• Contributors. Measures contributor diversity across organizations. An internal repository will naturally score low.
• Fuzzing. Valuable for parsers and security-critical libraries, less so for most CRUD services.
• Signed-Releases and Packaging. Matter a great deal for anything you publish as a package or artifact, and not at all for code that never ships one.

A check that does not apply should read as not applicable, not as a failure. An unreleased project has nothing to sign.

How to read a Scorecard without gaming it

The overall score is a summary, not a target. A repository at 7.2 with branch protection off is in worse shape than one at 5.8 that fails only on license and fuzzing. Three habits keep the score honest:

1. Read the reasons, not the number. The reason names the file or setting. That is your task list.
2. Weight by what the repository builds. A low score on a tier-one production service matters more than the same score on an internal prototype.
3. Track change over time. A score that drops after a reorganization or a CI migration is a signal that a control was lost.

A remediation plan for your repository estate

1. Score everything. Every repository in every organization, not only the ones someone remembered to add.
2. Sort tier-one services by Branch-Protection and Code-Review. Fix those first. They are usually settings changes, not code changes.
3. Sweep workflows for Dangerous-Workflow and Token-Permissions. These are the checks that describe an active path to compromise.
4. Pin actions and images. Start with third-party actions, which are the higher risk.
5. Enforce new work. Once the estate is clean, gate new pull requests that introduce unpinned actions or broad token permissions, so the score does not drift back.
6. Review quarterly. Export the estate, compare against last quarter and chase regressions.

Scorecard for what you consume, and for what you ship

Most teams start with Scorecard as a gate on adoption: check a package or an action before it enters the estate. Scoring your own repositories closes the other half of the loop. The same questions apply in both directions, and the answers feed each other. If your own workflows pin third-party actions by SHA and restrict token permissions, a compromised upstream action has far less room to do damage. If your default branches are protected, a stolen developer token cannot push straight to production. Treat the two as one control, measured from both sides.

How Heeler brings OSSF Scorecard to your repositories

In Heeler, every repository it analyzes carries an OSSF Scorecard, on both GitHub and GitLab. Open a repository in the Catalog and the OSSF Scorecard tab shows the overall score out of 10, the number of checks evaluated and when the repository was last scanned. The score also appears on the repository header.

Scores are computed from the repository's own files, configuration and history, not from a published badge, so a private repository that has never been scored anywhere still gets one. Seventeen checks are evaluated, covering source integrity, build and release practice, and project health, each with its own score, a Pass, Fail or N/A status and the reason behind it. N/A means the signal was not available for that repository, not that it failed.

The score is included in the repositories CSV export, which is how you rank the whole estate in one pass or track it over a quarter. The same supply-chain lens applies to what you consume: Heeler also scores the GitHub Actions and open-source dependencies your repositories pull in. See the OSSF Scorecard docs, Software Supply Chain Security and CI/CD Security.

FAQ

What is the OSSF Scorecard?

The OSSF Scorecard is an open-source tool from the Open Source Security Foundation that scores a repository's security practices from 0 to 10 across checks such as branch protection, code review, pinned dependencies and token permissions.

Can you run OSSF Scorecard on private repositories?

Yes. The checks read repository settings, files and history, which are available for private repositories to anyone with the right access.

Which OSSF Scorecard checks matter most?

For internal code, Branch-Protection, Code-Review, Dangerous-Workflow, Token-Permissions and Pinned-Dependencies describe the most direct paths to compromise and are usually the cheapest to fix.

What is a good OSSF Scorecard score?

There is no universal threshold. Read the individual check reasons and weight them by what the repository builds, rather than chasing an overall number.

How do I improve Pinned-Dependencies?

Reference GitHub Actions by full commit SHA and container images by digest, and keep a comment with the human-readable version next to each pin.

Score your estate

You already hold open-source projects to the Scorecard bar. Holding your own repositories to it is where the supply-chain gaps you control actually live. See the OSSF Scorecard for every repository you own, next to everything else Heeler knows about it. Get a demo.