Scorecard

Attaches the latest OpenSSF Scorecard run to packages whose source repository is on github.com. It is opt-in: select it with --matchers +scorecard next to --enrich. It needs no GitHub token because it reads precomputed runs from api.scorecard.dev.

What scorecard does

scorecard fetches the latest OpenSSF Scorecard run for every package whose source repository resolves to a github.com/{owner}/{repo} URL, and attaches the result to the package.

A Scorecard run rates a project's security practices: branch protection, dependency-update tooling, signed releases, fuzzing, a SECURITY.md, and more. The matcher does not run the checks itself. It reads the scores the OpenSSF publishes weekly at api.scorecard.dev, so it is fast, needs no GitHub credentials, and adds no heavy dependencies.

When it runs

scorecard is opt-in and does not run under plain --enrich. Select it explicitly:

bomly scan --enrich --matchers +scorecard

Keeping it opt-in avoids surprising users with extra latency (one HTTP call per unique repository) and keeps the default enrichment set stable.

Repository resolution

For each package, the matcher looks for a github.com source repository in this order:

1. The repository_url, vcs_url, or download_url qualifier on the package URL.
2. A package URL of type github (pkg:github/{owner}/{repo}@...).
3. A package URL of type golang whose module path begins with github.com/.
4. The package's resolvedUrl when it points at github.com, which is common for npm tarballs.

Packages with no resolvable github.com source are skipped silently. So are packages hosted elsewhere (GitLab, Bitbucket, internal Git). Packages that share one source repository, for example a monorepo, are fetched once, and the result is attached to every package that maps to it.

Network

The cache directory on Unix and macOS is ~/.bomly/cache/scorecard/. A cache failure is logged as a warning and never stops the scan. A repository the OpenSSF has not scored returns HTTP 404. The matcher caches that answer for the TTL, so unscored repositories are not retried on every run.

Each successful response is limited to 4 MiB. A larger response fails with a clear size error. A failed HTTP response reports the status code without copying the remote response body into errors or logs.

Output fields

When attached, package.scorecard holds:

• source: "api.scorecard.dev"
• repository: "github.com/{owner}/{repo}"
• commitSha: the commit Scorecard scored
• scorecardVersion: the Scorecard tool version that produced the run
• runDate: the ISO timestamp of the run
• aggregateScore: the overall score from 0.0 to 10.0 (a negative value means inconclusive)
• checks[]: one entry per check with name, score, reason, and a documentation link

The text report adds a "Project Posture" section listing each unique repository with its score, run date, Scorecard version, and the number of packages it covers.

Examples

List project scores from a scan

bomly scan --enrich --matchers +scorecard --json | jq '.graph.packages[] | select(.scorecard) | {name, score: .scorecard.aggregateScore}'

Inspect why a package scored as it did

bomly explain does not show Scorecard data yet. Read the JSON output, or open the Scorecard viewer at https://scorecard.dev/viewer/?uri=github.com/{owner}/{repo}.

Limitations

• github.com only. Projects hosted on GitLab, Bitbucket, Codeberg, or internal Git servers are skipped.
• Sparse coverage for niche projects. The OpenSSF runs Scorecard on a large but not complete set of repositories. A less popular dependency may return 404.
• Weekly refresh, not on demand. The scores reflect the most recent OpenSSF run, not the current state of the repository.
• No deps.dev fallback yet. A package whose source repository only appears in registry metadata (the npm repository field, PyPI Home-page, Maven SCM) is skipped.
• Signal only. The policy auditor does not evaluate Scorecard data. There is no --fail-on gate for a score.