Lås GitHub Actions till SHA – taggen kan flyttas efter granskningen

För att låsa en extern action i GitHub Actions ersätter du taggen efter @ i dess uses-referens med ett fullständigt commit-SHA från actionens eget repo. GitHubs säkerhetsråd rekommenderar detta när en arbetsflödeslåfil inte används och påpekar att en tagg kan flyttas eller tas bort efter granskningen. SHA-referensen fortsätter då att välja samma commit.

Behåll versionsnamnet som kommentar på samma rad och låt en uppdateringsbot föreslå nya versioner. Då blir den valda utgåvan läsbar för granskare, samtidigt som varje nytt SHA kan kontrolleras innan det införs. Låsningen skyddar mot att en tagg byter innehåll mellan granskning och körning, men den sköter inte underhållet åt dig.

Inventera alla externa uses-referenser

Gå igenom filerna i .github/workflows och sök efter uses: både i steg och på jobbnivå, där externa återanvändbara arbetsflöden kan anropas. Anteckna ägare, repo, eventuell undersökväg och nuvarande tagg för varje referens. Samma action kan finnas på flera ställen, och en kvarlämnad taggreferens kan fortfarande påverka ett bygge eller en publicering.

OpenSSF Scorecards kontroll för låsta beroenden letar efter olåsta beroenden bland annat i GitHub-arbetsflöden som används för bygge och release. Det är en användbar avgränsning när du prioriterar, men inventeringen bör också omfatta andra arbetsflöden som kör externa actions. En lokal referens som börjar med ./ pekar på kod i det egna repot och granskas därför som en del av den egna ändringen.

Separera också referenser som börjar med docker://. De pekar på containerbilder och följer inte syntaxen ägare/repo@SHA för en action i ett GitHub-repo. Ändra inte sådana referenser genom att klistra in ett Git-commit-SHA efter @; de behöver en egen kontroll av bildens identitet och uppdateringsväg.

Verifiera commiten innan du kopierar SHA:t

Utgå från den release eller tagg som actionens avsedda repo publicerar och öppna commiten som den pekar på. Jämför den fullständiga repo-adressen med delen före @ i uses-referensen. En commit som endast finns i en fork ska inte användas som om den hörde till originalrepot; själva hashvärdet berättar inte vilken källa du avsåg att lita på.

Granska koden på den valda commiten, inte bara releasesidans versionsnamn. Läs action.yml eller action.yaml och följ de skript eller program som actionen faktiskt kör. Kontrollera särskilt hur indata, GITHUB_TOKEN och hemligheter används, vilka externa resurser som kontaktas och om actionen hämtar ytterligare kod vid körning. Ett exakt SHA ger ett stabilt val av actionens commit, inte en garanti för allt som den commiten gör.

Om du uppdaterar en redan använd action, jämför skillnaden mellan den gamla och den nya commiten i samma repo. Det gör nya behörighetskrav, ändrade körkommandon och nya beroenden lättare att upptäcka. Kopiera hela commit-SHA:t från commitvyn; en förkortad identifierare är inte den fullständiga referens som rekommenderas för arbetsflödet.

Byt referensen och märk den med versionen

Ersätt endast delen efter @ och behåll ägare, repo och eventuell sökväg till actionen. Schematiskt kan uses: ägare/action@tagg bli uses: ägare/action@<fullständigt-SHA> # tagg. Platshållaren måste ersättas med det verkliga SHA:t från det kontrollerade repot. Det är SHA:t som styr vilken commit som körs; kommentaren dokumenterar vilken version du avsåg.

Placera kommentaren på samma rad som uses-referensen. Då kan Dependabot uppdatera versionsdokumentationen tillsammans med referensen, och granskaren kan jämföra ett föreslaget versionsbyte med dess nya commit. Om det valda SHA:t inte hör till någon tagg kan botens nästa förslag i stället peka mot senaste commit, som kan skilja sig från senaste release. Kopplingen mellan SHA och utgåva behöver därför kontrolleras även när förslaget ser rutinmässigt ut.

Gör ändringen i varje berört arbetsflöde och granska diffen innan den slås ihop. Kontrollera att ingen rad har bytt repo eller sökväg av misstag och att alla avsedda förekomster pekar på den granskade commiten. Kör sedan de vanliga CI-jobben för att fånga syntaxfel och beteendeförändringar. Ett lyckat jobb visar att just de kontrollerna passerade, inte att actionens kod är säker.

Låt Dependabot hitta nya versioner

Skapa .github/dependabot.yml, eller komplettera den befintliga filen, med package-ecosystem: github-actions, directory: / och ett schedule.interval. GitHubs Dependabot-instruktion använder weekly som exempel och anger att konfigurationen ska ligga i repots .github-katalog. När boten hittar en ny version kan den öppna ett ändringsförslag för granskning.

Bestäm vem som tar emot förslagen och hur de ska prioriteras. En veckovis kontroll kan passa vanlig versionsvård, medan en känd säkerhetsrättning kan kräva snabbare handläggning än nästa schemalagda uppdatering. Automatiska verktyg hjälper till att hitta nya versioner, men en låst commit får inte själv en rättning när underhållaren publicerar ny kod.

Skilj mellan versionsförslag och sårbarhetslarm. Dependabot kan föreslå uppdateringar av action-referenser med GitHub-reposyntax, även när de använder SHA, men Dependabot-larm för sårbara GitHub Actions skapas bara för semantiska versionsreferenser. Bevaka därför relevanta säkerhetsmeddelanden för de actions ni använder och låt inte frånvaron av larm avgöra om en låst commit kan behöva bytas.

Granska varje byte innan det slås ihop

När ett förslag kommer, kontrollera att det nya SHA:t finns i samma avsedda repo och att versionskommentaren motsvarar den utgåva du vill använda. Jämför committerna och läs versionsinformationen om actionens beteende eller krav har ändrats. Var särskilt uppmärksam på ändringar i skript, externa beroenden, tokenbehörigheter och hantering av hemligheter.

Låt arbetsflödesändringen gå genom kodgranskning även om en bot har skapat den. En separat granskare kan se om den föreslagna commiten faktiskt rättar ett problem utan att ändra mer än ni accepterar. Vid en relevant säkerhetsrättning behöver ett godkänt nytt SHA införas i arbetsflödet; den gamla commiten ändras inte för att en ny release finns.

En arbetsflödeslåfil kan ge bredare skydd genom att låsa även underliggande action-beroenden och verifiera källrepots identitet vid körning. Direkta SHA-referenser i uses ger inte automatiskt samma täckning. För ett repo som fortsätter med SHA i arbetsflödesfilen behövs därför både källkontroll, versionskommentar, uppdateringsförslag och granskning.

Läs också:

• Gamla GitHub-runners stoppas – version 2.329.0 räcker inte alltid
• Radera Google-aktivitet automatiskt – webbhistoriken kan ändå ligga kvar
• Prompt injection stoppas inte av ett filter – lås agentens verktyg