Skip to content

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

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

chore: add stale PR cleanup workflow via centralized pr-manager#310
Manask322 wants to merge 4 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:

The workflow passes all secrets to an external reusable workflow using secrets: inherit, giving the external workflow access to every repository secret. If the external workflow is compromised, an attacker gains access to all your secrets.

More details about this

This workflow passes all secrets to the reusable workflow razorpay/actions/.github/workflows/pr-manager.yaml@master using secrets: inherit.

Here's how this creates a security risk:

  1. Attacker compromises the external workflow: An attacker with access to the razorpay/actions repository could modify the reusable workflow to exfiltrate secrets (e.g., by adding a step that logs ${{ secrets.GITHUB_TOKEN }} or other secrets to workflow logs).

  2. All repository secrets become accessible: Because you're using secrets: inherit, every secret stored in your repository settings (API keys, deployment tokens, authentication credentials, etc.) gets passed into that external workflow's execution context.

  3. Attacker uses stolen secrets: The compromised workflow could grab those secrets and send them to an attacker-controlled server, giving them access to your infrastructure, databases, or third-party services.

Even if the razorpay/actions workflow isn't malicious today, it could be compromised in the future, or a maintainer could go rogue. You're giving away the keys to your entire secret vault based on trust in an external party.

The issue here is that the stale job doesn't need every secret—it probably only needs specific ones (if any) to complete its PR cleanup task. By using secrets: inherit, you're violating the principle of least privilege.

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: mapping under the stale job.
  2. Pass only the secret that this reusable workflow needs. For this workflow, map the GitHub token explicitly as GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}.
  3. Update the job so it looks like secrets: { GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} } or the YAML equivalent:
    secrets:
    GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
  4. Keep any other secrets out of this workflow unless the reusable workflow documentation shows they are required. This limits the called workflow to only the minimum access it needs.
💬 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