Can you confirm trivy-operator is not affected by the trivy compromise on 2026-03-19

[mamccorm]

Trivy-operator pulls in Trivy as a dependency. Was last updated / pinned to v0.69.3:

• chore: bump up Trivy to version v0.69.3 #2918

See: https://www.stepsecurity.io/blog/trivy-compromised-a-second-time---malicious-v0-69-4-release.

Which I believe is prior to the affected version. However can someone confirm that the latest trivy-operator version is not affected for assurance?

[chr0n1x]

hey @mamccorm - Im not with Aqua, but I started looking into this myself since I run this on my own personal cluster.

Going into my own pod running on my cluster I see this:

~ $ trivy-operator version # this was me assuming that they have a sane CLI flag interface, I was wrong
2026/03/24 01:19:38 maxprocs: Leaving GOMAXPROCS=4: CPU quota undefined
{"level":"info","ts":"2026-03-24T01:19:38Z","logger":"main","msg":"Starting operator",
"buildInfo":{"Version":"0.30.1","Commit":"fa099f9ade081a0432f33d47ef4032e6ff22aa82",
"Date":"2026-03-13T00:35:08Z","Executable":""}}

So given the SHA fa099f9ade081a0432f33d47ef4032e6ff22aa82 I started poking around @ the history, led me here to the default values.yaml.

And searching in the main trivy repo discussion tab, I found THIS discussion/answer thread where @DmitriyLewen provided some context.

So my HOPE is that - because this operator & its chart never actually got bumped PAST trivy version 0.69.3 (remember that 0.69.4 was the malicious package) - we should be safe...assuming that this operator is the only thing from aquasec that you've been running across your machines/environments. I think that we have never gone past 0.69.3 based on the commit history of the values.yaml file here.

That being said, if you manually bumped the image tag to something like a nightly build I don't think my theory holds.

Im only a homelab devops engineer though; I do things adjacent to this professionally, and have not been as deep in the trivy/k8s world for too long. I pray that @afdesk , @simar7 or @DmitriyLewen can actually confirm this for me.

Last thing I need this week is to find out that this chart ran some previously vulnerable version and I need to rotate literally everything on my cluster to be safe. I'm paranoid enough to not rule out a container escape scenario.

At the very least I'm scaling down my deployment of this thing 😞

[afdesk]

hey guys!
We share your concerns about the incident, and I believe it wasn't affect on trivy-operator, because we bumped up Trivy v0.69.3 only.

Last few days, I've checked the repository and couldn't see any strange behavior.
if you see it, PLEASE share these ones to us ASAP.

Thanks a lot and sorry for inconvinience!