I would kill for an all-in-one solution where I work... today we use a different scanner for every single type of scan we perform, and it's a nightmare to programmatically analyze the results.

I host https://www.defectdojo.org/ in my org and send all our scanner results to that, it’s worked very well. I believe Trivy scan results are supported natively too. The only part that took much work was developing a workflow to automatically scan images with Trivy and then send the results to DefectDojo.

FWIW, here’s a link to supported scans. https://documentation.defectdojo.com/integrations/parsers/fi...

To automatically send vulnerability reports from Kubernetes using the trivy-operator, we developed a small operator that does the sending automatically: https://github.com/telekom-mms/trivy-dojo-report-operator

I'm asking. Isn't there a trade off here?

The specialized apps do a better job, but take longer to parse, or is it just a PITA for no reason?

We're part of a big company that has company-wide standards, and our business unit has it's own more specific standards, and there's enough conflict there that I can't imagine we'll ever be unified.

Even if we did have a unified standard, it'd be a nightmare to move our legacy stuff over, and then it would be anybody's guess how well the standard would hold up over time w/ new controls and compliance programs being added

Got a really bad taste when Aqua just dropped support for tfsec entirely, including closing all GitHub issues even unfixed, instead pointing to trivy.

Yet another quote open source project that is too controlled by a for profit company.

Is Trivy helpful for non-docker and non-kubernetes? For example, can it be used on a regular baremetal server? All of the examples seem to be aimed at either images, ci/cd, or source code