feat: gate Dependabot PR workflow runs with environment approval rules

[gandalf-at-lerian]

Request Type

New input / parameter for an existing workflow

Affected Workflow (if applicable)

TypeScript (ci, release, frontend-pr-analysis)

Problem / Motivation

Recent npm supply-chain attacks have worked by publishing malicious package versions and relying on automated dependency updates/builds to execute them inside CI/CD runners.

When Dependabot opens a dependency bump PR for npm packages, the riskiest step is allowing workflow jobs to install/build the newly bumped dependency automatically. If the dependency is compromised, the GitHub Actions runner can become the execution point and may expose any credentials or secrets available to that workflow.

Some repositories may choose to disable non-vulnerability npm bumps entirely, but the shared-workflow layer should also offer a safer organization-wide control: Dependabot PRs should not run sensitive build/test/release steps without an explicit approval gate.

Proposed Solution

Design and implement a shared-workflow pattern that can detect PRs opened by Dependabot and route sensitive jobs through a protected GitHub Environment rule before executing steps that install/build dependencies.

Expected behavior to evaluate:

• If the PR actor is Dependabot, workflow jobs that could execute dependency code should require environment approval before running.
• Shared workflows should expose an explicit opt-in/parameterized way for repositories to enable this behavior without duplicating logic in every repo.
• Workflows must be prepared for both modes:
  • Skip the environment approval gate when the repo/workflow explicitly opts out or when the PR is not from Dependabot.
  • Block at the environment approval gate when the PR is from Dependabot and the repo opts in.
• The implementation should avoid breaking vulnerability-alert workflows or other existing security signals.
• The pattern should be reusable for npm/package-manager dependency PRs first, but not hard-code itself in a way that prevents later use for other ecosystems.

Possible detection points to assess:

• github.actor == 'dependabot[bot]'
• PR author/login checks from github.event.pull_request.user.login
• workflow-call inputs that let each repo choose strictness and environment name

Alternatives Considered

• Disable Dependabot npm update PRs in each repository. This reduces noise and risk, but does not create a reusable shared control for repos that still want automated dependency PRs.
• Keep Dependabot PRs but rely only on manual PR review. This is weaker because the runner may already have executed dependency code before a human reviews the bump.
• Use per-repository custom YAML rules. This works locally but creates drift and makes the control harder to audit across the organization.

Example Usage

jobs:
  ci:
    uses: LerianStudio/github-actions-shared-workflows/.github/workflows/typescript-ci.yml@main
    with:
      dependabot_environment_gate: true
      dependabot_environment_name: dependabot-approval

Would This Be a Breaking Change?

No — fully backward compatible

Checklist

• I searched existing issues and this is not a duplicate.
• This feature aligns with the repository's goal of providing reusable, organization-wide workflows.

Additional Context

This came from a DevOps discussion around reducing exposure from contaminated npm package releases in automated dependency bump PRs. The immediate goal is not to replace manual dependency hygiene, but to prevent unreviewed Dependabot PRs from automatically executing risky workflow steps on runners with access to workflow credentials.

[lerian-studio]

This issue has had no activity for 30 days and is now marked stale. It will be closed in 7 days unless updated. Add the no-stale label to keep it open indefinitely.

Learn more about the routine and exempt labels: https://github.com/LerianStudio/github-actions-shared-workflows/blob/main/instructions/repository-routines.md