Skip to content

chore: add stale PR cleanup workflow via centralized pr-manager#274

Open
Manask322 wants to merge 5 commits into
masterfrom
chore/add-pr-manager-workflow
Open

chore: add stale PR cleanup workflow via centralized pr-manager#274
Manask322 wants to merge 5 commits into
masterfrom
chore/add-pr-manager-workflow

Conversation

@Manask322

Copy link
Copy Markdown
Member

Adds centralized PR Manager workflow that delegates stale PR cleanup to razorpay/actions/.github/workflows/pr-manager.yaml.

jobs:
stale:
uses: razorpay/actions/.github/workflows/pr-manager.yaml@master
secrets: inherit

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Semgrep identified an issue in your code:

Using secrets: inherit gives the reusable workflow access to all repository secrets instead of just the ones it needs, creating a critical security risk if the external workflow is compromised.

More details about this

This workflow passes all repository secrets to the reusable workflow razorpay/actions/.github/workflows/pr-manager.yaml@master using secrets: inherit. This violates least privilege—the called workflow gets access to every secret, not just what it needs for PR management.

Here's how an attacker could exploit this:

  1. Compromise the reusable workflow: An attacker gains write access to the razorpay/actions repository (either through a supply chain attack or by compromising a maintainer's credentials).

  2. Exfiltrate all secrets: The attacker modifies pr-manager.yaml to add a step that outputs all available secrets (e.g., run: echo ${{ toJSON(secrets) }}) and logs them, or sends them to an attacker-controlled server.

  3. Access sensitive credentials: Because secrets: inherit was used, the reusable workflow now has access to every secret in your repository—database credentials, API keys, deployment tokens, OAuth tokens, etc.—not just the secrets needed for stale PR cleanup.

  4. Abuse credentials at scale: The attacker uses the exfiltrated secrets to access your production databases, deploy malicious code, or access third-party services on your behalf.

The stale job in your workflow doesn't need access to your entire secret vault—it likely only needs specific credentials for GitHub API interactions. By using secrets: inherit, you're giving the external workflow a skeleton key to all your sensitive data.

To resolve this comment:

✨ Commit fix suggestion

Suggested change
secrets: inherit
secrets:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
View step-by-step instructions
  1. Replace secrets: inherit with an explicit secrets: block under the stale job.
  2. Pass only the secret values that the reusable workflow actually needs, for example GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}.
  3. Update the job to look like secrets: { GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} } or the expanded YAML form:
    secrets:
    GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
  4. Keep the secret names aligned with what the called workflow expects in razorpay/actions/.github/workflows/pr-manager.yaml@master. This limits the reusable workflow to only the minimum secrets it needs.

Alternatively, if the reusable workflow requires additional specific secrets, add each one explicitly as its own mapping entry, such as ANOTHER_SECRET: ${{ secrets.ANOTHER_SECRET }}, instead of inheriting everything.

💬 Ignore this finding

Leave a nosemgrep comment directly above or at the end of line 13 like so // nosemgrep: yaml.github-actions.security.secrets-inherit.secrets-inherit

Take care to validate that this is not a true positive finding before ignoring it.
Learn more about ignoring code, files and folders here.

You can view more details about this finding in the Semgrep AppSec Platform.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant