Free tool: runs in your browser
GitHub Actions workflow lockfile checklistbefore you merge a workflow that calls third-party actions
TimeBinder adds a layer of protection against AI and human fraud and disputes. Review the current lockfile docs, the actions you will lock, and the exact workflow and lockfile you can still show, before you merge or rely on a workflow that calls third-party actions.
Nothing you tick is sent anywhere. Locking does not determine whether a dependency itself is safe. This page cannot show that an action is safe.
Check the lockfile and copies you can still show
Tick what is true of the current docs, the review you have done, and the exact workflow and lockfile you will keep. You get a shareable result and clear next steps. Nothing you tick is sent to TimeBinder.
Your choices stay on this page. Nothing you tick is sent anywhere or tied to your name.
Tick everything that is true before you merge a workflow that calls third-party actions
This looks at the current workflow dependency lockfile docs, a review of the actions you will lock, and the exact workflow and lockfile you can still show. Locking does not determine whether a dependency itself is safe.
What to do now
What should I keep before I merge a workflow that calls third-party actions? The short answer
Keep a dated copy of the workflow file and of the .github/workflows/actions.lock file you will merge, after generating or updating it with gh actions-lock. Review the actions, including transitive dependencies, before you lock them. Pin reusable workflow calls to a full commit SHA separately. If omitted or stale, an onboarded workflow may not be doing what a tag in the YAML still appears to say.
This checklist is not a safety decision. GitHub says locking does not determine whether the dependency itself is safe. A TimeBind of a file you already hold can show that exact file existed no later than a recorded time and still matches. It cannot show what a later run executed.
Why this came up in mid-October 2026
On 14 October 2026, GitHub published GitHub Actions workflow lockfiles in public preview. The changelog says workflow dependency lockfiles are in public preview for GitHub Enterprise Cloud, GitHub Enterprise Cloud with data residency, Team and Free plans. An editor’s note the same day updated which plans have access to the preview.
The changelog says tags and branches can move after you review a workflow, so a later run might execute different code. If an action is compromised, a moved tag or branch can introduce malicious code into a workflow without a change to your repository. Lockfiles keep those references in the workflow while running the exact commits you locked. The same post is explicit: “Locking does not determine whether the dependency itself is safe, so review dependencies before locking them.”
The current GitHub Docs page on workflow dependency lockfiles describes the same job in more detail. The lockfile is defined at .github/workflows/actions.lock. It is generated by gh actions-lock, a GitHub CLI extension, and should never be edited by hand. A lockfile pins a commit SHA to every action the workflows depend on, including transitive dependencies. It does not pin calls to reusable workflows; those should be referenced by full commit SHA. It controls which action code runs on the runner, and it does not control other build inputs, such as input parameters, secrets or the runner image. After a workflow is onboarded, every action dependency it uses must be present in the lockfile, and the locked commit is what runs. The changelog also notes that a Require lockfile policy is in public preview, and that Dependabot can regenerate a matching lockfile entry when it opens a version update.
Measured demand is current. Autocomplete checked on 12 November 2026, about 10:34 PM Australia/Brisbane, returned suggestion clusters for “github actions lockfile”, including “github actions workflow lockfiles preview”, for “github actions pin commit sha”, and for “github require actions to be pinned to a full length commit sha”. A dated YouTube sample the same evening included a 15 October 2026 video, “Your GitHub Actions Tags Can Change Overnight - The New Lockfile Stops That”, a 15 October 2026 video on GitHub Actions and lockfiles, a 17 October 2026 explainer of what the lockfile does, and a 24 October 2026 video, “Pin GitHub Actions to a SHA: Lockfiles and Immutable Releases”. An X search of the same window, first page of 24 posts as a lower bound, was almost entirely about the new lockfile, including a 30 October 2026 post with 713 impressions and 12 likes at the check, and a 12 November 2026 post with 338 impressions. Some later posts describe the feature as generally available. This page follows the dated official changelog (public preview, 14 October 2026) and the current Docs page, and does not treat unofficial “GA” wording as an official status change. Counts and suggestions will keep moving.
The checks are written for the next time a developer or maintainer is about to merge or rely on a workflow that calls third-party actions. Always read the current Docs, review the actions before you lock them, and follow any organisation policy that applies, including a Require lockfile policy if one is on.
Sources: the 14 October 2026 GitHub changelog and the current workflow dependency lockfiles Docs page.
What this checklist does and does not do
The honest job of this page is to slow down a merge until the actions have been reviewed, the lockfile is in hand, and the exact copies are kept, not to certify a dependency for you. See also the glossary entries for existed no later than and fingerprint.
| Part | What it does | What it does not do |
|---|---|---|
| Current lockfile docs | Reminds you to read how actions.lock is generated, what it pins, and that it should not be edited by hand. | Configure GitHub for you, or show that a preview or policy is on in your organisation. |
| Review before locking | Gives you a reason to pause and review actions, including transitive dependencies, before you generate or update the lockfile. | Show that a dependency itself is safe. GitHub says locking does not determine that. |
| Copies you already hold | Reminds you to keep the exact workflow file and lockfile you will merge. | Show that a later run executed those commits, or that inputs, secrets and the runner image were unchanged. |
| A TimeBind of a file you already hold | Records that an exact file existed no later than a recorded time and still matches, using a SHA-256 fingerprint made in your browser. The file stays on your device. | Show that an action is safe, or what a later CI run executed. |
If a workflow file is one you may need to stand behind later
Before you merge or rely on a workflow that calls third-party actions:
- Keep a dated copy of the exact workflow file and of the lockfile you will merge.
- Make a TimeBind of each exact file or archive you already hold. The fingerprint is made in your browser and the file stays on your device. You can later download a Proof of Time Certificate.
- Read the current lockfile docs first, review the actions before you lock them, and store the files, the docs capture and the certificate together.
A TimeBind shows the exact file existed no later than the recorded time and still matches. It cannot show that an action is safe.
First Pooled TimeBind free, no card, then from US$5. An ASAP TimeBind is US$15.
What a TimeBind shows, and what it does not. It shows that an exact file existed no later than a recorded time and that a copy shown later still matches its fingerprint. It does not show who made the file, who owns it, that its contents are true, or whether AI was used to make or edit it. This is general information, not legal advice.
If you suspect a malicious commit has already reached your workflows, see also the free GitHub Actions secret exposure response checklist. It cannot tell you whether a secret was stolen.
GitHub Actions workflow lockfile checklist: FAQ
Can this tool show that a GitHub Action is safe?
No. GitHub’s 14 October 2026 changelog says locking does not determine whether the dependency itself is safe, so you should review dependencies before locking them. This checklist cannot show that an action is safe, and it cannot show what a later run executed.
What should I keep before I merge a workflow that calls third-party actions?
A dated copy of the workflow file and of the lockfile you will merge, a dated copy of the current GitHub Docs wording you relied on, and a note of the reviews you did. A TimeBind of an exact file you already hold can show that file existed no later than a recorded time and still matches.
What does a workflow dependency lockfile actually pin?
The current GitHub Docs say a lockfile pins a commit SHA to every action your workflows depend on, including transitive dependencies, and that it is defined at .github/workflows/actions.lock, generated by the gh actions-lock GitHub CLI extension, and should never be edited by hand. The locked commit is what runs when an onboarded workflow executes. A lockfile does not pin calls to reusable workflows; those should be referenced by full commit SHA. A lockfile also does not control other build inputs, such as input parameters, secrets or the runner image.
Why not just pin every action to a tag in the workflow file?
The current Docs say workflows often reference an action by a tag or branch, that GitHub Actions resolves that reference to whatever commit the tag or branch points to at run time, and that tags and branches can move. If an upstream maintainer’s account is compromised and a tag is repointed, repositories could run malicious code. A lockfile lets you keep those tag references in the workflow while running the exact commits you locked. That still does not show the dependency itself is safe.
Is anything I tick sent to TimeBinder?
No. The checklist runs in your browser. Your ticks stay on the page.
Is this a substitute for secret scanning or a security review?
No. A neighbouring job on this site is the cloud coding assistant checklist, when the next step is sharing code with a cloud assistant, and the article on what to keep after a GitHub Actions CI secret-stealer incident, when a compromised action is already in play. This page is only about pausing to review, lock and keep copies before you merge or rely on a workflow.
Related guides and tools
- Cloud coding assistant checklistA neighbouring job before you share a private repo or client code with a cloud assistant
- Vibe-coding review checklistA checklist before you rely on assistant-written code
- GitHub Actions CI secret-stealer: what developers should keepWhat to keep if a compromised action is already in play
- Developer timestampingThe TimeBinder hub for developer file records
- Source code timestampingDated records for source you already hold
- GlossaryPlain definitions of fingerprint, SHA-256 and existed no later than
- All free toolsPrivate, in-browser tools
Date the exact files you already hold
Add a layer of protection against AI and human fraud and disputes: a dated, checkable record of the exact workflow and lockfile, kept beside the docs wording you may later need to show.
- Open the app and sign in with email or Google.
- Add your files. They stay on your computer.
- Seal them and download your Proof of Time certificates.
First Pooled TimeBind free, no card, then from US$5. See pricing.