How the Trivy supply chain attack harvested credentials from secrets managers (vaultproof.dev)

Well...obviously secrets available in the runtime environment of a CI job are vulnerable to attacks that can compromise the runtime environment. I think everyone knew that. Also GitHub actions that come from less than unreproachable sources (GitHub themselves, ?) have always been an obvious attack vector. In places I've worked where we were concerned about this we forked all the actions repos into our own org so we could never pick up mystery meat in our jobs.

The technical breakdown of the Trivy attack is a great reminder that our security is only as strong as our version pinning. We all know we should pin to SHA-256 hashes instead of mutable tags, but the UX for managing and updating those hashes is still painful enough that most teams default to tags. Until the tooling makes 'doing the right thing' as easy as @v1, these supply chain leaks will continue to be a high-ROI path for attackers.

Leaving aside the fact that this is an ad thinly veiled as an article, OneCli does the same, and recently NanoClaw made OneCli setup their default.

Author here. Built VaultProof after analyzing the Trivy attack the credential harvesting worked specifically because the keys existed as plaintext in the CI/CD environment after retrieval from the secrets manager. Happy to go deep on the Shamir architecture or the attack mechanics if useful.