[s_ting765]

Pinning github actions by commit SHA does not solve the supply chain problem if the pinned action itself is pulling in other dependencies which themselves could be compromised. An action can pull in a docker image as a dependency for example. It is effectively security theatre. The real fix is owning the code that runs in your CI pipelines. Or fork the action itself and maintain it as part of your infrastructure.

[zanie]

We do address this in the article! It's defense in depth, not theater.

We audit all of our actions, check if they pull in mutable dependencies, contribute upstream fixes, and migrate off using any action when we can.

(I work at Astral)

[pojzon]

Do you fork them and have a team maintaining forks ?

If not you cant be sure of anything. Its just a security theater.

[MeetingsBrowser]

> It is effectively security theatre.

I disagree. Security is always a trade-off.

Owning, auditing, and maintaining your entire supply chain stack is more secure than pinning hashes, but it is not practical for most projects.

Pinning your hashes is more secure than not pinning, and is close to free.

At the end of the day, the line of trust is drawn somewhere (do you audit the actions provided by GitHub?). It is not possible to write and release software without trusting some third party at some stage.

The important part is recognizing where your "points of trust" are, and making a conscious decision about what is worth doing yourself.

[codethief]

Shouldn't you always read & double-check the 3rd-party GitHub actions you use, anyway? (Forking or copying their code alone doesn't solve the issue you mention any more than pinning a SHA does.)

[s_ting765]

Double checking Github actions does not mitigate threats from supply chain vulnerabilities. Forking an action moves the trust from a random developer to yourself. You still have to make sure the action is pulling in dependencies from trusted sources which can also be yourself depending on how far you want to go.