Maintenance: Avoid Expaning Secrets in a run block in a workflow

[sdangol]

Summary

As per some SonarQube findings, we should pass secrets to steps through environment variables instead of command-line arguments.

The following files are flagged with the finding:

• .github/workflows/bootstrap_region.yml
• .github/workflows/dispatch_analytics.yml
• .github/workflows/layer_balance.yml
• .github/workflows/publish-package.yml

Why is this needed?

GitHub Actions workflows should handle secrets securely by passing them through environment variables rather than directly expanding them in run commands. When secrets are expanded directly in run commands using GitHub’s expression syntax (${{ secrets.SECRET_NAME }}), they may be exposed in process lists, shell history, or files.

This practice increases the risk of accidental secret exposure, as command-line arguments and process information can be visible to other processes running on the same system.

Which area does this relate to?

Automation

Solution

name: Example

on:
  pull_request:

jobs:
  main:
    steps:
      - name: example
        env:
          SECRET: ${{ secrets.EXAMPLE_SECRET }}
        run: |
          example-command "$SECRET"

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.

[powertools-for-aws-oss-automation]

Warning

This issue is now closed. Please be mindful that future comments are hard for our team to see.
If you need more assistance, please either reopen the issue, or open a new issue referencing this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.