- Top reward
- $1,500
- Top severity paid
- Critical
- Assets in scope
- 13
- Public CVEs
- 5
- Last change
- No changes yet
At a glance
What to know before you start testing.
- Pays from $1,500
- for critical bugs.
- 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.
| Severity | Relative size | Reward |
|---|---|---|
| Critical | $1,500+ | |
| High | $700+ | |
| Medium | $300+ | |
| Low |
|
$100 $100 / 1 month Claude Max |
- 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
13 assets you may test, 6 excluded.
Web 1
- https://github.com/aquasecurity/trivy
Products and areas 12
- Client-server mode, where a Trivy server accepts scan requests across a network boundary
- Image handling: registry fetch, layer extraction, tar and archive parsing, and every format a layer can carry
- Misconfiguration scanning: the Terraform, CloudFormation, Kubernetes, Dockerfile and Helm parsers, plus the policy evaluation layered on top of them
- Registry authentication and credential handling for private registries and cloud provider logins
- SBOM handling in both CycloneDX and SPDX, as input to a scan and as output from one
- Secret scanning and everything it reads, since it is pointed by definition at files that hold secrets
- The analysers for every ecosystem, covering OS package databases and every language lockfile and manifest Trivy understands
- The Kubernetes and cloud scanning modes and the credentials they operate with
- The plugin mechanism, which fetches and runs third-party code on the scanning host
- The policy asks for defects in Trivy itself through GitHub private vulnerability reporting, and sends vulnerabilities in Trivy's dependencies to Discussions instead. Nothing narrower than the Trivy codebase is carved out
- The vulnerability database update path, which pulls artefacts from a registry, along with the Java database and the checks bundle fetched the same way
- Trivy as a Go library, embedded inside other scanners and platforms
Out of scope (6)
- Aqua Security's commercial platform, a separate product with a separate report surface
- Findings that presuppose the attacker already controls the machine running the scan
- The registries, container runtimes and cloud APIs Trivy talks to
- Third-party Trivy plugins that are not maintained in the project
- Vulnerabilities in Trivy's own dependencies, which the policy routes to GitHub Discussions rather than to the private channel
- Wrong or missing data in the upstream advisory feeds Trivy consumes; a bad record in an upstream source is not a Trivy defect
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.
-
Use the private vulnerability reporting feature on aquasecurity/trivy , under the repository's security tab.
-
Attach the image, archive or configuration that triggers it.
-
Say whether you ran the CLI, client-server mode or Trivy as a Go library, because the exposed surface differs a great deal between them
-
Name the scanner involved, whether vulnerability, misconfiguration, secret, licence or SBOM, and the database version in play
-
No reward appears anywhere in the policy, so confirm the vendor side with Aqua before assuming a payout is settled
Not accepted
-
Vulnerabilities in Trivy's own dependencies
-
Wrong or missing data in the upstream advisory feeds Trivy consumes
-
Aqua Security's commercial platform
-
Third-party Trivy plugins that are not maintained in the project
-
The registries, container runtimes and cloud APIs Trivy talks to
-
Findings that presuppose the attacker already controls the machine running the scan
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.
Sorona credits this project with 5 CVEs, 4 of them recent. 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 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 CVE history 4 Last 12 months 5 Lifetime Parsing/validation 35 % Code execution 25 % Integrity bypass 25 % Info disclosure 15 % Latest advisories Loading the feed Overview Trivy is the most widely deployed open-source scanner, embedded in GitHub Actions, GitLab's container scanning, Harbor and a great many hand-rolled CI gates. It reads container images, filesystems and infrastructure code that it has no reason to trust, and the answer it returns decides whether a build ships. Both halves of that hurt. A parser defect in an image layer executes inside the pipeline, and a silent false negative walks a vulnerable image straight through the control that exists to stop it. Aqua Security publishes a private reporting channel with no reward attached, so sorona.xyz pays you directly on qualified, reproduced findings. In scope The policy asks for defects in Trivy itself through GitHub private vulnerability reporting, and sends vulnerabilities in Trivy's dependencies to Discussions instead. Nothing narrower than the Trivy codebase is carved out Image handling: registry fetch, layer extraction, tar and archive parsing, and every format a layer can carry The analysers for every ecosystem, covering OS package databases and every language lockfile and manifest Trivy understands SBOM handling in both CycloneDX and SPDX, as input to a scan and as output from one The vulnerability database update path, which pulls artefacts from a registry, along with the Java database and the checks bundle fetched the same way Misconfiguration scanning: the Terraform, CloudFormation, Kubernetes, Dockerfile and Helm parsers, plus the policy evaluation layered on top of them Secret scanning and everything it reads, since it is pointed by definition at files that hold secrets Client-server mode, where a Trivy server accepts scan requests across a network boundary Registry authentication and credential handling for private registries and cloud provider logins The plugin mechanism, which fetches and runs third-party code on the scanning host The Kubernetes and cloud scanning modes and the credentials they operate with Trivy as a Go library, embedded inside other scanners and platforms Out of scope Vulnerabilities in Trivy's own dependencies, which the policy routes to GitHub Discussions rather than to the private channel Wrong or missing data in the upstream advisory feeds Trivy consumes; a bad record in an upstream source is not a Trivy defect Aqua Security's commercial platform, a separate product with a separate report surface Third-party Trivy plugins that are not maintained in the project The registries, container runtimes and cloud APIs Trivy talks to Findings that presuppose the attacker already controls the machine running the scan Most-valued findings Code execution or memory corruption while parsing an image layer, an archive or a package database. The input is untrusted by design and the process runs inside the release pipeline with whatever credentials that pipeline holds Anything in the database or checks-bundle update path that lets an attacker serve content Trivy accepts. The scanner then reports clean indefinitely, and nobody investigates a green gate A systematic false negative: a crafted lockfile, package database or image structure that makes Trivy miss a package it should have flagged. The control fails silently and the vulnerable build ships SBOM parsing defects, since Trivy routinely consumes an SBOM produced by another tool and treats its contents as fact Exposure through client-server mode, where the server takes scan requests and returns results over a network to callers it did not authenticate strongly Registry credential leakage into logs, caches or scan output, because Trivy holds pull credentials for private registries on shared CI infrastructure 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. Use the private vulnerability reporting feature on aquasecurity/trivy , under the repository's security tab. That is the channel SECURITY.md names and it is confirmed enabled Vulnerabilities in Trivy's own dependencies are redirected to GitHub Discussions by the policy. Only defects in Trivy itself belong in the private channel Attach the image, archive or configuration that triggers it. This tool's input is untrusted by design, so the reproducer is normally a crafted artefact Say whether you ran the CLI, client-server mode or Trivy as a Go library, because the exposed surface differs a great deal between them Name the scanner involved, whether vulnerability, misconfiguration, secret, licence or SBOM, and the database version in play No reward appears anywhere in the policy, so confirm the vendor side with Aqua before assuming a payout is settled Disclosure Coordinated through GitHub private vulnerability reporting on aquasecurity/trivy and published as a GitHub Security Advisory. The policy sets no response target and no day count, so agree the embargo in the thread. Trivy is pinned inside pipeline definitions and vendored as a library by other platforms, so downstream needs a release cycle before any public writeup. 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