3 comments
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.
Regarding GitHub actions and it's secret manager. Any decently organized company would do well to stay away from well known secret interfaces.
Instead use oidc auth to fetch secrets just in time, all short-lived for the duration of the pipeline.
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.
Why use a Shamir architecture at all, instead of giving the CI run an ephemeral token that will be exchanged on the proxy?
Can you explain what this is please? "Exploits mutable Git tags and self-declared commit identity"