# Package scores

> What the OpenSSF Scorecard figure on a package page is, where it comes from, why some packages have none, and how a maintainer can raise each check — with a prompt for a coding agent.

Source: https://minimal.dev/docs/reference/scorecard

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 {#source}

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 {#no-scorecard}

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 {#improving}

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](https://github.com/ossf/scorecard/blob/main/docs/checks.md).

### Getting scanned by OpenSSF {#get-scanned}

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](https://github.com/ossf/scorecard-action#publishing-results).

### The checks

#### [Dangerous-Workflow](https://github.com/ossf/scorecard/blob/main/docs/checks.md#dangerous-workflow) {#check-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](https://github.com/ossf/scorecard/blob/main/docs/checks.md#binary-artifacts) {#check-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](https://github.com/ossf/scorecard/blob/main/docs/checks.md#branch-protection) {#check-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](https://github.com/ossf/scorecard/blob/main/docs/checks.md#code-review) {#check-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](https://github.com/ossf/scorecard/blob/main/docs/checks.md#dependency-update-tool) {#check-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](https://github.com/ossf/scorecard/blob/main/docs/checks.md#maintained) {#check-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](https://github.com/ossf/scorecard/blob/main/docs/checks.md#signed-releases) {#check-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](https://github.com/ossf/scorecard/blob/main/docs/checks.md#token-permissions) {#check-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](https://github.com/ossf/scorecard/blob/main/docs/checks.md#vulnerabilities) {#check-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](https://github.com/ossf/scorecard/blob/main/docs/checks.md#fuzzing) {#check-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](https://github.com/ossf/scorecard/blob/main/docs/checks.md#packaging) {#check-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](https://github.com/ossf/scorecard/blob/main/docs/checks.md#pinned-dependencies) {#check-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](https://github.com/ossf/scorecard/blob/main/docs/checks.md#sast) {#check-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](https://github.com/ossf/scorecard/blob/main/docs/checks.md#security-policy) {#check-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](https://github.com/ossf/scorecard/blob/main/docs/checks.md#ci-tests) {#check-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](https://github.com/ossf/scorecard/blob/main/docs/checks.md#cii-best-practices) {#check-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](https://github.com/ossf/scorecard/blob/main/docs/checks.md#contributors) {#check-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](https://github.com/ossf/scorecard/blob/main/docs/checks.md#license) {#check-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 {#agent-prompt}

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.

```text
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.
```