https://www.cloudkaramchari.com/tags/gh-actions-lock/Recent content in Gh Actions-Lock on CloudkaramchariHugo -- gohugo.ioencloudkaramchariThu, 15 Oct 2026 22:07:00 +0530https://www.cloudkaramchari.com/blog/github-actions-workflow-lockfiles-setup-guide-gh-actions-lock-require-lockfile-policy/Thu, 15 Oct 2026 22:07:00 +0530https://www.cloudkaramchari.com/blog/github-actions-workflow-lockfiles-setup-guide-gh-actions-lock-require-lockfile-policy/ <h1 id="github-actions-workflow-lockfiles-pin-every-action-with-gh-actions-lock-and-enforce-it">GitHub Actions Workflow Lockfiles: Pin Every Action With gh actions-lock and Enforce It</h1> <p>A line like <code>uses: actions/checkout@v7</code> does not name a piece of code. It names a tag, and the owner of that repository can point the tag at a different commit whenever they like. When we resolved it on October 15, 2026, <code>actions/checkout</code>'s <code>v7</code> tag pointed at the same commit as <code>v7.0.1</code>, not <code>v7.0.0</code>. That is normal: major-version tags are meant to move. It is also how most GitHub Actions supply-chain attacks of the last two years reached their victims. An attacker who gets write access to a popular action re-points its tags, and every workflow that trusts the tag runs the new code on its next run.</p>