The dependencies in a CI workflow deserve the same attention as the packages in the application it builds. A short action reference can run code with access to the workspace and, depending on the job, credentials. I want changes to that code to be reviewable rather than arriving as an invisible consequence of a moved tag.
GitHub’s workflow dependency lockfiles record verified commits and repository identities. As checked on 26 October 2026, the feature is a public preview for GitHub Enterprise Cloud. It covers action dependencies, including transitive actions; reusable workflows have their own repository’s lockfile boundary. That scope is worth understanding before assuming one file locks everything everywhere.
For repositories that cannot adopt it, GitHub’s secure-use guidance still describes full-length commit SHA pinning. Neither option proves the selected code is safe. Review what you are selecting, limit the job’s permissions, and keep a deliberate update process so a stable reference does not become a permanently forgotten dependency.
For me, the useful outcome is being able to answer which code ran and why it was allowed to change. A lockfile can make that answer easier to maintain. Treat the workflow as part of the software supply chain, then give its dependency updates the same clear review boundary as the rest of the application.
