GitHub's early-September 2026 Actions changelog contains three small items that are easy to skip and useful to adopt: a GITHUB_TOKEN permission for reading Dependabot alerts, a REST endpoint that reports when a runner version loses support, and new job-context properties for reusable workflows. None of them is a headline feature. Together they remove a few workarounds that many teams have carried for years.
We read these from the GitHub changelog entry and summaries of it. Property and endpoint names below follow that entry, but check the current GitHub Docs before copying them into production workflows.
1. Reading Dependabot alerts without a PAT
Until now, a workflow that needed to know about open Dependabot alerts (to fail a release, to post a summary, to gate a deploy) usually relied on a personal access token or a GitHub App token, because the default GITHUB_TOKEN could not read them. Both options add something to manage: a long-lived secret, or an App installation.
The new vulnerability-alerts permission lets a workflow request read-only access with the built-in token:
name: release-gate
on:
workflow_dispatch:
permissions:
contents: read
vulnerability-alerts: read
jobs:
check-alerts:
runs-on: ubuntu-latest
steps:
- name: Fail on open critical alerts
env:
GH_TOKEN: ${{ github.token }}
run: |
count=$(gh api "repos/${{ github.repository }}/dependabot/alerts?state=open&severity=critical" --jq 'length')
echo "open critical alerts: $count"
test "$count" -eq 0Two points are worth stating. First, declaring permissions at the workflow level sets every unlisted scope to none, so this is a least-privilege configuration by default. Second, the token is short-lived and scoped to the run, which is a better security posture than a PAT stored in repository secrets. If you have a release or deploy gate that currently uses a PAT only for this purpose, this is a clean replacement.
One caution: a gate that blocks on any open critical alert will also block on alerts that do not affect your code path. Decide up front whether you want a hard failure or a warning, and consider an allow-list with an expiry date for accepted risks.
2. Planning around runner version support
Self-hosted runners are a recurring source of surprise. GitHub enforces minimum runner versions, and in June it resumed enforcement for self-hosted runners on github.com and Enterprise Cloud with Data Residency. A runner that falls too far behind stops registering and then stops running jobs, often at the least convenient time.
The new REST endpoint returns when registration and runtime support end for a given runner version. That makes an expiry check scriptable:
# Pseudocode: look up the support window for the version you run
RUNNER_VERSION=$(cat /opt/actions-runner/.runner-version 2>/dev/null || echo "unknown")
gh api "<runner-deprecation-endpoint>/${RUNNER_VERSION}" --jq '.'We have left the endpoint path as a placeholder because we could not verify the exact route from the sources we had. Look it up in the REST API reference under Actions. What matters is the pattern: run the check on a schedule, compare the returned date with today, and open an issue or page the platform owner when fewer than 30 days remain.
If you run Actions Runner Controller on Kubernetes, the same data can feed a check that compares the version in your runner image tag with the deprecation window, before the image is rolled out to the fleet.
3. Reusable workflows that know where they came from
A reusable workflow runs in the caller's context. The existing github.workflow_ref and github.workflow_sha values describe the caller, not the reusable workflow itself, which made it awkward for a shared workflow to report which version of itself was running or to check out its own helper scripts.
The new job-context properties reflect the workflow that defines the current job. In practice this helps with:
- Logging the exact version of a shared workflow in the run summary, which makes it easier to correlate a failure with a template change
- Checking out the reusable workflow's repository at the same ref it was called with, to fetch scripts that ship alongside it
- Auditing which pinned SHA of a shared workflow each repository actually used
If your organisation keeps CI templates in a central repository, add a step to each template that prints the new properties to the job summary. The cost is one line, and the first time a template regression has to be traced across thirty repositories you will be glad of it.
Putting it together
A reasonable baseline for a repository using these features:
- Set
permissions: {}or a minimal block at the top of every workflow, then add scopes per job. - Replace PATs that exist only to read Dependabot alerts with
vulnerability-alerts: read. - Schedule a weekly runner-version check for self-hosted fleets and alert on a threshold.
- Make shared workflows print their own identity into the job summary.
- Pin third-party actions to full commit SHAs, as before. None of the above replaces that.
These changes are small, and each one removes either a long-lived secret or a source of silent failure. That is usually a better use of an afternoon than adopting a new tool.
Sources
- GitHub Changelog, "GitHub Actions: Early September 2026 updates" (September 3, 2026)
- GitHub Changelog, June 2026 entry on resumed enforcement of self-hosted runner version requirements