Sigstore

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 get accepted upstream and that stays merged, without reverts, for one month. It does not pay for the report. This is a Tier 2 project, in scope through its OSS-Fuzz integration, so $5,000 is the reachable ceiling; the $15,000 headline and the 2× and 3× memory-safety multipliers are Tier 1 only. Awards start at $100, the patch has to be between one and twelve months old, submissions are capped at three per person per month, and one-liner fixes for non-exploitable crashes are not rewarded. Sanctions and territory exclusions apply. CVE history 15 Last 12 months 26 Lifetime Auth bypass 35 % Parsing/validation 30 % Denial of service 20 % Info disclosure 10 % Latest advisories Loading the feed Overview Sigstore is the signing and transparency substrate underneath npm provenance, PyPI attestations, Homebrew bottles, Kubernetes release artifacts and a growing share of container images, and cosign verify runs inside the admission controllers that decide what may start in production Kubernetes clusters: Kyverno, OPA Gatekeeper, Connaisseur. It is the trust anchor rather than one more dependency. A verification bypass in cosign silently converts every downstream claim that an artifact is signed into a false statement, across several language ecosystems at once. Fifteen advisories in the last twelve months make it the most actively vulnerable cluster in the supply-chain corpus for its size. The project pays nothing for a report, so sorona.xyz pays you directly on qualified, reproduced findings. In scope Reports go to the Sigstore security team at [email protected] , and coverage here runs to the six Sigstore repositories in the OSS-Fuzz integration: cosign, rekor, sigstore, sigstore-go, sigstore-java and sigstore-python. Everything below sits inside those trees cosign in full, verification logic first: certificate identity and issuer matching, --certificate-identity and --certificate-oidc-issuer enforcement, and the keyless verification paths rekor in full, covering transparency-log integrity: inclusion proofs, signed entry timestamps, checkpoint and consistency-proof handling, and the Merkle tree operations underneath them The client libraries end to end, sigstore-go, sigstore-python and sigstore-java, including protobuf bundle deserialization from attacker-supplied input Bundle and attestation parsing wherever it happens, together with the SLSA provenance and in-toto predicate validation built on top of it OCI registry interaction and attachment resolution through the .sig and .att tags, including confusion between a subject digest and the attachment bound to it TUF root-of-trust handling and trusted-root refresh, the material every later verification is measured against Out of scope sigstore/fulcio , which is not an OSS-Fuzz project and carries no Patch Rewards coverage, so no money reaches it on this pathway Availability or abuse of the public-good Rekor log and Fulcio CA as running services, as opposed to defects in the code that implements them Policy decisions a downstream verifier makes about which identities to trust, as opposed to defects in the Sigstore libraries themselves Key-compromise scenarios where the attacker already controls the signing identity, which sits inside the trust boundary rather than breaking it Reports with no merged upstream patch behind them, which earn nothing on the Google pathway even though sorona.xyz still pays for the finding One-liner fixes for non-exploitable crashes, which the reward rules place below the bar regardless of which repository they land in Most-valued findings Certificate identity or issuer matching in cosign that can be made to pass for the wrong signer, so a hostile artifact verifies. The auth-bypass class is the largest here and this is the shape that reaches every admission controller running cosign verify Rekor inclusion-proof, checkpoint or signed-entry-timestamp verification that accepts a forged or inconsistent entry, which breaks the transparency guarantee the whole design rests on Protobuf bundle or attestation deserialization flaws in sigstore-go, sigstore-python or sigstore-java reachable purely from an attacker-supplied bundle OCI attachment resolution confusion where the signature or attestation actually verified is a different one from that bound to the subject digest the caller asked about TUF trusted-root refresh handling that lets an attacker substitute the trust material, since that compromises every verification performed afterwards rather than one artifact 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 to the Sigstore security team at [email protected] ; if the team cannot reproduce it, it is not eligible Coverage runs to the six Sigstore projects integrated into OSS-Fuzz: cosign, rekor, sigstore, sigstore-go, sigstore-java and sigstore-python. sigstore/fulcio is not one of them Give the maintainers room to ship a fix and publish their GitHub Security Advisory before any public writeup If you also want the Google patch money, land the fix upstream yourself and keep it merged without reverts for one month, with the patch between one and twelve months old. That is a separate pathway with its own rules Google's side is capped at three submissions per person per month and cannot pay anyone on a sanctions list or resident in Russia or Belarus Disclosure Coordinated with the Sigstore security team through [email protected] , which publishes GitHub Security Advisories promptly and credits reporters by name. Google Patch Rewards adds no confidentiality or embargo term of its own, so the only timing discipline is upstream's: hold the detail until the advisory is out. 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