GitHub Actions allows passing all repository secrets to reusable workflows using secrets: inherit. When the target workflow belongs to a different repository or organization, this violates the principle of least privilege.

Why is this an issue?

When secrets: inherit is used to call a reusable workflow from an external repository, all repository secrets become available to code you do not own or control. Unlike same-repository workflows, external workflows can be modified by their owners at any time, and you cannot fully audit what happens to your secrets once they are passed.

What is the potential impact?

If an external reusable workflow that receives all secrets is compromised or maliciously modified, an attacker can exfiltrate credentials for unrelated services — cloud provider keys, deployment tokens, API credentials, and more. Because the code executing your secrets is outside your control, you may not detect the exposure until significant damage has already occurred.

How to fix it

Code examples

Instead of using secrets: inherit, explicitly pass only the secrets the external workflow actually requires. This limits exposure to a known, minimal set of credentials if the external workflow is ever compromised.

Noncompliant code example

name: Example

on:
  pull_request:

jobs:
  call-reusable-workflow:
    uses: github/ExampleRepo/.github/workflows/reusable.yml@v1
    secrets: inherit # Noncompliant

Compliant solution

name: Example

on:
  pull_request:

jobs:
  call-reusable-workflow:
    uses: github/ExampleRepo/.github/workflows/reusable.yml@v1
    secrets:
      SECRET: ${{ secrets.EXAMPLE_SECRET }}

Resources

Documentation

Standards