3 ms·

This is why I avoid using non-official actions where possible and always set a version for the action. We had a contractor that used some random action to ssh

by hk1337 1y ago

This is why I avoid using non-official actions where possible and always set a version for the action. We had a contractor that used some random action to ssh files to the server and referenced master as the version to boot. First, ssh isn't that difficult to upload files and run commands but the action owner could easily add code to save private keys and information to another server. I am a bit confused on the "bypass" though. Wouldn't the adversary need push access to the repository to edit the workflow file? So, the portion that needs hardening is ensuring the wrong people do not have access to push files to the repository? On public repositories I could see this being an issue if they do it in a section of the workflow that is run when a PR is created. Private repositories, you should take care with who you give access.

gawa 1y ago
> This is why I avoid using non-official actions where possible and always set a version for the action. Those are good practices. I would add that pinning the version (tag) is not enough, as we learnt with the tj-actions/changed-files event. We should pin the commit sha.[0]. Github states this in their official documentation [1] as well: > Pin actions to a full length commit SHA > Pin actions to a tag only if you trust the creator [0] https://www.stepsecurity.io/blog/harden-runner-detection-tj-actions-changed-files-action-is-compromised#recovery-steps https://www.stepsecurity.io/blog/harden-runner-detection-tj-... [1] https://docs.github.com/en/actions/security-for-github-actions/security-guides/security-hardening-for-github-actions#using-third-party-actions https://docs.github.com/en/actions/security-for-github-actio...
jand 1y ago
> I am a bit confused on the "bypass" though. Wouldn't the adversary need push access to the repository to edit the workflow file? So, the portion that needs hardening is ensuring the wrong people do not have access to push files to the repository? I understand it that way, too. But: Having company-wide policies in place (regarding actions) might be misunderstood/used as a security measure for the company against malicious/sloppy developers. So documenting or highlighting the behaviour helps the devops guys avoid a wrong sense of security. Not much more.

by hk1337 1y ago

gawa 1y ago

> This is why I avoid using non-official actions where possible and always set a version for the action. Those are good practices. I would add that pinning the version (tag) is not enough, as we learnt with the tj-actions/changed-files event. We should pin the commit sha.[0]. Github states this in their official documentation [1] as well: > Pin actions to a full length commit SHA > Pin actions to a tag only if you trust the creator [0] https://www.stepsecurity.io/blog/harden-runner-detection-tj-actions-changed-files-action-is-compromised#recovery-steps https://www.stepsecurity.io/blog/harden-runner-detection-tj-... [1] https://docs.github.com/en/actions/security-for-github-actions/security-guides/security-hardening-for-github-actions#using-third-party-actions https://docs.github.com/en/actions/security-for-github-actio...

jand 1y ago

> I am a bit confused on the "bypass" though. Wouldn't the adversary need push access to the repository to edit the workflow file? So, the portion that needs hardening is ensuring the wrong people do not have access to push files to the repository? I understand it that way, too. But: Having company-wide policies in place (regarding actions) might be misunderstood/used as a security measure for the company against malicious/sloppy developers. So documenting or highlighting the behaviour helps the devops guys avoid a wrong sense of security. Not much more.