Consider adding a version endpoint, or version header to server API

[nscuro]

Description

The Dependency-Track project recently received a community contribution to integrate with Trivy, via its server API.

The contribution was made when the latest Trivy release was 0.51.0.

Since then, there were a few breaking changes in Trivy's server API that caused the integration to no longer work:

• In Trivy 0.51.2, the libraries field was renamed to packages
• In Trivy 0.54.0, the vuln_type field was renamed to pkg_types

In order to support Trivy version 0.51.0, 0.51.2, as well as 0.54.0 and newer, we now have to:

• Populate both libraries and packages with the same content
• Populate both vuln_type and pkg_types with the same content

Since our users tend to leverage a central Trivy server that they already use for other purposes, only supporting the latest Trivy version would be a hard sell.

It would be preferable if we could either:

• Taylor our requests to the Trivy version being used (i.e. only send packages for Trivy >=0.51.2), or
• Enforce the lowest supported Trivy version, i.e. fail when Trivy version is <0.51.2

At the moment, Trivy will happily accept ill-formed requests, and simply not return any results. Which of course makes it impossible to determine if a project has no vulnerabilities, or simply couldn't be scanned at all. And there is currently no indicator as to what version the Trivy server is.

Would it be possible to enrich the Twirp server API with either a new version endpoint, or adding a version header to server responses?

Target

None

Scanner

None

[knqyf263]

Since then, there were a few breaking changes in Trivy's server API that caused the integration to no longer work:

They are not server API changes since a client uses protobuf and the same number. The field name doesn't matter for protobuf. Could you elaborate on how it was broken?

And there is currently no indicator as to what version the Trivy server is.

Also, is /version different from what you want?

$ curl http://localhost:4954/version
{
  "Version": "0.54.0-21-g515bcf462",
  "VulnerabilityDB": {
    "Version": 2,
    "NextUpdate": "2024-08-12T12:11:34.28006289Z",
    "UpdatedAt": "2024-08-12T06:11:34.28006316Z",
    "DownloadedAt": "2024-08-12T09:59:01.59917Z"
  }
}

[nscuro]

The field name doesn't matter for protobuf. Could you elaborate on how it was broken?

You are absolutely correct with this. I think the issue is that the integration was done via the Twirp HTTP API, where a change in the name is indeed breaking. But arguably that is not an issue with Trivy, it's how the integration was chosen to be done.

I'll get us to migrate to gRPC instead.

Also, is /version different from what you want?

🤦 I was sure I checked this. Thanks for pointing that out, apologies for the unnecessary noise.

[knqyf263]

Oh, I see. The JSON client is auto-generated by Twirp, but Trivy doesn't use it but Protobuf. Since users cannot use the JSON client via Trivy CLI, we don't care about it. We may want to delete it so people cannot use it by mistake.

🤦 I was sure I checked this. Thanks for pointing that out, apologies for the unnecessary noise.

It's okay. Please let us know if you're missing something.

[nscuro]

We may want to delete it so people cannot use it by mistake.

That would be good I think.

We will be migrating to the gRPC API for the next Dependency-Track release.

[nscuro]

@knqyf263 I just tried to migrate to gRPC, but realized that Trivy only exposes a twirp-powered HTTP server, which doesn't accept native gRPC calls.

Given your statement from earlier:

The JSON client is auto-generated by Twirp, but Trivy doesn't use it but Protobuf.

I'm wondering if you're planning to move off the HTTP-based Twirp server, towards a gRPC-native one. Or, alternatively, offer gRPC alongside Twirp?

[nscuro]

For reference:

$ trivy server --listen :8080
2024-09-01T19:53:53+02:00	INFO	[db] Need to update DB
2024-09-01T19:53:53+02:00	INFO	[db] Downloading DB...	repository="ghcr.io/aquasecurity/trivy-db:2"
2024-09-01T19:53:55+02:00	INFO	Listening :8080...

$ curl http://localhost:8080/version
{"Version":"0.54.1"}

$ grpcurl -v -plaintext localhost:8080 list
Failed to dial target host "localhost:8080": context deadline exceeded

[knqyf263]

Trivy only exposes a twirp-powered HTTP server, which doesn't accept native gRPC calls.

Is that a problem?

[nscuro]

Ignore me, I missed that Twirp also supports application/protobuf payloads: https://twitchtv.github.io/twirp/docs/proto_and_json.html