Disabled build-test workflow

[richardlau]

FYI @nodejs/docker Out of caution, I've disabled the build-test workflow.

Late Friday night/early Saturday morning, we were informed that this repository had been identified as using actions that had been compromised: https://www.stepsecurity.io/blog/harden-runner-detection-tj-actions-changed-files-action-is-compromised:

docker-node/.github/workflows/build-test.yml

Line 29 in 8e848ca

uses: tj-actions/changed-files@v45

AFAICT the last time the workflow ran was before the action was compromised, so we've been lucky not to leak any secrets.

[nschonni]

Thanks! Our actions are unpinned to reduced noise, but is your recommendation to go back and use the hashes for all/some of the actions going forward?

[richardlau]

My understanding is that OSSF and the @nodejs/security-wg recommend pinning hashes.

My own view is that I'm not entirely sure that would have avoided the compromise as usually sha pinning is done in conjunction with automation for update (e.g. dependabot, Rennovate, etc) and there were reports that some repositories took an update to the compromised hash (i.e. in theory each version update should be checked, but does anyone actually scour through the changes of each dependency from a dependabot PR?).

[richardlau]

Although having thought about it more, I guess the argument is that pinning at least means another step (i.e. PR merge) before the behaviour is changed, and an easier roll-back if a compromise is discovered.

[nschonni]

Yeah, I went ahead and opened PRs to pin them, and add the OSSF workflow to this repo. I think we had mostly hardened the workflows, and the workflow that uses that action doesn't actually load any secrets, it's good that you disabled it. I'll what till the other PRs land and the permissions stuff is also reviewed till re-enabling the job. Right now that workflow is just a smoke test for PRs anyway