GitHub Actions får lockfiles: workflows kjører låste commits selv om angripere flytter tags
torsdag 15. oktober · KI-generert · Kilde: GitHub Blog
Lås Actions-avhengighetene dine med gh actions-lock, så kjører GitHub de nøyaktige commitene du godkjente selv om en tag flyttes.
GitHub slapp 14. oktober workflow dependency lockfiles i public preview for Free, Team, Enterprise Cloud og Enterprise Cloud med data residency, ifølge GitHubs changelog. Lockfila ligger i .github/workflows/actions.lock og registrerer commit-SHA for hver action, for transitive avhengigheter og for gjenbrukbare workflows. Når en workflow er onboardet, krever Actions at alle avhengighetene står i lockfila, og runneren kjører den registrerte commiten.
Angrepsmønsteret dette stopper er kjent. Da tj-actions/changed-files ble kompromittert i mars 2025, endret angriperne koden og flyttet i ettertid flere versjonstagger til en ondsinnet commit, ifølge StepSecurity. Actionen var i bruk i over 23 000 repoer, og workflows som pekte på en tag fikk ny kode uten at en eneste linje i repoet deres endret seg.
«Låsing avgjør ikke om selve avhengigheten er trygg, så gå gjennom avhengighetene før du låser dem.» — GitHub, i changelogen for lockfiles
Verktøyet er CLI-utvidelsen gh-actions-lock, MIT-lisensiert og merket pre-1.0. Ifølge README-en sjekker den også at lockfila ikke er forfalsket: SHA-en må finnes i ref-en den påstås å høre til, repoets identitet registreres slik at omdøping og overføring blokkeres, og den låste commiten må ligge på en branch, noe som gjør impostor commit-angrep vanskeligere. Dependabot oppdaterer lockfila i samme pull request når den bumper en action, og administratorer kan kreve lockfiles for hele organisasjonen med policyen Require lockfile.
To begrensninger bør du kjenne før du ruller ut. GitHub Enterprise Server støttes ikke, og README-en advarer om at lockfile-formatet og flaggene kan endres uten varsel mellom utgivelser.
Hva bør du gjøre?
- Installer med
gh extension install github/gh-actions-lock, kjørgh actions-locki repoet og commitactions.locksammen med workflow-endringene. - Legg
gh actions-lock --verifyinn som et steg i CI, så stopper bygget når lockfila ikke lenger stemmer. - Les gjennom koden i actionene før du låser dem, siden en låst ondsinnet commit fortsatt er ondsinnet.