Can you check whether the trivy breach affects users of drydock?

[ovizii]

https://www.bleepingcomputer.com/news/security/trivy-vulnerability-scanner-breach-pushed-infostealer-via-github-actions/

GHSA-69fq-xp46-6x23

https://www.crowdstrike.com/en-us/blog/from-scanner-to-stealer-inside-the-trivy-action-supply-chain-compromise/

[s-b-e-n-s-o-n]

Thanks for flagging this @ovizii — this is a serious supply chain incident and it's a fair question.

TL;DR: Drydock users are not affected by this breach.

We've done a thorough audit and can confirm there is zero exposure across all three attack vectors. No CI runs occurred during the exposure window (March 19–20), and no compromised version was ever pulled or shipped.

1. aquasecurity/trivy-action GitHub Action (primary attack vector)

Not used. Drydock does not use trivy-action or setup-trivy in any GitHub Actions workflow. The attacker force-pushed 76 of 77 release tags to malicious commits — but since we never reference these actions, our CI/CD pipelines were never exposed.

2. Bundled Trivy binary is a safe version

Drydock's Docker image includes Trivy and cosign binaries for local vulnerability scanning and image signature verification. The Trivy binary is installed from Alpine's package repository and pinned at v0.69.3-r1 in the Dockerfile, which predates the compromised v0.69.4 release. Aqua Security has confirmed that v0.69.3 is safe and protected by GitHub's immutable releases feature.

# From Drydock's Dockerfile — Trivy pinned to safe version
apk add --no-cache --repository=https://dl-cdn.alpinelinux.org/alpine/edge/testing trivy=0.69.3-r1

Correction (March 22): Our initial version of this reply stated the Dockerfile pinned Trivy, but the main branch Dockerfile did not include an explicit version constraint at the time of posting. This does not change the outcome: no Docker image builds ran during the exposure window, the Alpine repository was serving v0.69.3 (safe), and even if a compromised Trivy binary had been installed, it would only be used to scan container images for CVEs — it has no access to CI runner secrets, SSH keys, process memory, or any of the targets the GitHub Actions payload exploited. The QA test compose file also referenced aquasec/trivy:latest, but that environment only runs on developer machines, never in CI or production. As a defense-in-depth measure, we have pinned both: trivy=0.69.3-r1 in the Dockerfile and aquasec/trivy:0.69.3 in the QA compose.

You can verify your running instance:

docker exec drydock trivy --version
# Should report v0.69.3 — confirmed safe

Our CI/CD linting also uses Trivy through Qlty, which has v0.69.3 cached locally.

3. All GitHub Actions SHA-pinned (immune to tag repointing)

The core attack technique was git tag -f + git push -f — silently repointing mutable version tags to malicious commits. As CrowdStrike's writeup recommends, the defense is pinning actions by full commit SHA instead of tags.

Every action in Drydock's CI is already SHA-pinned:

# Example from our workflows — SHA-pinned with version comment
uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd  # v6.0.2
uses: step-security/harden-runner@fa2e9d605c4eeb9fcad4c99c224cee0c6c7f3594  # v2.16.0

Additionally, every job runs step-security/harden-runner which provides runtime security monitoring on our CI runners.

4. No CI activity during the exposure window

We verified that zero GitHub Actions runs occurred between March 19–20, 2026 (the exposure window). The last CI run before the breach was March 18 (release workflow, completed successfully). The next CI run was March 21. No compromised version of any component was ever executed in our pipelines.

What Drydock users should do

• Verify your Drydock container: docker exec drydock trivy --version should show v0.69.3
• If you use an external Trivy server (DD_SECURITY_TRIVY_SERVER): verify that server is not running v0.69.4
• If you use trivy-action in your own CI pipelines: check if your workflows ran between March 19–20 and follow Aqua's remediation guidance. Rotate any secrets accessible to those runners.
• If you don't use Trivy at all: no action needed.

We've published a full writeup at getdrydock.com/security/trivy-supply-chain-march-2026 with the complete timeline, technical details, and recommendations.

This is a good reminder to always pin GitHub Actions by commit SHA rather than version tags. Tags are mutable pointers in Git — they can be silently repointed without any visible change on the release page.

[Eesa-000]

Hi, taking a look through some trivy stuff myself

that environment only runs on developer machines

might want to verify that the developer machines are not compromised fyi: https://rosesecurity.dev/2026/03/20/typosquatting-trivy.html (under the It Didn’t Stop at CI section). Just a heads up :)

[s-b-e-n-s-o-n]

Good call @Eesa-000, thanks for flagging — the developer workstation vector is worth taking seriously.

We did a full audit:

• Qlty's local Trivy binary (the only one that runs natively on macOS): SHA256 verified byte-for-byte against the official v0.69.3 GitHub release. Never touched v0.69.4.
• QA compose trivy:latest: runs inside a Docker container in Colima, not on the host. docker compose up -d uses the cached image — no re-pull during the exposure window. Even in a worst case, the container has no volume mounts to the host filesystem, and the persistence dropper (sysmon.py/systemd) can't escape the container or activate on macOS.
• Sophos Central (cloud-side, immutable logs): zero hits on all five C2 indicators (aquasecurtiy.org, 45.148.10.212, trycloudflare.com tunnel, icp0.io dropper endpoint, tpcp exfil) across the entire org for the last 30 days.
• No host compromise indicators: no persistence mechanisms, no suspicious processes, no typosquatted domain in shell history.

Confirmed clean. Appreciate the heads up — the RoseSecurity writeup is a great companion to the Wiz analysis.