Closed pnacht closed 1 year ago
If there's interest in this, feel free to assign it to me. Unless someone suggests otherwise, I'd move forward with (2), forgiving all write permissions set at job level.
Scorecard currently only punishes the high-risk permissions
contents/packages/actions: write
if they are at the top-level. At the job-level, a warning is shown but no score penalty is applied.However, all the other lower-risk permissions (i.e.
checks
) apply a score penalty wherever they are.
Agree this is paradoxical, and came about because the higher-risk permissions were more broadly used (and therefore got more complaints about the penalty), leading to #2338 .
I have no problem with 2.
Just hit this when implementing scorecard in our project: https://github.com/aws-powertools/powertools-lambda-python/blob/3f2498545a5f207bff7fc283956235d99858b306/.github/workflows/release-drafter.yml#L28
In this instance, we need contents: write
only to create a release in draft mode and keep it up to date.
In other cases, we use contents: write
to create temporary branches + create a PR from trusted workflows like building a changelog on every merged PR -- this allows us to keep a protected branch (trunk) and yet allow automation to keep us safe.
Describe the bug Scorecard currently only punishes the high-risk permissions
contents/packages/actions: write
if they are at the top-level. At the job-level, a warning is shown but no score penalty is applied.However, all the other lower-risk permissions (i.e.
checks
) apply a score penalty wherever they are.Reproduction steps Steps to reproduce the behavior:
permissionIsPresent
while high-risk permissions usepermissionIsPresentInTopLevel
.Expected behavior The current situation is the opposite of what'd be expected: high-risk permissions should be punished more severely than low-risk permissions (or they should be punished equally).
So, I'd expect either:
(2) seems closest to the spirit of #2338, but I'd also see value in (3), with something like:
@ top-level
@ job-level
packages, actions)
This would somewhat capture the risk of adding high-risk permissions even if only at the job-level (which could be further reduced to no loss if hash-pinned, as suggested by #3022).