Trivy Server as request proxy

[ryanpodonnell1]

We want to spin up an internal scanning service that leverages trivy as a central scanning tool

As we were investigating server/client mode it became apparent that:

• the client is the one who authN's to a registry (all our registries are private and require to be part of the restricted network for docker pull)
• the client physically sends the layers to the server
• the client NEEDs to have a javaDB locally to analyze the image

In our use case all we want to do is leverage the trivy client as the job "requestor" where the trivy server receives a request, authN's to the registry, pulls the image and provides the results back to the client.

This would allow the client to not require registry credentials, access to a cache or direct access to the image to retrieve vulnerability results.

client (trivy image/sbom --server xxxx) -> trivy server
trivy server (login) -> Container Registry
trivy server (pull image) -> Container Registry
trivy server (analysis)
trivy server (response to client) -> trivy client sees results

to achieve this as is currently I dont really see a need for trivy server but a bunch of individual clients that needs to be run on demand. This will introduce some delay as tasks will need to provision/execute/download image etc rather than just a simple request to kick off a scan