Trivy Supply Chain Attack Transparency Report (No Impact)

[lreading]

Threat Dragon Was Not Impacted

AquaSecurity's Trivy GitHub Action was compromised, including an overwrite of 76 existing release tags.
For more information on the technical details of this breach, please see CrowdStrike's Blog Post and Trivy's official statement. The Actions were compromised on March 19, 2026 at ~17:43 UTC, and containment was completed on March 19, 2026 at ~20:38 UTC

Threat Dragon was NOT impacted by this compromise. Even so, our community deserves to know what happened, how we investigated, and what we could do differently to safeguard against future supply chain attacks. Per our community trust documentation, this issue is being created as a transparency report to our community.

---

How Threat Dragon Uses Trivy

Threat Dragon uses the official Trivy Action to scan our built docker images for known vulnerabilities:

• on every pull request targeting main
• on every push to main
• daily

We have some light documentation on how/why Trivy is used in the Trust / Container scanning and Trust / Dependency management pages.

---

Investigation

Trivy runs pre-compromise

At the time these jobs ran, aquasecurity/trivy-action@0.34.0 pointed to the legitimate, unmodified code. The malicious force-push did not occur until 2026-03-19T17:43:00Z.

Run ID	Trivy job started (UTC)	Trivy job completed (UTC)	Trigger	Workflow	Outcome
23275785695	2026-03-19 01:52	2026-03-19 01:53	pull_request	pull_request.yaml	Success 15h 51m before tag was compromised
23283770064	2026-03-19 07:05	2026-03-19 07:05	schedule	housekeeping.yaml	Success 10h 38m before tag was compromised
23295925015	2026-03-19 13:05	2026-03-19 13:05	pull_request	pull_request.yaml	Success 4h 37m before tag was compromised

Trivy runs post-containment

All runs that occurred after AquaSecurity contained the issue by removing the compromised tags failed, spare one that was using the newest known-safe tag. The following runs used aquasecurity/trivy-action@0.34.0, after the compromise:

Run ID	Timestamp (UTC)	Trigger	Workflow	Trivy job outcome
23332645717	2026-03-20 07:05	schedule	housekeeping.yaml	Failed at "Set up job" (tag deleted)
23374391353	2026-03-21 07:00	schedule	housekeeping.yaml	Failed at "Set up job" (tag deleted)
23377023151	2026-03-21 09:47	pull_request	pull_request.yaml	Skipped (upstream job failed)
23381099443	2026-03-21 13:51	push	push.yaml	Skipped (Docker build cancelled)
23393679454	2026-03-22 02:12	pull_request	pull_request.yaml	Skipped (upstream job failed)

One additional run used the newly published / uncompromised version via dependabot PR that correctly identified and pushed the newest known-safe tag:

Run ID	Timestamp (UTC)	Trigger	Workflow	Notes
23381203540	2026-03-21 13:57	pull_request	pull_request.yaml	Dependabot PR bumping to @0.35.0 (safe)

Credential Rotation and Dependency Investigation

I had initially assumed that Threat Dragon was impacted based on our use of Trivy. I prioritized auditing our deployment channels over a deeper investigation to ensure that we were not directly compromised and/or delivering malware.

Note on code-signing: Threat Dragon code-sign all macOS and Windows releases using Certum’s cloud-based signing service. Signing is performed manually by maintainers (not automated). macOS packages are signed and notarized by Jon, and Windows installers are signed by Leo. The signing keys are held in an HSM and require authenticated access with OTP (2FA), so possession of the certificate alone is not sufficient to perform signing.

Heroku: There were no changes to configuration or other unexpected activity. The latest deployment happened well before the time of compromise. I rotated the credentials.

Docker Hub: Official releases are in the OWASP org, and build/rolling artifacts are maintained in a separate threatdragon org. There were no pushes to the official repo after the time of compromise. The latest tag was updated in the build artifacts org well after the time of containment. Trivy is not included in the docker images themselves.

Snapcraft: The latest update to the snap store was well before the time of compromise

BrowserStack: Used only for e2e testing - rotated credentials and found no anomalous activity.

At this point, I began the deeper investigation and found that we were not directly impacted.

---

Commit & Tag Audit

Commits to main after compromise (2026-03-19T17:43:00Z):

SHA	Timestamp (UTC)	Author	Message
a836498b8d04	2026-03-21 13:51	Leo (lreading)	Merge pull request #1494 from OWASP/chore/desktop-e2e-coverage

I re-reviewed the PR and there was nothing notable - all changes are the changes I made and were expected.

Tags:

• No tags were created after 2026-03-19T17:43:00Z
• Most recent tag v2.6.0 (SHA 36e91854bf0f) predates the compromise
• Cross-checked recent tag SHAs against git log: no orphaned or unexpected tags

---

What Should We Do Differently?

I want to acknowledge that we were lucky. If our actions had run at a different time of day, we would have been impacted. While we cannot prevent dependencies from being compromised, we can do more to better protect Threat Dragon from supply chain attacks.

I'd love feedback on the following suggestions:

1. Audit / remove repository secrets that are no longer used - audited and pruned on 30th March 2026
2. Pin third party actions to commit hashes instead of tags - applied by pull request update automation dependencies to use hashes #1515 on 29th March 2026

Cleaning up unused secrets is basic security hygiene - I do not anticipate this to be an issue.

Pinning actions to commits does introduce a slightly higher maintenance burden. From what I've read, dependabot gracefully handles pinned actions / commit hashes. Tags are regularly overwritten by actions maintainers, so dependabot will not always open a PR for every commit when using tags. Using commits may change that behavior, and we could see a higher number of dependabot PRs as a result. I believe this is a reasonable tradeoff. We can explore additional ways of managing dependabot updates in the future.

[lreading]

Our repo settings currently require approval to run actions for new contributors only. This means that any user who has contributed at least once is free to run actions when they open a pull request, without approval.

While this definitely reduces friction, I am wondering if we should require approval for all external contributors? My concern is that someone may make a very small commit, and that sets them up to run a malicious action in the future.

@jgadsden - this would make slightly more work for us (albeit the click of a button), so I'd love your thoughts!

[jgadsden]

Yes, I agree that we should apply this safeguard - I will apply it now
In addition we should consider signed commits? Discussions during the OWASP leaders conference in Oslo suggested that this would reduce AI slop and is an extra safeguard as well

Now that we have full length SHAs in place for workflow actions, I have enabled 'Require actions to be pinned to a full-length commit SHA' setting and it seems to work OK for the action I manually triggered

[lreading]

That is all fantastic. Thanks, Jon!!!

While this was such an unfortunate situation, I am thrilled that we are hardening, learning, and otherwise improving from this.

[jgadsden]

agreed, it has been a prompt to increase the defences as much as we reasonably can