Package scores
A package page shows the project’s OpenSSF Scorecard result: the aggregate score out of 10, who ran the scan, the repository that was scored, the scan date, and each check’s score exactly as the Scorecard tool reports it. OpenSSF Scorecard is an open source project of the Open Source Security Foundation. We do not regroup, reweight or rescale anything.
Where the score comes from
OpenSSF scans public GitHub repositories weekly and publishes the results. Where that scan covers a package’s repository, the card shows OpenSSF’s result and links to it on scorecard.dev.
Where it does not, Minimal runs the same Scorecard tool itself each week; those runs include CI-Tests, Contributors and Dependency-Update-Tool, which OpenSSF’s scan leaves out, so the figure can differ from scorecard.dev.
The gauge’s colour is our presentation, not OpenSSF’s: the score is banded green from 8, yellow from 4, red below that, with a bolder green at a perfect 10.
The card shows the date of the scan it holds. OpenSSF may have rescanned since, so the figure here can trail scorecard.dev until our copy refreshes; the scan date tells you how old it is.
Why some packages have no score
OpenSSF Scorecard analyses a source repository. We track where each package is published from, and for some sources there is no repository to analyse — so no score can exist, now or later. Those packages show no figure, and the card says why.
- Sources a scorecard can cover: GitHub repository (GitLab repositories are scoreable by the tool but not yet scanned by Minimal, so they show the generic empty state)
- Sources with no repository to analyse: GNU project, SourceForge, Project website
A package from a supported source that still shows no score is a gap in our data, not a judgement on the project.
Improving your score
If you maintain a project in the catalog, the figure moves when OpenSSF Scorecard’s checks do. The guidance below is summarised from OpenSSF’s own check documentation, ordered by the risk level OpenSSF assigns each check, and links to the full upstream text. OpenSSF Scorecard check documentation.
Getting scanned by OpenSSF
OpenSSF’s Scorecard GitHub Action is free for public repositories. Run it with publish_results: true and the id-token: write permission on its job, and your own scan results replace OpenSSF’s weekly scan for the repository, appear on OpenSSF’s API and scorecard.dev, and enable OpenSSF’s badge. OpenSSF’s API rejects results from a workflow that breaks its restrictions — for one, no write permissions at workflow level — so follow the action’s documentation. OpenSSF Scorecard Action documentation.
The checks
Dangerous-Workflow
OpenSSF risk: Critical · Code change
What it looks for GitHub Actions workflows that check out pull-request code under a pull_request_target or workflow_run trigger, or that let untrusted context values such as an issue title reach an inline script.
What raises it Remove both patterns from every workflow. The top score needs all workflows clean.
Binary-Artifacts
OpenSSF risk: High · Code change
What it looks for Generated executables committed to the repository — compiled binaries, .class and .pyc files and the like. Reviewable scripts and generated source do not count.
What raises it Remove the generated artifacts and build them from source.
Branch-Protection
OpenSSF risk: High · Repository settings
What it looks for Branch protection or rulesets on the default and release branches, scored in tiers: no force-push or deletion first, then required review, required status checks, a second reviewer and code-owner review.
What raises it Enable the rules in the repository’s settings. This needs a repository admin; no commit can do it.
Code-Review
OpenSSF risk: High · Review process
What it looks for Whether the last 30 or so changes were approved by a reviewer, or merged by someone other than their author. Reviews by bots do not count.
What raises it Review changes before merging, and require review in the branch rules. OpenSSF notes that a project with one active maintainer may not be able to meet this.
Dependency-Update-Tool
OpenSSF risk: High · Code change
What it looks for A Dependabot or Renovate configuration in the repository. It checks that the tool is enabled, not that its pull requests get merged.
What raises it Commit a Dependabot or Renovate configuration file covering the ecosystems the repository uses.
Maintained
OpenSSF risk: High · Activity over time
What it looks for Activity over the previous 90 days: at least one commit a week earns the top score, maintainer activity on issues earns partial credit, and an archived repository scores lowest. A repository younger than 90 days cannot pass.
What raises it Nothing to change. OpenSSF lists no remediation — the check reports activity, and only continued activity moves it.
Signed-Releases
OpenSSF risk: High · Release process
What it looks for Signature files (.asc, .sig, .sign, .minisig, .sigstore, .sigstore.json) attached to the last five releases score 8; SLSA provenance (.intoto.jsonl) on each scores 10. Signatures are not verified.
What raises it Sign release artifacts in the release workflow and attach the signatures or provenance to each release. The score moves as new releases are published.
Token-Permissions
OpenSSF risk: High · Code change
What it looks for Whether each workflow sets read-only permissions at the top level and grants write permissions per job. The repository-wide default-permissions setting is invisible to the check.
What raises it Set top-level permissions to contents: read (or read-all) in every workflow file, and declare any write scope on the job that needs it.
Vulnerabilities
OpenSSF risk: High · Code change
What it looks for Open, unfixed vulnerabilities in the project’s code or its dependencies, according to OSV.
What raises it Fix the vulnerability or update the affected dependency. One that does not apply can be ignored by ID, with a reason, in an osv-scanner.toml file.
Fuzzing
OpenSSF risk: Medium · Code change
What it looks for A listing in OSS-Fuzz, a ClusterFuzzLite deployment, or language-native fuzz or property-based tests (Go fuzzing, and a limited set of libraries for Haskell, JavaScript and TypeScript, Erlang, C# and F#).
What raises it Integrate with OSS-Fuzz — an application to that project — or add ClusterFuzzLite or native fuzz tests to the repository.
Packaging
OpenSSF risk: Medium · Release process
What it looks for Whether the project is published as a package, detected from GitHub packaging workflows and language-specific publishing actions. Other ways of publishing may go undetected.
What raises it Publish releases as a package from a GitHub workflow, such as GitHub Packages or a language registry.
Pinned-Dependencies
OpenSSF risk: Medium · Code change
What it looks for Dependencies in Dockerfiles, shell scripts and GitHub workflows that are not pinned to a hash.
What raises it Pin GitHub Actions to full commit SHAs and container images to digests, and use a dependency update tool to keep the pins current.
SAST
OpenSSF risk: Medium · Code change
What it looks for CodeQL or SonarCloud runs on recently merged pull requests, or github/codeql-action in a workflow. Other static analysis tools may go undetected.
What raises it Add a CodeQL workflow that runs on pull requests.
Security-Policy
OpenSSF risk: Medium · Code change
What it looks for A SECURITY.md file, scored on its contents: a reporting email or link (6 points), explanatory text beyond the link (3), and wording about vulnerability disclosure with a timeline (1).
What raises it Add SECURITY.md to the repository root with a private way to report a vulnerability, what counts as one, and when a reporter can expect a response.
CI-Tests
OpenSSF risk: Low · Code change
What it looks for Whether tests ran before recent pull requests were merged, detected from recognised CI system names on the last 30 or so commits.
What raises it Check in scripts that run the tests, and run them in CI on every pull request.
CII-Best-Practices
OpenSSF risk: Low · External application
What it looks for An OpenSSF Best Practices badge for the repository: in progress scores 2, passing 5, silver 7, gold 10.
What raises it A maintainer applies at bestpractices.dev and answers its criteria. It is a self-certification, not a code change.
Contributors
OpenSSF risk: Low · Activity over time
What it looks for Recent contributors from at least three organizations, read from the Company field of each commit author’s GitHub profile.
What raises it Nothing to change in the repository. OpenSSF lists no remediation beyond contributors recording their organization on their profile.
License
OpenSSF risk: Low · Code change
What it looks for A license file under a conventional name (6 points), in the top-level directory (3), naming an FSF- or OSI-approved license (1).
What raises it Add a LICENSE file to the repository root for the license the project actually uses.
What a commit cannot fix
Several checks do not respond to a code change. Maintained and Contributors reflect activity over time. CII-Best-Practices needs a badge application. Branch-Protection and required review are repository settings only an admin can change. Code-Review reflects how recent changes were actually merged. A low score on these is not something to patch around.
A prompt for your coding agent
Paste this into any coding agent running in a checkout of your repository, replacing <owner>/<repo> with the repository’s GitHub path. It asks for one pull request per check and for a list of what it could not fix, so nothing is changed silently.
If your package’s card says it was scored by Minimal, OpenSSF’s API has no result for the repository, and the prompt tells the agent to run the Scorecard tool itself.
You are working in a checkout of the GitHub repository <owner>/<repo>.
Goal: raise its OpenSSF Scorecard result with small, reviewable changes.
1. Fetch the current result:
https://api.securityscorecards.dev/projects/github.com/<owner>/<repo>
If that returns 404, OpenSSF has not scanned this repository. Run the
Scorecard CLI from https://github.com/ossf/scorecard against it
instead, or stop and say that you need a result to work from.
2. List every check scoring below 10. Skip checks scored -1: Scorecard
could not evaluate them. Rank the rest by the risk level OpenSSF
assigns each check in
https://github.com/ossf/scorecard/blob/main/docs/checks.md
(Critical, then High, Medium, Low), lowest score first within a level.
Read each check's "details" array: it names the files and lines at
fault.
3. Fix what a change to this repository can fix, following the
remediation steps in checks.md. Typical fixes:
- Dangerous-Workflow: remove pull-request checkouts from
pull_request_target / workflow_run workflows, and stop untrusted
context values reaching inline scripts.
- Token-Permissions: set top-level "permissions: contents: read" (or
read-all) in every workflow, and grant write scopes per job only
where that job needs them.
- Pinned-Dependencies: pin GitHub Actions to full commit SHAs (keep
the version as a trailing comment) and container images to digests.
- Dependency-Update-Tool: add a Dependabot or Renovate configuration
covering every ecosystem in the repository, GitHub Actions included.
- Security-Policy: add SECURITY.md with a private reporting contact,
what counts as a vulnerability, and a disclosure timeline. Ask me
for the contact; do not invent one.
- SAST: add a CodeQL workflow for the languages present.
- Binary-Artifacts: remove committed build outputs that can be built
from source, and say so in the pull request.
- License: if there is no top-level license file, ask me which
license applies. Never choose one yourself.
- CI-Tests, Fuzzing, Signed-Releases: propose a workflow only when
the repository already has the tests, fuzz targets or release
process it would run.
4. Open one focused pull request per check, never one sweeping change.
In each, name the check, quote the finding, and explain why the
change addresses it. Run the existing tests and linters first. Do not
change application behaviour, and do not weaken a check to make it
pass.
5. Finish with a list of every check you could NOT raise, and why. Some
cannot be fixed from a checkout:
- Branch-Protection and required reviews are repository settings
that need an admin.
- Code-Review reflects how recent changes were actually merged.
- Maintained and Contributors reflect activity over time.
- CII-Best-Practices needs a maintainer to apply for the OpenSSF
Best Practices badge at https://www.bestpractices.dev/.
- Signed-Releases only moves as new signed releases are published.
For each, tell me the exact setting or step a maintainer has to take.