Trivy Trials and Tribulations

Spooky Sundays

On Sunday, March 22 2026 I woke up to some messages in a Discord server I frequent that Trivy, the popular security tool often used to scan container images, suffered a supply chain attack. That attack, among other things, affected their GitHub Action, which I happen to use in my pipelines. The window of time where it was reported that the Action was compromised, I believed to have included time where my pipelines using the Action, would have ran. So I had to assume that I was compromised. What did I do then?

Initial thoughts

Firstly, reading the Discord messages at like 07:30 in the morning, had me feeling just annoyed and tired that I’d need to do something haha. I read the post that Crowdstrike made on the issue and some threads on Reddit. Even if I felt like I was fine, I think it was better to take action, for the sake of my own sanity. And it did not really take a lot of time to get up and going towards resolving the assumed exposure.

The likely exposure across my setup

To pull the curtain back a bit, all my self hosting related repositories live on a GitHub organisation. I do this to primarily take advantage of organisation level variables and secrets for GitHub Actions, Dependabot and CodeSpaces. I use GitHub Actions to automate almost everything to do with my setup. For that, I rely on reusable workflows, so I have one repository that holds said workflows and all other repositories, call them.

I version my Actions repository, using major minor patch and I do my best to follow semver. As a user of well, one, if something does go different it’s not a huge deal. I then rely on Dependabot to open pull requests to update the versions of Actions in my reusable workflow repository and then the repositories that call said reusable workflows.

In the Trivy case, where I use it is for my Docker images. I have two to three Docker images that I use predominately within GitHub Actions workflows themselves, where I use the container keyword to run a job within a container. None of those repositories have any repository level secrets, but they do have access to the organisation level secrets. Those secrets included

• The certificate authority and service account token for my local Kubernetes cluster
• An API key to Hashicorp/IBMs managed Terraform offering, where I manage my state and modules
• Tailscale OAuth details for connecting to Tailscale

So, not great, not terrible (as an aside, YouTube has been pushing shorts from Chernobyl to me recently, I should probably rewatch that show).

How worried was I?

I think it was important to understand how my setup worked, even though I was probably overly proactive in changing some things, I just assumed the secrets at the organisation level were exposed. But, specific to the Docker workflow that I used Trivy in:

• It never connects to my Tailnet. If it did connect to my Tailnet, it would have been able to reach the Kubernetes cluster API. The service account credentials are somewhat elevated, but the attack would have to be trying to deploy workloads to Kubernetes to take advantage of it. It seems the attack was mostly focused on exfiltrating credentials to use later. Which in my case if they wanted to use those later, they need to be on my Tailnet. Plus, I use OIDC to connect anything on the GitHub side to the Tailscale side, so there’s no long term lived credentials. I still made new credentials just to be safe but I think with how OIDC works I likely didn’t need to.
• It never interacts with Terraform or Hashicorp. But important to know that since the API key for Terraform was set to all repositories, they could interact with my Terraform state and Terraform modules. That key was one of the first to be rotated and also subsequently scoped to specifically my Terraform repositories. In terms of cloud credentials, again I use OIDC here for connecting GitHub to AWS. I also looked at areas on my AWS account like EC2 Global View to see if any rogue instances were spun up, which is usually the angle for these sorts of credential thefts I think, and did not notice anything. I’m planning a broader move away from the managed Hashicorp offering and Terraform in general, this was on my TODO list before this event
• There was a fine grained GitHub PAT set on the Dependabot secrets, which gives read access to repositories for Dependabot to be able to update the Actions library that I mentioned. My understanding of GitHub is that for those Dependabot secrets to be accessible, the actor behind the GitHub Actions workflow has to be Dependabot. But I was again just being overly cautious here.

All good? I hope?

I think all-in-all I spent maybe an hour actively looking at this? I rotated all the credentials first, followed by updating the Actions library to use the latest version of Trivy which uses immutable tags now, so that I presume would prevent something similar to this happening again. I then force kicked off Dependabot on all repositories so it would pull in the new version of the repository, doing the Docker image repositories first, so they used the new version of Trivy. Once they were updated I then set the new credentials on the Github org.

It certainly makes me reconsider using Trivy in my environment, whether I’m jumping to remove it right at this moment, not really? Considering this is a tool from a security vendor, I imagine they are quite red faced at the moment and will be doing their best to ensure it doesn’t happen again. I know from my side I need to consider how I scope organisation level credentials, if I wasn’t using OIDC with AWS for example and just had an access key / secret key on the org? With no scoping? Likely tied to my personal IAM user who’s basically God on my account?

Spooky stuff.