Skip to content

Bazel

Bug bounty on Sorona bazel.build

Accepting reports open-source
Top reward
$7,500
Top severity paid
Not published
Assets in scope
11
Public CVEs
2
Last change
No changes yet

At a glance

What to know before you start testing.

Pays up to $7,500
top reward.
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://bazel.build

Products and areas 10

  • bazelbuild/continuous-integration, the CI infrastructure configuration that Bazel's own releases are built on
  • bzlmod module resolution, registry fetching, lockfile generation and lockfile verification, where a gap substitutes one dependency for another
  • Google's tier file names three repositories at OT0: bazelbuild/bazel, bazelbuild/bazel-central-registry and bazelbuild/continuous-integration. A product vulnerability anywhere in the three is priced at $500 to $7,500, and a compromise of the registry, the repositories or the release pipeline falls in the separate supply-chain category at $3,133.70 to $31,337
  • Installer and release artifacts, repository configuration, GitHub Actions workflows and release signing across all three repositories, which Google prices as the supply-chain category
  • Remote execution and remote caching clients, including action key derivation and the decision to trust a result computed on another machine
  • The Bazel Central Registry: module metadata, the source archive integrity hashes it publishes, patch files, and the presubmit and publishing flow that admits a new module version
  • The Bazel server and its client protocol, the build event service, and the persistent worker protocol
  • The build engine end to end: loading, analysis and execution, the action graph, and the local sandbox implementations that are supposed to confine an action
  • The network fetching layer: http_archive, checksum verification, netrc and credential-helper handling, and proxy support
  • The Starlark interpreter and everything it evaluates: BUILD files, .bzl files, WORKSPACE, MODULE.bazel, and repository rules that fetch and execute external content
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
  • Build breakage, incorrect output and performance regressions that carry no security consequence
  • Insider-only risks, which the rules downgrade to credit rather than a reward
  • Issues that require a malicious BUILD or MODULE.bazel file the developer already chose to run, absent a realistic non-maintainer attack path
  • 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 releases 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
  • Third-party Bazel rulesets outside the bazelbuild organisation, which are not listed in Google's repository tier file
  • Vulnerabilities in the third-party CI platforms Bazel uses, which the program rules place explicitly out of scope

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.
  • A malicious BUILD or MODULE.bazel file the developer already chose to run is not by itself a finding; show a realistic path by which a non-maintainer gets that file executed
  • 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

  • Build breakage, incorrect output and performance regressions that carry no security consequence
  • Issues that require a malicious BUILD or MODULE.bazel file the developer already chose to run, absent a realistic non-maintainer attack path
  • Vulnerabilities in the third-party CI platforms Bazel uses
  • Insider-only risks
  • Third-party Bazel rulesets outside the bazelbuild organisation

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.

Search NVD

Sorona credits this project with 2 CVEs. The individual records appear here after the next sync.

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 2 Lifetime Code execution 35 % Access control 25 % Parsing/validation 20 % Info disclosure 15 % Latest advisories Loading the feed Overview Bazel is the build system for Google's monorepo and, outside Google, for a concentrated set of very large engineering organisations including Dropbox, Uber, Stripe, Pinterest, Databricks and much of the Android and Kubernetes-adjacent toolchain. Its footprint is not measured in installs but in what sits downstream of it: a flaw in Bazel's action execution, sandboxing or dependency resolution inserts attacker-controlled code into the binaries those organisations ship, and nobody reviews a build artifact the way they review a pull request. The Bazel Central Registry is the sharpest edge of that: it is the trusted index bzlmod resolves against, the direct Bazel analogue of npm or PyPI, and a compromise of its metadata or integrity hashes is priced by Google as a supply-chain compromise ($3,133.70 to $31,337) rather than as an ordinary product vulnerability. Two lifetime CVEs against a system with that reach reflects how rarely build tooling is looked at rather than how safe it is. 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 three repositories at OT0: bazelbuild/bazel , bazelbuild/bazel-central-registry and bazelbuild/continuous-integration . A product vulnerability anywhere in the three is priced at $500 to $7,500, and a compromise of the registry, the repositories or the release pipeline falls in the separate supply-chain category at $3,133.70 to $31,337 The build engine end to end: loading, analysis and execution, the action graph, and the local sandbox implementations that are supposed to confine an action Remote execution and remote caching clients, including action key derivation and the decision to trust a result computed on another machine The Starlark interpreter and everything it evaluates: BUILD files, .bzl files, WORKSPACE , MODULE.bazel , and repository rules that fetch and execute external content bzlmod module resolution, registry fetching, lockfile generation and lockfile verification, where a gap substitutes one dependency for another The network fetching layer: http_archive , checksum verification, netrc and credential-helper handling, and proxy support The Bazel server and its client protocol, the build event service, and the persistent worker protocol The Bazel Central Registry: module metadata, the source archive integrity hashes it publishes, patch files, and the presubmit and publishing flow that admits a new module version bazelbuild/continuous-integration , the CI infrastructure configuration that Bazel's own releases are built on Installer and release artifacts, repository configuration, GitHub Actions workflows and release signing across all three repositories, which Google prices as the supply-chain category Out of scope Third-party Bazel rulesets outside the bazelbuild organisation, which are not listed in Google's repository tier file Build breakage, incorrect output and performance regressions that carry no security consequence Issues that require a malicious BUILD or MODULE.bazel file the developer already chose to run, absent a realistic non-maintainer attack path Vulnerabilities in the third-party CI platforms Bazel uses, which the program rules place explicitly out of scope Insider-only risks, which the rules downgrade to credit rather than a reward Repositories the tier file does not name, and releases 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 Code execution escaping Bazel's action sandbox or injected through the remote execution and caching clients, the largest expected class here at 35% and the one that turns a build into an attacker's process on every machine that runs it Integrity failure in Bazel Central Registry metadata or source archive hashes that lets a substituted artifact resolve as the genuine module: the highest-value framing on this program, since Google prices registry compromise in the $3,133.70 to $31,337 supply-chain band A bzlmod resolution or lockfile verification gap that silently pulls a different module version than the lockfile pins, which is a supply-chain swap that no reviewer sees Access-control or permission failures in the registry publishing flow that let someone who is not the module owner publish under its name Starlark or repository-rule evaluation that fetches and executes remote content without the integrity check the caller believed was applied Compromise of the release signing or GitHub Actions configuration in any of the three in-scope repositories, which reaches every consumer of the next Bazel release 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. Three repositories are in Google's tier file at OT0: bazelbuild/bazel , bazelbuild/bazel-central-registry and bazelbuild/continuous-integration : third-party rulesets outside the bazelbuild organisation are not covered Frame the report accurately: a bug in the project's own code is a product vulnerability capped at $7,500, while a compromise of the registry, repository or release pipeline is a separate supply-chain category priced from $3,133.70 to $31,337: the same finding can be worth four times as much depending on which it genuinely is A malicious BUILD or MODULE.bazel file the developer already chose to run is not by itself a finding; show a realistic path by which a non-maintainer gets that file executed Vulnerabilities in the third-party CI platforms Bazel happens to use are explicitly out of scope under the program rules Insider-only risks are downgraded to credit rather than paid, so the attack has to be reachable by someone outside the trusted set 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 the relevant bazelbuild repository and publishes on its own schedule with researcher credit. Because Google treats a private disclosure to a third party as grounds for disqualification, file with Google directly, and give registry-side findings extra room: a fix to the Bazel Central Registry has to propagate through every organisation's lockfiles before it means anything. 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