GitHub Actions adds a vulnerability-alerts token and reusable workflow identity

September 3, 2026. GitHub ships three GitHub Actions updates that tighten control and visibility over pipelines. Since 2021. The GITHUB_TOKEN forced scope compromises to read Dependabot alerts; the new vulnerability-alerts permission ends that. Until now. A reusable workflow could not determine its own identity; the job context fixes it. Why it matters: three quiet changes that, together, shrink the surface of an over-broad secret and finally make reusable workflows auditable.

A vulnerability-alerts token to read Dependabot without handing over everything

The most awaited change is a security one. Until now, a workflow that wanted to read Dependabot alerts had to grant itself a broad scope — often the security-events perimeter, which also covers writes to the Security tab, or worse, overly generous permissions. The new vulnerability-alerts permission for the GITHUB_TOKEN grants only what is needed: read-only access to Dependabot alerts.

permissions:
  contents: read
  vulnerability-alerts: read

The permission accepts two values, read and none. This is the least-privilege pattern applied to CI/CD: a triage or reporting workflow that aggregates alerts no longer has to inherit a scope that could be abused if the repository is compromised. For a team that already follows the rule that every workflow declares what it reads, this removes a point of friction — and gives one more reason to abandon implicit or global permissions.

Concretely, a weekly summary workflow that lists critical Dependabot alerts needs no other scope. It declares the permission in two lines, then queries the dedicated API:

gh api -H "Accept: application/vnd.github+json" \
  "/repos/$OWNER/$REPO/dependabot/alerts?state=open&severity=critical,high" \
  --jq '.[] | .security_advisory.cve_id + "  " + .security_advisory.summary'

For each open alert the output returns the CVE id and its summary — enough to feed a report without ever exposing a token that can write to the repository or the Security tab. That is the difference between a scope that reads and one that can write: the latter is an escalation lever, the former is not.

The job context: a reusable workflow that knows where it comes from

The second change fixes a real annoyance in reusable workflows. The github context exposes github.workflow_ref and github.workflow_sha, but those values describe the calling workflow, not the workflow that defines the job currently running. A reusable workflow therefore had no way to know, inside its own code, which version of itself was executing.

The job context closes that gap with four new properties:

• job.workflow_ref — the full ref of the workflow file defining the current job;
• job.workflow_sha — the commit SHA of that file;
• job.workflow_repository — the owner/repo hosting that file;
• job.workflow_file_path — the file path relative to the repository root.

jobs:
  audit:
    uses: acme/shared-workflows/.github/workflows/audit.yml@main

echo "running from ${{ job.workflow_repository }} @ ${{ job.workflow_ref }}"

For a job defined directly in a workflow, job.workflow_ref matches github.workflow_ref; the two diverge only in the reusable case. The practical upshot: a reusable workflow can now log its own origin, sign its artifacts with its own version, or apply compliance rules that depend on the exact branch of the shared workflow. Note that these properties are not available on GitHub Enterprise Server — check before making them a dependency of your enterprise pipeline.

The most consequential use is provenance. A reusable workflow can now emit an attestation that records job.workflow_sha and job.workflow_ref alongside its output, so a downstream consumer can verify which exact version produced a build artifact. For teams already moving toward SLSA or signed builds, this closes the gap between “a workflow ran” and “we can prove which workflow ran.”

An API to plan runner end-of-life

The third update targets build-infrastructure owners. A new REST API returns the support-end dates for a given runner version: GET /actions/runners/deprecations/{version}, available at the repository, organization and enterprise levels.

curl -s -H "Authorization: Bearer $GITHUB_TOKEN" \
  https://api.github.com/repos/acme/app/actions/runners/deprecations/2.323.0

The response carries three fields: runner_version, runtime_deprecates_at and registration_deprecates_at. The distinction between the two dates is the useful part — a runner can stop accepting new registrations before it stops running. Knowing how to plan, rather than discovering a deprecated version the moment a job fails, turns a forced upgrade into a scheduled operation.

The supply-chain angle: where does the running workflow come from

Reusable workflows carry a structural flaw that gets too little attention: when you call uses: org/repo/.github/workflows/audit.yml@main, the called workflow runs with the GITHUB_TOKEN and permissions of the calling repository. That is exactly what makes it a supply-chain vector — a mutable tag like @main, force-pushed by a compromised account, executes code in every repository that references it.

The job.workflow_ref and job.workflow_sha properties change the picture because they let a reusable workflow attest to itself. A job can log the exact reference it is running, and a compliance policy can compare job.workflow_sha against an expected value before proceeding. It is a step toward SHA pinning — the baseline recommendation for any shared reusable workflow: reference a precise commit, never a branch.

The lesson cuts both ways. For the publisher of a shared workflow, logging its own origin turns a provenance incident into a traceable investigation. For the consumer, demanding a verifiable origin shrinks the trust surface you grant to a third-party repository.

What it changes for your pipelines

Taken together, the three changes point the same way: GitHub Actions gains granularity without adding complexity. The vulnerability-alerts token eliminates a category of over-broad secrets. The job context removes the identity ambiguity that pushed teams to hack around with environment variables or misread the github context. The deprecation API moves runner management from reactive to planned.

The cost is debt to pay back. Workflows that read Dependabot alerts through security-events today would be better narrowed to vulnerability-alerts — a quick review of each workflow’s permissions is in order. And teams that rely on shared reusable workflows should test the job context before rolling it out, keeping the Enterprise Server exception in mind.

None of this demands a big-bang migration. Start with the lowest-effort win — narrowing the permissions block of workflows that already read Dependabot alerts — then add the job context to the one or two reusable workflows you actually maintain, and finally wire your monitoring into the deprecation API. Each change is safe independently, which means you can adopt them in whatever order your risk register dictates.

Verdict

If you aggregate Dependabot alerts in a workflow, replace your broad scope with permissions: vulnerability-alerts: read now: it is a free security win, and the first line of defense for a compromised repository.

If you maintain reusable workflows, adopt job.workflow_ref and job.workflow_sha to log the real origin of your jobs — but confirm availability on your GitHub Enterprise Server version first if you use one.

If you manage self-hosted runners, wire the deprecation API into your monitoring and schedule upgrades ahead of the announced dates instead of absorbing them at the first failing job.

References

• GitHub Changelog — GitHub Actions: Early September 2026 updates, September 3, 2026
• GitHub Docs — Workflow syntax: permissions
• GitHub Docs — Contexts: job context