Summary

Multiple GitHub Actions workflows in this repository have security code scanning alerts related to token permissions. There are 6 open alerts across 6 workflow files related to permission configuration:

The alerts fall into two categories:

1. S8264: Read permissions defined at workflow level instead of job level (4 alerts)
2. S8234/TokenPermissionsID: Overly broad permission declarations (2 alerts)

Why is this needed?

1. Security best practice: Following the principle of least privilege reduces attack surface if a workflow is compromised
2. OSSF Scorecard compliance: Proper permission configuration contributes to a higher security score
3. Defense in depth: Ensures new jobs fail safely (no permissions) rather than inheriting potentially unnecessary access
4. CWE-266 compliance: Addresses "Incorrect Privilege Assignment" vulnerability class

Which area does this relate to?

Automation

Solution

Apply a two-layer permission strategy that satisfies both SonarCloud and OSSF Scorecard requirements:

1. Set restrictive top-level permissions

permissions: {}  # Disables all permissions at workflow level

Per GitHub docs, this "disables permissions for all available scopes."

2. Declare permissions at each job level

jobs:
  example-job:
    permissions:
      contents: read  # Only grant what this specific job needs
    runs-on: ubuntu-latest

Job-level permissions override workflow-level, so each job gets exactly what it declares.

Files to update:

• .github/workflows/reusable-run-linting-check-and-unit-tests.yml
• .github/workflows/ossf_scorecard.yml
• .github/workflows/quality_check.yml
• .github/workflows/publish_layer.yml
• .github/workflows/layers_partitions.yml
• .github/workflows/layers_partitions_deploy.yml

Benefits:

Acknowledgment

• This request meets Powertools for AWS Lambda (TypeScript) Tenets
• Should this be considered in other Powertools for AWS Lambda languages? i.e. Python, Java, and .NET

Future readers

Please react with 👍 and your use case to help us understand customer demand.