chore(ci): enforce top-level permission to minimum fail-safe permission as per openssf

[step-security-bot]

Issue number: #2203

Summary

OSSF Scorecard rates workflows based on top-level permission as either read-all, : read. Step-Security recommends the bare minimum for a fail-safe run with contents: read`.

Doesn't that break our workflows that need additional permissions?

No. Job-level permissions can still increase a given scope. This changes merely enforces that new jobs will have contents: read permission if no explicit scope is defined.

In which scenario this could break our workflows?

Nested workflows via workflow_call, where parent workflow's permissions cannot be overridden to prevent privilege escalation.

Notes

This pull request is created by Secure Repo at the request of @heitorlessa. Please merge the Pull Request to incorporate the requested changes. Please tag @heitorlessa on your message if you have any questions related to the PR. You can also engage with the StepSecurity team by tagging @step-security-bot.

Changes

Security Fixes

Least Privileged GitHub Actions Token Permissions

The GITHUB_TOKEN is an automatically generated secret to make authenticated calls to the GitHub API. GitHub recommends setting minimum token permissions for the GITHUB_TOKEN.

• GitHub Security Guide
• The Open Source Security Foundation (OpenSSF) Security Guide

Add Dependency Review Workflow

The Dependency Review Workflow enforces dependency reviews on your pull requests. The action scans for vulnerable versions of dependencies introduced by package version changes in pull requests, and warns you about the associated security vulnerabilities. This gives you better visibility of what's changing in a pull request, and helps prevent vulnerabilities being added to your repository.

• Github Guide about Dependency Review
• Github Guide for Configuring Dependency Review Action

Feedback

For bug reports, feature requests, and general feedback; please create an issue in step-security/secure-repo. To create such PRs, please visit https://app.stepsecurity.io/securerepo.

Signed-off-by: StepSecurity Bot [email protected]

[heitorlessa]

fix suggestions to not break all workflows that require additional permissions at job-level

[heitorlessa]

@varunsh-coder following up on this with a proper review this time - I've noticed Step-Security tool adds contents: read in any workflow at the top-level as suggested by OSSF, however this will break workflows that need additional permissions at per job-level --- is that correct?

My previous experience doing this led to actions failing as top-level permissions cannot be increased at the job-level.

Practical example: we have certain workflows that need to create temporary branches and create PRs from them.

[heitorlessa]

just read all issues open/closed in OSSF Scorecard, and specifically this ossf/scorecard#1128.

I'll create a separate repo to test one of our workflows with a read-only top-level permission that increases its scope at the job-level. I suspect I might be misremembering a nested workflow increasing the scope and failing vs top-level minimum with some increased scope at job-level.

[heitorlessa]

Confirmed, reverting suggested changes and keeping contents: read minimal. Workflows only fail when nested workflows try to escalate permissions, which we already addressed at job-level.

Test: https://github.com/heitorlessa/aws-lambda-powertools-test/actions/runs/5453114771/workflow#L16

[heitorlessa]

Approving after clarifying top-level vs job-level permissions potential breakage.

PR body updated to help review in the future.

[github-actions]

No acknowledgement section found. Please make sure you used the template to open a PR and didn't remove the acknowledgment section. Check the template here: https://github.com/aws-powertools/powertools-lambda-python/blob/develop/.github/PULL_REQUEST_TEMPLATE.md#acknowledgment

[github-actions]

No related issues found. Please ensure there is an open issue related to this change to avoid significant delays or closure.

[boring-cyborg]

Awesome work, congrats on your first merged pull request and thank you for helping improve everyone's experience!

[varunsh-coder]

@varunsh-coder following up on this with a proper review this time - I've noticed Step-Security tool adds contents: read in any workflow at the top-level as suggested by OSSF, however this will break workflows that need additional permissions at per job-level --- is that correct?

My previous experience doing this led to actions failing as top-level permissions cannot be increased at the job-level.

Practical example: we have certain workflows that need to create temporary branches and create PRs from them.

Hi @heitorlessa, the Step-Security tool only adds the contents: read top-level permission, if all jobs already have job level permission. If all jobs do not have job level permission, it tries to figure out the job level permission using a knowledge base of permissions for GitHub Actions used by that job. If it cannot figure it out, it will not add the contents: read top-level permission. https://github.com/step-security/secure-repo/blob/d9d6d7e778b117a718e621e7aa9b2cf068c7865d/remediation/workflow/secureworkflow.go#L43-L50

If a job has job level permission, those job level permissions are used. Top level permissions are used if a job does not define any permissions.

[heitorlessa]

if all jobs already have job level permission

Gotcha, that explains it. Thank you! Everything went smoothly, only one small breakage after merging due to nested workflows not getting contents: read propagated (TIL)

Thank you once again for the awesome tool!