Author here. Last week it was codfish/semantic-release-action, a GitHub Action repointed to a malicious commit to steal CI/CD secrets. A month before that, the Claude Code action was leaking secrets straight out of /proc/self/environ. Same root cause every time: a CI runner is full of long-lived secrets in env vars, and anything running in the job can read them.

We give every pod and VM a workload identity, but the CI job has none, even though it holds your source, your signing keys, and your deploy creds. It borrows credentials instead of earning them. So the job presents its GitHub OIDC token, we check it against GitHub's JWKS plus a policy on the claims (repo/ref/actor), and issue a short-lived SPIFFE cert. After that, credentials get injected onto the outbound connection in the kernel, bound to the destination. Nothing is written to an env var, a file, or process memory. You can't read a secret that was never there, and you can't ship it somewhere policy won't allow.

Scope, upfront: it relies on GitHub's OIDC, it needs Linux runners (works on ubuntu-latest), and the kernel-level enforcement does the heavy lifting. Happy to dig in.