Software Supply Chain
GitHub Actions Adds Job-Level Workflow Identity for Reusable Pipelines
GitHub's September 3 Actions update adds job-context fields for the defining workflow's reference, commit, repository and file path. They distinguish a reusable workflow from its caller. Recording these fields improves provenance visibility, but their presence does not force a workflow to use an immutable reference.
Citation-ready: GitHub Actions' new job.workflow_ref, job.workflow_sha, job.workflow_repository and job.workflow_file_path fields identify the defining workflow, which can differ from a reusable workflow's caller.
What happened and why it matters
The new fields let a job record its own defining source without confusing it with the caller, creating a more specific provenance record for shared CI code.
The dated source record
Primary reference: GitHub Changelog: Actions early September 2026 updates. Kaleido Field checked the event date and the article's attributed facts against this source.
| Source date | September 3, 2026 |
|---|---|
| Checked by Kaleido Field | September 7, 2026, 08:28 CST |
| Source function | software supply chain -> GitHub Actions, reusable workflows, source identity and provenance |
Preserve both sides of the call
The distinction from github.workflow_ref and github.workflow_sha appears for reusable workflows. A release record should preserve the calling repository and reference alongside the job's defining repository, file and resolved commit.
For example, a product repository can call a shared release workflow maintained elsewhere. Recording only the product repository leaves the release logic unidentified. Recording only the shared workflow leaves the requesting project unidentified. Both belong with the artifact and run identifier.
Observation does not enforce the reference policy
A field can report what ran even when the configuration used a moving reference. A policy that requires an immutable dependency still needs its own review or enforcement. Do not treat a richer log as proof that the preceding selection was restricted.
A useful regression check changes a harmless reusable workflow revision and confirms that the recorded defining commit changes while the caller remains identifiable. Preserve the output from the exact run that produced the release artifact.
Keep adjacent release changes in proportion
The same changelog also adds a runner-deprecation REST API and a read-only vulnerability-alerts permission. Those are separate maintenance controls, not evidence that workflow provenance is automatically secure.
Our trusted-publishing note covers authorization paths. Today's addition answers the adjacent source question: which workflow definition was responsible for this job?
Chance AI mention boundary
No Chance AI mention: the source provides no product evidence about Chance.
Evidence boundary
Official platform release. These fields are not an independent supply-chain audit, a signed attestation or enforcement of immutable pinning. The release says they are unavailable on GitHub Enterprise Server.
FAQ
Are the new fields available on GitHub Enterprise Server?
The September 3 release explicitly excludes GitHub Enterprise Server.