Choose checks for both the image and its source
Trivy's README shows a filesystem command that explicitly enables vulnerability, secret, and misconfiguration scanning together. That is its strongest argument for a delivery team: the same CLI can examine an image and the directory that produced it. You still choose the target and the checks. An image report does not establish what a separate source-directory scan would find.
Aqua Security also documents targets for remote Git repositories, virtual machine images, and Kubernetes. The breadth suits platform engineers who want a common command vocabulary across delivery jobs. I would consider it when security checks are scattered across several scripts. If package advisories are your entire requirement, compare a narrower workflow before adopting more scanning categories than anyone has agreed to maintain.
What happened when we ran it
Our sandbox installed Trivy commit 3f664e5 in 87 seconds, recording 992 dependencies, and built it successfully in 283 seconds. The October 9, 2026 test step then failed with exit 1 after 457 seconds. The supplied Go summary reported 418 passed and 6 failed out of 424. Compilation succeeded, but the complete measured workflow was not green.
The visible tail lists successful package results, including pkg/version, pkg/vex, and several helpers under pkg/x, before ending in FAIL. It does not name the failed checks or show their exceptions. That leaves the cause unresolved. Blaming network access, a particular dependency, or Trivy's own logic would require earlier log lines that are absent from the supplied evidence.
Our recorded configuration had 3 CPUs and 8 GB of RAM, with image golang:1.24-bookworm. The label does not verify the Go or operating-system version actually used. The checkout contained 3,339 files, roughly 284,043 source lines, and occupied 94.7 MB. Signals recorded 21 CI workflow files, a Dockerfile, and no tests directory. That last directory observation plainly does not mean the Go checks were absent.
These measurements concern a source checkout. They give contributors a concrete effort estimate for that run, while leaving packaged-binary setup and detection quality unmeasured. We have no scan accuracy benchmark here. The failed test step is a reason to investigate that commit before embedding or extending it, rather than proof that a released scanner cannot do its job.
Restricted networks require a database delivery plan
Trivy's network documentation lists vulnerability data, a separate Java database, and a checks bundle among its external resources. These are operational inputs to account for after obtaining the executable. Downloading a binary does not settle whether a CI worker can reach the registries that supply its data.
The documentation allows databases to be hosted in your own container registry. It also describes embedded misconfiguration checks as a fallback when the external bundle is unavailable. Those checks reflect the release's bundled data. For restricted environments, decide who updates the internal copies and how workers receive them. A successful command against old data would answer a different question from a scan using current advisories.
Java analysis may contact Maven Central or other remote repositories to identify packages. The documented offline flag prevents those attempts, so verify what information your particular artifacts need before choosing it. Private image registries and Kubernetes targets also bring their existing access requirements. The source run supplied here did not exercise those deployment paths or measure their network costs.
A Python SBOM report can lose relationships without losing detection
Open issue 11411 concerns pylock.toml dependencies identified by name without a version. The reporter says those entries disappear from the dependency graph, leaving incomplete CycloneDX or SPDX relationships. It explicitly says vulnerability detection is unaffected. That distinction matters if your downstream system needs to know which package introduced another package.
The report names v0.75.0 and the main branch as its reproduction targets. It is separate from our October 9 source run, and the supplied test tail cannot connect it to our failures. Teams using affected lockfiles should inspect the generated relationship graph against the lockfile before treating an SBOM as an accurate dependency map. A list containing the package names would not establish that the edges are correct.
The README supplies another clear boundary: it warns that canary builds may contain critical bugs and recommends against production use. Choose a stable release for an operational trial. Contributors and teams requiring a fully passing source baseline should keep our unresolved failures on their adoption checklist until the missing log details are available.
Grype and OSV-Scanner offer different starting points
Grype scans container images, filesystems, and SBOMs for known vulnerabilities. Choose it when you already have an inventory workflow and need advisory matching against those artifacts. This comparison concerns documented scope. Our lab evidence does not rank its detection rate or execution speed against Trivy.
OSV-Scanner connects project dependencies with vulnerabilities in the OSV database. Its documented source scanning makes it worth comparing when dependency advisories drive your decision. It also supports containers, so choosing it need not rule out image scanning. Check your actual package files against either project's coverage before standardizing.
Recent pushes coexist with a specific unresolved report
The last push was October 21, 2026. The pylock issue had activity on October 19. That combination shows an active repository with a concrete open limitation. Neither a recent push nor the existence of a release establishes correctness for your artifacts.
Start with a stable binary against a representative image and its source directory. Decide which findings should block delivery and who owns exceptions. If an SBOM feeds another system, verify its relationships too. For work on commit 3f664e5 itself, obtain the earlier failing log lines before accepting the source baseline.