- Top reward
- $7,500
- Top severity paid
- Not published
- Assets in scope
- 11
- Public CVEs
- 0
- Last change
- No changes yet
At a glance
What to know before you start testing.
- Pays up to $7,500
- top reward.
- Report on Sorona
- Submit through the program page.
- Partial safe harbor
- Some legal protection; read the terms.
- Publish after a fix
- Coordinate the timing with the company.
Rewards
What Sorona lists as the payout for each severity.
Sorona does not publish a reward table for this program.
- Safe harbor
-
Partial
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.
Summarised with AI from the program policy on Sorona, read 12 Nov 2026, and checked word for word against it. Read the original
Scope
11 assets you may test, 8 excluded.
Web 1
- https://github.com/GoogleContainerTools/distroless
Products and areas 10
- Debian package selection, snapshot pinning, and the integrity verification of the .deb artifacts the build fetches
- Google's tier file names GoogleContainerTools/distroless at OT0, and the program takes security bugs in the latest versions of what that repository publishes. A product vulnerability is priced at $500 to $7,500, and a compromise of the repository or the publishing pipeline falls in the separate supply-chain category at $3,133.70 to $31,337
- Image signing, attestation, SBOM generation, and the publishing pipeline to gcr.io and registry mirrors
- The Bazel rules and package-set definitions that assemble each distroless base image, where a change to what goes in the image is a change to every image built on it
- The CA certificate bundle shipped in the base and static images, both its contents and its freshness, since every TLS client in a derived container trusts it
- The debug image variants and the busybox shell they include, which reintroduce the tooling the other variants deliberately omit
- The nonroot user and group configuration, the default user each image runs as, and the filesystem ownership and permissions baked into published images
- The published image families: static, base and cc, the Java, Node.js and Python images, and the debug counterpart of each
- The repository's own GitHub Actions workflows and release configuration
- The rest of the filesystem the images assemble rather than inherit, including /etc/passwd, timezone data and the shipped licence and metadata files
Out of scope (8)
- Awards to researchers on sanctions lists, in territories subject to sanctions, or located in Russia or Belarus, which Google states it will not issue
- Container runtime and host kernel escapes, which these images neither implement nor mediate
- Image size, layer count and build-time complaints, which carry no security consequence
- Reports filed by anyone other than the researcher: Google requires the submission under your own identity through bughunters.google.com, and treats routing around the designated channel as grounds to reject
- Repositories the tier file does not name, and images that are not current: the program covers the latest versions of the listed repositories, and any other repository in the same organisation counts only where the file names it. What the file omits sits at OT2 or OT3, where product vulnerabilities earn no monetary reward
- Scanner false positives about packages present in the image, without a demonstrated impact
- Upstream Debian package CVEs that distroless merely repackages, which belong with the upstream package maintainers
- Vulnerabilities in the application a user layers on top of a distroless base image
Rules
What the policy asks of you, and the bug types it won't reward, quoted from Sorona's policy.
While testing
-
Submit through sorona.xyz first.
-
Frame the report accurately: a bug in the project's own code is a product vulnerability capped at $7,500
-
Vulnerabilities in the application a user layers on top of a distroless base are not findings against distroless
-
Upstream Debian package CVEs that distroless merely repackages belong upstream with Debian, not here
-
Container runtime and host kernel escapes are outside what these images control
-
Scanner output claiming a package is vulnerable, without a demonstrated impact on the published image, is not eligible
-
Google's rules state that privately disclosing a flaw to a third party, for any purpose other than fixing it, will typically not qualify for a reward
-
Google requires the submission under your own identity through bughunters.google.com
Not accepted
-
Vulnerabilities in the application a user layers on top of a distroless base image
-
Upstream Debian package CVEs that distroless merely repackages
-
Container runtime and host kernel escapes
-
Scanner false positives about packages present in the image, without a demonstrated impact
-
Image size, layer count and build-time complaints, which carry no security consequence
-
Scanner output claiming a package is vulnerable, without a demonstrated impact on the published image, is not eligible
Summarised with AI from the program policy on Sorona, read 12 Nov 2026, and checked word for word against it. Read the original
Changes
Tracked since 11 Nov 2026. Last checked 1 hour ago.
No changes yet. When the rewards or scope move, you will see it here and in the RSS feed.
Public CVEs
Published vulnerabilities in this vendor's products, from the NVD.
No CVEs matched yet. We match NVD records by vendor name, so products sold under another name can be missing.
Original policy
Copied from sorona.xyz on 12 Nov 2026. The summaries on this page are made from it; the live page may have changed since.
Skip to content What this pays sorona.xyz pays 1.25× the program's reward, up to +$1,000 per finding, plus a complexity bonus of up to $1,000 for especially complex or well-chained bugs. Finding │ Program pays │ Through sorona.xyz Product vulnerability (Tier OT0; supply-chain compromise is a separate category) │ $500 - $7,500 │ $625 - $8,500 Other security issue (Tier OT0 flat award) │ $1,000 │ $1,250 Submit a vulnerability CVE history 0 Last 12 months 0 Lifetime Access control 35 % Code execution 30 % Info disclosure 25 % Parsing/validation 8 % Latest advisories Loading the feed Overview Distroless is the standard minimal container base for production Go, Java, Python and Node workloads, and the recommended base in a large fraction of Kubernetes hardening guidance, in ko , in Cloud Run and GKE deployment templates, and in the published images of many CNCF projects. The number that matters is not stars but how many running containers derive FROM these images, which is very large and concentrated in exactly the organisations that chose distroless to reduce their attack surface. The unusual thing about this target is that there is almost nothing to find in the ordinary sense: there is no shell and almost no code, which is the point of the project. The realistic finding is a compromise of how the images are assembled or published: a poisoned base propagates silently into every image built on it, and Google prices that in the supply-chain compromise category at $3,133.70 to $31,337 rather than in the product-vulnerability band. An empty CVE history is expected here, because distroless ships rebuilt images instead of CVE records, and is not evidence of a small attack surface. Google pays for reports through the Open Source Software VRP at Tier OT0, where a product vulnerability runs from $500 to $7,500 and a discretionary panel decides where in that band a finding lands. sorona.xyz adds 1.25× on top of whatever Google awards, up to $1,000 more, plus a complexity bonus of up to $1,000 for a well-chained finding. In scope Google's tier file names GoogleContainerTools/distroless at OT0, and the program takes security bugs in the latest versions of what that repository publishes. A product vulnerability is priced at $500 to $7,500, and a compromise of the repository or the publishing pipeline falls in the separate supply-chain category at $3,133.70 to $31,337 The Bazel rules and package-set definitions that assemble each distroless base image, where a change to what goes in the image is a change to every image built on it Debian package selection, snapshot pinning, and the integrity verification of the .deb artifacts the build fetches The published image families: static , base and cc , the Java, Node.js and Python images, and the debug counterpart of each The CA certificate bundle shipped in the base and static images, both its contents and its freshness, since every TLS client in a derived container trusts it The nonroot user and group configuration, the default user each image runs as, and the filesystem ownership and permissions baked into published images The rest of the filesystem the images assemble rather than inherit, including /etc/passwd , timezone data and the shipped licence and metadata files Image signing, attestation, SBOM generation, and the publishing pipeline to gcr.io and registry mirrors The debug image variants and the busybox shell they include, which reintroduce the tooling the other variants deliberately omit The repository's own GitHub Actions workflows and release configuration Out of scope Vulnerabilities in the application a user layers on top of a distroless base image Upstream Debian package CVEs that distroless merely repackages, which belong with the upstream package maintainers Container runtime and host kernel escapes, which these images neither implement nor mediate Scanner false positives about packages present in the image, without a demonstrated impact Image size, layer count and build-time complaints, which carry no security consequence Repositories the tier file does not name, and images that are not current: the program covers the latest versions of the listed repositories, and any other repository in the same organisation counts only where the file names it. What the file omits sits at OT2 or OT3, where product vulnerabilities earn no monetary reward Reports filed by anyone other than the researcher: Google requires the submission under your own identity through bughunters.google.com, and treats routing around the designated channel as grounds to reject Awards to researchers on sanctions lists, in territories subject to sanctions, or located in Russia or Belarus, which Google states it will not issue Most-valued findings A break in the image assembly or publishing pipeline that lets attacker-chosen content land in a published base image: the highest-value finding here, priced by Google in the $3,133.70 to $31,337 supply-chain band rather than the product-vulnerability one, because a poisoned base propagates into every image built FROM it An integrity gap in Debian package fetching or snapshot pinning that lets a substituted .deb be baked into an image without the build noticing A weakness in image signing or attestation that lets an unsigned or mis-attested image pass as genuine to a policy engine that was relying on it Permission or ownership mistakes in a published image that leave the nonroot user able to write paths it should not, the largest expected class here at 35% and one that quietly undoes the hardening the base was chosen for A stale, missing or tampered CA certificate bundle in base or static , which changes what every TLS client in every derived container will trust Anything in the debug variants or their busybox shell that is reachable in a production image the operator believed was shell-free Program rules Submit through sorona.xyz first. We validate, coordinate with the program's security team, and add the payout uplift on top of whatever it awards. Frame the report accurately: a bug in the project's own code is a product vulnerability capped at $7,500, while a compromise of image assembly or publishing is a separate supply-chain category priced from $3,133.70 to $31,337: on this project the second framing is usually the correct one Vulnerabilities in the application a user layers on top of a distroless base are not findings against distroless Upstream Debian package CVEs that distroless merely repackages belong upstream with Debian, not here Container runtime and host kernel escapes are outside what these images control Scanner output claiming a package is vulnerable, without a demonstrated impact on the published image, is not eligible Google's rules state that privately disclosing a flaw to a third party, for any purpose other than fixing it, will typically not qualify for a reward Disclosure Coordinated through Google Bug Hunters, which triages the report, lands the fix in GoogleContainerTools/distroless and republishes affected images. Distroless publishes rebuilt images rather than CVE records, so remediation usually arrives as a new image digest rather than an advisory, and every downstream image has to be rebuilt against it before anything changes in production. Because Google treats a private disclosure to a third party as grounds for disqualification, file with Google directly. 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