Feature: Allow unpinned in non-privileged workflows

[laurentsimon]

Workflows that have no secret and all their permissions set to read/none don't benefit from being pinned, and add burden for users to keep them up to date. We may want to relax the Token-Permission check, making this a "bonus" point rather than flagging it as an problem

[laurentsimon]

/cc @raghavkaul

[evverx]

Workflows that have no secret and all their permissions set to read/none don't benefit from being pinned

They do but it has nothing to do with security. systemd pins its dependencies to make it easier to maintain the CI. For example super-linter broke at some point https://github.com/github/super-linter/issues/2128 and when Dependabot tried to update the action it failed and the last working version was successfully used until the bug was fixed. If it hadn't been pinned the part of the CI relying on super-linter would have been just broken.

Having said that I agree that unpinned read-only actions shouldn't be flagged by analyzers focusing primarily on security and it seems to me that promotional PRs like the one discussed at ossf/scorecard-action#1017 triggered semi-automatically by overzealos "security" tools fixing imaginary "security" issues can be eliminated by addressing this issue. Can it be bumped somehow?

[laurentsimon]

I think we'll try to tackle this in Q1. It's on our radar.

[evverx]

I wonder if there are any updates on this?

(it's related to systemd/systemd#27530)

[laurentsimon]

@diogoteles08 is working on it afaik

[evverx]

Good to know. Thanks!

It seems it should cover CIFuzz (at least as long as it doesn't write SARIF). I wonder if ClusterFuzzLite can pass this check? It comes with unpinned docker images.

[diogoteles08]

Hi there! Yes, I'll be working on this issue. Expected to end of Q1.

[hartwork]

I would like to emphasize that even for read-only actions, a gone-malicious action could:

• modify build artifacts
• leak CI secrets (if secrets are used)
• release/deploy/publish malicious code (if secrets are used)

So if the scorecard de-penalizes read-only actions, it closes their eyes to all of these scenarios. Is that a good idea?
I would personally expect to at least require that the action does not use any secrets (and check for that) to be considered safe without pinning, just my 2 cents.

Am I missing something in this picture?

CC @hugovk @joycebrum

PS: https://github.com/step-security/harden-runner tries to go the exact opposite way, in case someone is interested.

[evverx]

modify build artifacts

I wonder how it can do this if it doesn't have contents: write? Or do you mean actions that upload stuff to, say, PyPI?

leak CI secrets

They can leak secrets but I don't think pinning stuff to hashes can help much here given that under the hood a lot of actions use a bunch of unpinned modules nobody has ever reviewed. PRs where Dependabot updates stuff aren't reviewed either.

release/deploy/publish malicious code

They can do that too and pinning stuff doesn't help here either.

https://github.com/step-security/harden-runner tries to go the exact opposite way, in case someone is interested

I took a look at it systemd/systemd#25205 (comment) so personally I'm not interested in that.

All in all I think instead of that security theater scorecard should ideally actually audit/scan actions. It was discussed in #3022 (comment) and #2991 (comment).