Feature: detect secrets exposed beyond the steps that need them

[Danil42Russia]

Pre-submission checks

• I am not reporting a bug (crash, false positive/negative, etc). These must be filed via the bug report template.
• I have looked through both the open and closed issues for a duplicate request.

What's the problem this feature will solve?

In GitHub Actions, environment variables can now be declared at the workflow level, at the individual job level, and at the step level.

If variables are declared for all steps, values in env that depend on secrets.* become accessible to a wider range of steps than might be necessary :(

jobs:
  example:
    runs-on: ubuntu-latest

    env:
      JOB_SECRET: ${{ secrets.JOB_SECRET }} # bad: available to all `steps`

    steps:
      - name: vulnerable step
        shell: bash
        run: |
          # could steal secrets 
          ./vulnerable_script.sh

      - name: working step
        shell: bash
        run: |
          ./working_script.sh

      - name: vulnerable step
        shell: bash
        run: |
          # could steal secrets
          ./vulnerable_script.sh

Describe the solution you'd like

1. warn if workflow.env uses a value from secrets.*
2. warn if jobs.<job_id>.env uses a value from secrets.*
3. do not warn if jobs.<job_id>.steps[*].env uses a value from secrets.*

Additional context

name: CI

on:
  push:
  workflow_dispatch:

env:
  WORKFLOW_SECRET: ${{ secrets.WORKFLOW_SECRET }} # bad: available to all `jobs` and `steps`

jobs:
  test:
    runs-on: ubuntu-latest

    env:
      JOB_SECRET: ${{ secrets.JOB_SECRET }} # bad: available to all `steps`

    steps:
      - name: step 1
        shell: bash
        run: |
          echo $WORKFLOW_SECRET | base64 | base64
          echo $JOB_SECRET | base64 | base64
          echo $STEP_SECRET | base64 | base64

      - name: step 2
        env:
          STEP_SECRET: ${{ secrets.STEP_SECRET }} # good: available to this `step`
        shell: bash
        run: |
          echo $WORKFLOW_SECRET | base64 | base64
          echo $JOB_SECRET | base64 | base64
          echo $STEP_SECRET | base64 | base64

      - name: step 3
        shell: bash
        run: |
          echo $WORKFLOW_SECRET | base64 | base64
          echo $JOB_SECRET | base64 | base64
          echo $STEP_SECRET | base64 | base64

[woodruffw]

Hi @Danil42Russia, thanks for opening an issue.

To make sure I understand: you're proposing that zizmor flag any non-step env: block that references secrets, right?

[Danil42Russia]

Yes, if the env variable that references secrets is defined outside the step, that should be flagged :)

[Danil42Russia]

Given that there’s currently a surge in attempts to compromise action, unnecessary access could lead to unauthorised access to sensitive information, although this can be avoided :)

It’s better to be on the safe side than to find out in the middle of the night that you’ve been burgled :)

[Danil42Russia]

That said, I’d also take issue with cases like these:

ENV1: ${{ format('Bearer {0}', secrets.WORKFLOW_SECRET) }}
ENV2: ${{ secrets.WORKFLOW_SECRET || 'fallback' }}

i.e. any use of secrets in the environment variable, at any stage.

But this definitely needs to be discussed...

[woodruffw]

i.e. any use of secrets in the environment variable, at any stage.

Could you provide a real-world example? I agree that secrets in general are a risk (by definition), but there are a lot of places where you pretty much need to use an environment variable to pass a secret to a program. It would probably be too noisy for zizmor to flag all secret usages, since it's a key part of GitHub Actions' use case.

(Or did you mean specifically cases where the secret is used as part of an expression/as a computed value?)

[Danil42Russia]

i.e. any use of secrets in the environment variable, at any stage.

What I meant by that is that I think we should comment out all env variables where the value contains secrets.* (and, of course, the env variable itself isn’t declared in the step)

i hope this makes it clearer:

jobs:
  example:
    runs-on: ubuntu-latest

    env:
      JOB_SECRET_1: ${{ secrets.SECRET }}                         # bad
      JOB_SECRET_2: ${{ format('Bearer {0}', secrets.SECRET) }}   # bad
      JOB_SECRET_3: ${{ secrets.WORKFLOW_SECRET || 'SECRET' }}    # bad
  
  steps:
    - name: vulnerable step
      env:
        JOB_SECRET_1: ${{ secrets.SECRET }}                        # good
        JOB_SECRET_2: ${{ format('Bearer {0}', secrets.SECRET) }}  # good
        JOB_SECRET_3: ${{ secrets.SECRET || 'fallback' }}          # good
      run: |
        ./script.sh

P.S. sorry if I'm a bit hard to understand – my English isn't very good :c