Sounds like the exploit is really just consolidating the unencrypted secrets that were stored by devs in public logs. Or am I missing something?
Devs, secure your secrets. Encrypt your secrets. Ensure secrets don’t show in plain text in your logs. Audit your third party usage.
As I understand it, the exploit was leaking the secrets from the place in the CI pipeline where they were supposed to be, into the public logs.
That’s not how it worked. Secured secrets were read from the context where they are used and printed to logs (albeit run through base64 twice). E.g. here’s the API key for the automation to use the API but it’s not just used, it’s also printed.
The prevention to this situation has nothing to do with secrets and everything to do with pinning 3rd party actions to specific commits. Release versions are not immutable.
I’m very glad that the compromise didn’t reach out with the secrets, so private repos got hit with a switch and not a 2x4.
Thank you for the clarification.
And then I store the encryption key in another repo to ensure the compliance checkmark gets checked? (/s)
Anybody that got bit by this, there’s a drop in replacement at step-security/changed-files
They also have a good write-up of the incident https://www.stepsecurity.io/blog/harden-runner-detection-tj-actions-changed-files-action-is-compromised that shows how to tell if you were hit.