OpenSSF Scorecard

Skip to content What this pays This project runs no bounty of its own. sorona.xyz pays you directly on qualified, reproduced findings. Severity │ sorona.xyz pays Critical │ $1,500+ High │ $700+ Medium │ $300+ Low │ $100 / 1 month Claude Max Submit a vulnerability Separately, for a merged upstream patch : up to $5,000 Google Patch Rewards pays for a patch you land upstream yourself and that stays merged, without reverts, for one month. It does not pay for the report. This project sits in Tier 2, where awards run from $100 to $5,000; the $15,000 headline is the Tier 1 column and is not reachable here. Patches must be between one and twelve months old, submissions are capped at three per person per month, memory-safety hardening can carry a 2× or 3× multiplier, and sanctions and territory exclusions apply. Latest advisories Loading the feed Overview Scorecard measures the supply-chain posture of other people's repositories. The OpenSSF runs it across hundreds of thousands of projects for the public dataset, and the GitHub Action variant runs inside the CI of the repository being scored, holding that repository's credentials. Its exposure is inverted from a normal library: the whole job is parsing content nobody controls, so a parser or command-injection defect there compromises the tool built to detect supply-chain compromise. No CVE has ever been filed against it, on a tool sitting in tens of thousands of pipelines. The OpenSSF and the Linux Foundation pay nothing for a report, so sorona.xyz pays you directly on qualified, reproduced findings. In scope Reports go to [email protected] under the Linux Foundation's standard security process. The one thing the project rules out by name is a disagreement about how a check scores a repository The whole check and probe layer, meaning every implementation that parses third-party repository content: GitHub Actions workflow YAML, Dockerfiles, dependency manifests and SBOMs, none of which Scorecard controls The parsing libraries underneath those checks, including the YAML and probe paths that carry the two OSS-Fuzz harnesses ( yaml_fuzzer.go and probes_fuzzer.go ) The GitHub, GitLab and Azure DevOps API clients in full, covering how they authenticate and how they store, scope and log their tokens scorecard-action , the GitHub Action wrapper that executes inside the CI of the repository being scored, with that repository's credentials in the environment The signing and attestation path into the Scorecard results API and the public BigQuery dataset, where a forged or mis-attributed result poisons a dataset other tooling trusts The command-line tool and its output handling, which is what maintainers and vendor-risk tooling actually invoke Out of scope Disagreements about check scoring methodology, which are policy debates rather than vulnerabilities The scorecard-webapp deployment as a hosted service, as distinct from the code in its repository Non-exploitable crashes whose fix is a one-liner, which Google explicitly declines to reward on the patch rail Patches over twelve months old, which Patch Rewards will not consider For the Google money specifically, anything reported but never patched upstream, since that pathway pays only on a merge Most-valued findings Command injection or argument smuggling reachable from repository content Scorecard parses, since scorecard-action runs inside someone else's CI with their token and that is the highest-consequence outcome this codebase can produce Parser defects in the workflow YAML, Dockerfile or manifest readers, 35% of the expected bug mass and the surface the project already fuzzes, which makes a patch straightforward to land Token handling failures in the GitHub, GitLab or Azure DevOps clients that leak or over-scope credentials into logs, artifacts or outbound requests A way to make a scored repository influence its own result, or another repository's, through the signing and attestation path into the results API Access-control flaws that let repository-supplied content reach an authenticated call it should never have been able to make Program rules Submit through sorona.xyz. This project runs no bounty of its own; we validate, coordinate disclosure with the maintainers, and pay you directly. Send a detailed, reproducible report with the repository content, workflow file or manifest that triggers the defect; if the maintainers can't reproduce it, it isn't eligible One vulnerability per report unless a chain is needed to show the real impact Disagreements about how a check scores a repository are policy arguments rather than vulnerabilities, and are not eligible Give the maintainers room to ship a fix before any public writeup; Scorecard follows the Linux Foundation's standard security process If you also want the Google patch money, land the fix upstream yourself and keep it merged without reverts for a month; the patch must be between one and twelve months old and you may submit at most three a month Google cannot pay researchers on sanctions lists, in sanctioned territories, or located in Russia or Belarus Disclosure Coordinated with the OpenSSF through [email protected] under the Linux Foundation's standard security process, with the fix landing in a Scorecard release. Nothing in the Google rules restricts routing the finding through sorona.xyz; hold the detail until the release is out, since the Action auto-updates into other people's CI. Safe harbor Sorona will not pursue legal action against you for good-faith research submitted to us in line with this policy. We cannot speak for the upstream project, its vendor, or any third party, and we do not grant authorization on their behalf. You are responsible for understanding and following the laws that apply to you, wherever you are, and for staying within any scope the project has defined. Submit a vulnerability