Praktisk säkerhetshärdning för GitHub-åtgärder

Hem » Python » Praktisk säkerhetshärdning för GitHub-åtgärder

GitHub Actions har blivit den officiella CI/CD-motorn för repositorier som finns på GitHub., som driver allt från enhetstester till produktionsdistributioner och infrastrukturförändringar. Den bekvämligheten kommer med en allvarlig avvägning: arbetsflöden körs ofta med breda behörigheter, hanterar kraftfulla tokens och hemligheter och kan nå produktionssystem direkt. Om du inte medvetet härdar dem ger du effektivt varje felkonfiguration, beroendebugg eller komprometterat konto en snabb fil in i dina pipelines och molnkonton.

Den här guiden går igenom en omfattande och välgrundad checklista för att säkra GitHub Actions från början till slut.: hur man hanterar hemligheter korrekt, undviker skriptinjektion, låser tokens och triggers, utvärderar tredjepartsåtgärder, hanterar runners och drar nytta av inbyggda säkerhetsfunktioner som kodskanning, OIDC, Dependabot och revisionsloggar. Målet är att sammanföra de spridda bästa praxisen, hårt vunna lärdomar från senaste incidenter och GitHubs egna riktlinjer för hårdare implementering i en enda, praktisk referens som du kan tillämpa i verkliga projekt.

Den verkliga riskprofilen för GitHub Actions

På en övergripande nivå är ett GitHub Actions-arbetsflöde bara en YAML-fil under .github/workflows som definierar ett eller flera jobb, där varje jobb består av steg. Steg kan antingen köra shell-kommandon eller anropa återanvändbara åtgärder som publiceras av GitHub eller communityn. Arbetsflöden utlöses av händelser som pushes, pull requests, ärendeaktivitet, scheman eller manuella utskick.

Ur ett säkerhetsperspektiv ligger dessa arbetsflöden direkt ovanpå din programvaruleveranskedjaDe bygger och signerar releaseartefakter, pushar Docker-avbildningar, distribuerar till molnmiljöer, provisionerar infrastruktur, kör migreringar med mera. Om en angripare kan kontrollera koden, konfigurationen eller miljön som ett privilegierat arbetsflöde körs i, kan de ofta:

• Bakdörrskompilerade artefakter (binärfiler, containrar, paket) som du senare skickar till kunder.
• Utplåna kraftfulla långlivade tokens och hemligheter från minne, loggar, cacher eller artefakter.
• Missbruka privilegierade molnroller beviljats ​​CI för att driftsätta extra tjänster, ändra nätverk eller komma åt data.
• Förgiftningsprojekt nedströms genom att kompromettera pipelines för öppen källkod och distribuera trojanska utgåvor.

Nyligen genomförda verkliga händelser har understrukit hur attraktiv GitHub Actions är som en attackytaAngripare har missbrukat sårbara arbetsflöden för att injicera kryptominers i publicerade paket, och den populära tj-actions/changed-files åtgärden komprometterades i en flerstegsattack som försökte nå Coinbase. Den skadliga koden extraherade hemligheter från arbetsflöden och skrev dem in i byggloggar, vilket skapade en potentiell kaskad av efterföljande komprometter i leveranskedjan.

Den viktigaste idén att komma ihåg är att de flesta GitHub Actions-attacker handlar om "sannolikhet × påverkan"Du vill minska sannolikheten för att du använder skadliga eller buggiga komponenter (tredjepartsåtgärder, osäkra löpare, riskabla utlösare) och samtidigt dramatiskt begränsa explosionsradien om någon enskild komponent komprometteras.

Låsa hemligheter i GitHub Actions

Hemligheter är oftast det mest attraktiva målet i alla CI/CD-systemI GitHub-åtgärder visas de som hemligheter för arkiv, organisation eller miljö, och som ad hoc-värden som du av misstag kan dumpa i konfigurationer, loggar, cacher eller artefakter.

Det första man måste internalisera är åtkomstmodellen: vem som helst med skrivåtkomst till ett arkiv kan effektivt läsa alla hemligheter på arkivnivåDe kan helt enkelt modifiera ett befintligt arbetsflöde på en oskyddad gren, injicera loggnings- eller exfiltreringskod och köra det arbetsflödet för att skriva ut eller läcka hemligheter. GitHubs maskering i loggar är ett försvar enligt bästa förmåga, inte en ofelbar garanti.

För att hålla hemligheter överlevbara enligt den modellen, följ dessa grundläggande regler:

• Tillämpa principen om minsta privilegiumAlla autentiseringsuppgifter som används i ett arbetsflöde måste endast ha de absolut nödvändiga behörigheterna. Undvik att dela allmänna administratörstokens som arbetsflödeshemligheter.
• Föredra miljöhemligheter framför databas- eller organisationshemligheter för känsliga värdenMiljöhemligheter är endast tillgängliga för jobb som deklarerar den miljön, och du kan förse dem med extra skydd som obligatoriska granskare och begränsningar för grenar.
• Lagra aldrig hemligheter i klartext i arbetsflödes-YAML-filer eller i kod som checkats in i repot. Allt känsligt bör gå igenom GitHub Secrets-mekanismen eller en extern hemlighetshanterare.
• Undvik att använda strukturerade blobbar (JSON, YAML, XML) som ett enda hemligt värdeMaskering bygger till stor del på exakt strängmatchning; flerfältsblobbar är mycket svårare att på ett tillförlitligt sätt redigera bort. Dela istället upp känslig data i flera dedikerade hemliga poster.
• Registrera alla härledda hemligheter explicitOm du transformerar en hemlighet (Base64, URL-kodning, JWT-signering, etc.) och det resultatet någonsin kan hamna i loggarna, registrera det transformerade värdet som en egen hemlighet så att GitHub kan försöka maskera det.

Rotation och hygien är lika viktiga som den initiala konfigurationenGranska regelbundet vilka hemligheter som finns, vem och vad som faktiskt fortfarande behöver dem, och ta bort eller rotera alla som är föråldrade. Efter misstänkt exponering (till exempel en hemlighet som skrivits ut oredigerad i loggar eller används i en komprometterad åtgärd), ta omedelbart bort berörda loggar, återkalla autentiseringsuppgifterna och skapa nya.

Undvika skriptinjektion och osäker interpolering

En av de vanligaste, men ändå subtila, klasserna av GitHub Actions-buggar är skriptinjektion genom uttryck.GitHub tillhandahåller omfattande "kontexter" som till exempel github, env, secrets och händelsenyttolaster, som du refererar till i arbetsflöden med hjälp av ${{ ... }} syntax. Dessa uttryck utvärderas av GitHub innan ditt skalsteg körs.

När du bäddar in en opålitlig kontext direkt i ett shell-kommando, inbjuder du till kommandoinjektion.Om du till exempel gör:

run: echo "new issue ${{ github.event.issue.title }} created"

och en angripare kan kontrollera problemets titel, de kan skicka in en titel som $(id)Efter uttrycksutvärderingen blir steget:

echo "new issue $(id) created"

som exekverar id på löparenInte en enda mängd justeringar av citattecken eller enkel validering i skalet kommer att rädda dig från det här mönstret på ett tillförlitligt sätt.

Det säkra mönstret som GitHub rekommenderar är att använda en mellanliggande miljövariabel.:

env:
TITLE: ${{ github.event.issue.title }}
run: |
echo "new issue \"$TITLE\" created"

Här lagras det potentiellt fientliga värdet i minnet som en miljövariabel, och skalet ser bara $TITLE, inte en dynamiskt konstruerad kommandorad. Du behöver fortfarande normal skalhygien (citera variabler, undvika onödig evalering etc.), men det farliga interpoleringssteget tas bort.

När du frestas att bädda in ${{ github.* }} eller annan användarstyrd data direkt in i run: block, stanna och tryck igenom den env: iställetDen här vanan eliminerar en hel klass av problem med skriptinjicering i dina arbetsflöden.

Konfigurera behörigheter och tokens säkert

Ocuco-landskapet GITHUB_TOKEN som GitHub injicerar i varje arbetsflödeskörning är otroligt kraftfull om den lämnas med standardinställningarnaDen kan läsa och skriva innehåll, öppna och uppdatera pull requests och interagera med repot på många sätt. Historiskt sett har många organisationer haft den som standard inställd på läsande och skrivande utan att inse det.

Ditt första steg bör vara att ställa in standardbehörigheterna för arbetsflödestoken till skrivskyddad. på organisations- och/eller databasnivå. Det finns en dedikerad inställning för detta i konfigurationen för åtgärder. Därifrån kan du selektivt bevilja extra behörigheter per arbetsflöde eller per jobb, till exempel:

permissions:
contents: read
pull-requests: write

Denna modell ”neka som standard, tillåt vid behov” minskar dramatiskt vad en angripare kan göra med ett komprometterat arbetsflödeDet tvingar också författare att tänka på vilka förmågor deras jobb faktiskt kräver istället för att ärva en samlartoken.

Om din organisation skapades före början av 2023 bör du uttryckligen granska dessa standardinställningar.Många äldre organisationer har fortfarande skrivaktiverade arbetsflödestokens eftersom de är äldre än den säkrare standarden och aldrig har valt att använda ändringen.

Utöver token-omfång, var mycket försiktig med inställningar som låter GitHub Actions godkänna eller skapa pull requests.Att låta arbetsflöden godkänna PR:er öppnar upp för missbruksvägar där komprometterade jobb sammanfogar skadlig kod utan mänsklig granskning. Om du inte har ett starkt användningsfall och tydliga skyddsräcken, låt den funktionen vara inaktiverad.

Välja och fästa tredjepartsåtgärder

Varje extern åtgärd du använder är en fjärrkod som körs med samma behörigheter som resten av ditt jobb.Om den åtgärden blir skadlig, komprometteras eller avbryts med sårbara beroenden, blir den ett färdigt fotfäste i din pipeline.

Det finns flera försvarslager du kan tillämpa när du använder tredjepartsåtgärder:

• Börja med en liten, betrodd godkännandelistaGitHub-underhållna åtgärder (som actions/checkout, actions/setup-node) och marknadsplatsåtgärder från verifierade skapare är vanligtvis en säkrare baslinje än slumpmässiga repositorier. Många organisationer tillämpar detta via "Tillåt angivna åtgärder och återanvändbara arbetsflöden" på organisationsnivå.
• Föredra populära, aktivt upprätthållna handlingarForskning visar att många marknadsplatsåtgärder har låga OpenSSF Scorecard-poäng, enstaka ansvarigheter och kortlivade eller mycket unga ägarkonton. Åtgärder som används ofta tenderar att granskas mer och få snabbare lösningar.
• Håll utkik efter ett stort antal öppna Dependabot PR:er i åtgärdens repo.Det är ofta ett tecken på att utvecklaren inte installerar säkerhetsuppdateringar, vilket lämnar transitiva sårbarheter ouppdaterade.
• Föredra åtgärder med mer än en utvecklare och en icke-arkiverad, aktiv kodbasHundratals åtgärder på marknaden arkiveras, vilket innebär inga nya korrigeringar eller kompatibilitetsuppdateringar och en växande risk över tid.

Versionslåsning är ett annat viktigt ämneOm du anger en åtgärd endast via tagg, till exempel some-org/some-action@v2, du litar på att taggen aldrig flyttas till skadlig kod. Taggar kan omdirigeras om ansvariga kontot eller arkivet komprometteras.

Det mest defensiva tillvägagångssättet idag är att fästa till en fullständig commit SHA:

uses: some-org/some-action@247835779184621ab13782ac328988703583285a

Att fästa till en SHA gör koden i praktiken oföränderlig ur ditt perspektiv. (förutom en SHA-1-kollisionsattack på Git-objekt). Nackdelen är operationell: du måste uppdatera SHA:n när du vill ha nya funktioner eller korrigeringar, och olika arbetsflöden kan glida till olika SHA:er om du inte är försiktig.

För att lindra den smärtan centraliserar vissa team användningen av tredjepartsåtgärder till delade eller sammansatta arbetsflödenEnskilda databaser refererar till dessa delade arbetsflöden via taggar, medan de delade arbetsflödena fäster de underliggande åtgärderna till granskade SHA:er och uppdateras i en kontrollerad takt, ibland med verktyg som öppnar PR:er för nya SHA:er.

Oavsett vilken strategi du väljer, kom ihåg att pinning inte är en magisk brandväggEn åtgärd kan fortfarande dynamiskt hämta kod vid körning (till exempel via curl | bash mönster) och kringgå din PIN-kod. Du måste fortfarande skumma igenom källan efter uppenbart osäkra mönster innan du litar på en åtgärd med hemligheter eller skrivbara tokens.

Utforma säkrare arbetsflöden och jobb

Hur du strukturerar arbetsflöden och jobb påverkar starkt sprängradien för en kompromissEtt vanligt antimönster är ett enda jättejobb som kontrollerar kod, bygger, testar, paketerar och driftsätter, allt samtidigt som man har breda behörigheter och åtkomst till produktionshemligheter.

Att dela upp arbete i separata jobb och till och med separata arbetsflöden ger både isolering och tydlighetTill exempel kan du ha:

• A bygg- och testjobb som körs med minimala behörigheter och inga distributionshemligheter.
• A paketjobb som producerar signerade artefakter men fortfarande inte kommunicerar med produktion.
• A distribuera jobb som är beroende av de andra och är den enda som har åtkomst till miljöhemligheter och antar molnroller.

På GitHub-hostade runners körs varje jobb i ett arbetsflöde i en ny virtuell maskin., vilket ger dig en viss grad av isolering mellan jobb. Det är inte likvärdigt med en härdad sandlåda, och det finns kända vektorer för korsjobb (som delade grencacher), men att dela upp jobb tvingar fortfarande angripare att arbeta hårdare och minskar oavsiktligt läckage av hemligheter till orelaterade steg.

Använd miljöer för att koppla känsliga steg till skyddEtt distributionsjobb kan deklarera:

environment: production

och production miljön kan sedan konfigureras för att endast acceptera distributioner från en skyddad gren, eventuellt med obligatoriska manuella godkännanden. Genom att kombinera detta med strikta regler för filialskydd (obligatoriska granskningar, inga snabbspola framåt, avvisande av inaktuella godkännanden) kommer du nära en fyrögonprincip för produktionsändringar.

Slutligen, var försiktig med artefakter, cacher och loggarDe är praktiska sätt att dela data mellan jobb och arbetsflöden, men:

• Samla inte hemligheter i cacher, särskilt inte välkända platser som ~/.docker/config.json som kan innehålla vanliga Docker-inloggningsuppgifter.
• Undvik att logga hemligheter eller dumpa hela kontexter till loggar, eftersom detta kan omintetgöra maskering eller avslöja härledda värden som GitHub inte vet att redigera.
• Kom ihåg att alla med läsåtkomst till repot vanligtvis kan ladda ner artefakter och bläddra i loggar., inklusive externa samarbetspartners om du ger dem åtkomst.

OIDC och kortlivade molnuppgifter

En av de mest effektfulla förändringarna du kan göra är att helt sluta lagra långlivade molnleverantörsuppgifter som GitHub-hemligheter.Använd istället OpenID Connect (OIDC) för att få kortlivade, väldefinierade tokens bundna till en specifik arbetsflödesidentitet.

Högnivåflödet är enkelt:

• Din molnleverantör (AWS, Azure, GCP, etc.) är konfigurerad för att lita på GitHubs OIDC-leverantör.
• Du definierar en identitetspolicy som säger "acceptera endast tokens från denna organisation/repo/filial eller miljö".
• Under ett jobb kan GitHub begära en OIDC-token och ditt arbetsflöde använder en molnspecifik åtgärd (till exempel aws-actions/configure-aws-credentials) för att byta ut det mot en kortlivad roll- eller servicekontotoken.

Det är i förtroendetillståndet man kan bli väldigt detaljeradFör AWS kan en typisk policy innefatta:

"StringEquals": {
"token.actions.githubusercontent.com:aud": "sts.amazonaws.com",
"token.actions.githubusercontent.com:sub": "repo:Org/Repo:ref:refs/heads/main"
}

Det säkerställer att endast arbetsflöden från ett specifikt repository och en specifik filial kan ta på sig rollen.Om du vill ha ännu snävare omfattning kan du koppla rollen till en specifik miljö istället för en gren och sedan kräva att den miljön endast gäller för distributionsjobbet. En komprometterad tredjepartsåtgärd i ett jobb som inte är distributionsbart kommer att upptäcka att OIDC-anrop helt enkelt misslyckas.

Att använda OIDC eliminerar inte behovet av principer för roll med lägsta behörighet i molnet., men det eliminerar statiska åtkomstnycklar som finns i GitHub Secrets, där de kan stjälas och återanvändas på obestämd tid utanför GitHub.

Grenskydd, regeluppsättningar och miljöer som arbetar tillsammans

Många av de skrämmande attackvägarna i GitHub Actions kokar ner till "angripare injicerar skadliga ändringar i en skyddad gren"Skydd av grenar och regelverk är din huvudsakliga försvarslinje där.

På grenar som main or production, vill man vanligtvis ha minst:

• Kräv en pull request före sammanslagning – förbjud direkta knuffar.
• Kräv minst en (ofta fler) godkännande recension från någon annan än den sista föraren.
• Avfärda inaktuella godkännanden när nya commits läggs till – så att angripare inte kan smyga in kod efter granskning.
• Kräv godkännande av den senaste granskningsbara pushen – förhindrar att en angripare kapar någon annans PR, pusha dålig kod och godkänner sig själv.

Du kan sedan ansluta dessa skydd till miljöer. Till exempel a production miljön kanske bara accepterar distributioner från main grenen, och kanske också kräva manuellt godkännande från en liten grupp granskare (med "förhindra självgranskning" aktiverat). På så sätt kan ett enskilt komprometterat bidragsgivarkonto inte skicka godtycklig kod till produktion utan någon annans uttryckliga inblandning.

Var försiktig med miljöregler som är beroende av själva distributionerna (till exempel ”kräv att distributioner lyckas innan tagguppdateringar tillåts”). Om den är dåligt strukturerad kan du skapa cirkulära beroenden eller pseudokontroller som en samarbetspartner kan kringgå genom att redigera arbetsflöden. Det säkraste mönstret är fortfarande: starkt grenskydd → miljöer med begränsat omfång → explicit användning av dessa miljöer endast i de minimala jobb som verkligen behöver dem.

Hantera löpare: GitHub-hostad kontra egenhostad

Löpare är maskinerna som faktiskt utför dina arbetsflödenGitHub-hostade runners är tillfälliga virtuella maskiner som hanteras av GitHub; självhostade runners är maskiner eller containrar som du provisionerar och kontrollerar.

GitHub-hostade runners är generellt sett mycket säkrare som standard.:

• De är kortlivade och återställs för varje jobb., så det finns ingen bestående kompromiss mellan körningar.
• GitHub publicerar SBOM:er för standardavbildningar (Ubuntu, Windows, macOS), så att du kan analysera förinstallerad programvara för sårbarheter.
• Vissa skadliga värdar blockeras direkt (till exempel kända kryptominingpooler) via /etc/hosts konfiguration.

Självstyrda löpare är kraftfulla men farliga om du inte behandlar dem som produktionsservrar:

• De är vanligtvis inte efemära om du inte bygger det själv., så alla skadliga arbetsflöden kan försöka sig på persistens, lateral förflyttning eller datastöld.
• De har ofta bredare nätverksåtkomst och lokala hemligheter (SSH-nycklar, moln-CLI:er, metadatatjänster), vilket ökar risken för eventuella kompromisser.
• Publika arkiv bör nästan aldrig använda självhostade runners., eftersom vem som helst kan öppna en pull request som slutar med att exekvera kod på din infrastruktur.

Om du måste använda självhostade löpare, dela upp dem efter förtroendegränser.Använd löpargrupper och begränsningar så att:

• Offentliga och privata projekt delar aldrig samma löparpool.
• Högkänsliga repor (till exempel produktionsinfrastruktur) har sina egna noggrant kontrollerade löpare.
• Endast specifika databaser eller organisationer kan skicka jobb till en given grupp.

Du kan ytterligare minska risken med just-in-time (JIT)-körningar som tillhandahålls via REST API:et.Dessa löpare registreras dynamiskt, kör högst ett jobb och tas sedan bort automatiskt. Du måste fortfarande se till att den underliggande värden rensas eller förstörs, men det begränsar fönstret inom vilket ett komprometterat jobb kan påverka efterföljande jobb.

Behandla självhostade löpare som vilket annat produktionssystem som helstövervaka processaktivitet, lås utgående nätverksvägar, hålla operativsystem och verktyg uppdaterade och anta att alla användare med behörighet att utlösa arbetsflöden effektivt har kodkörning på den maskinen.

Inbyggda säkerhetsfunktioner: kodskanning, poängkort och Dependabot

GitHub levererar ett antal förstklassiga funktioner som är specifikt inriktade på att belysa arbetsflödes- och beroenderisker., och de är värda den lilla installationskostnaden.

Kodskanning (till exempel med CodeQL) kan nu själva analysera GitHub Actions-arbetsflöden, inte bara din applikationskälla. Regler som "Excessive Secrets Exposure" kan upptäcka mönster där GitHub inte kan avgöra vilka hemligheter som krävs (till exempel dynamiska secrets[myKey] användning i matrisbyggen), vilket leder till att den laddar fler hemligheter än nödvändigt i jobbminnet.

OpenSSF Scorecards och Scorecards-åtgärden lägger till ytterligare ett lager genom att gradera säkerhetsstatusen för dina beroenden.För åtgärder på marknaden kan Scorecards flagga osäkra metoder i leveranskedjan, såsom:

• Fäster inte beroenden.
• Saknade grenskydd eller krav på kodgranskning.
• Brist på säkerhetspolicy eller processer för hantering av sårbarheter.

Dependabot spelar två roller här:

• Dependabot-aviseringar varna dig när ett beroende av dina åtgärder eller arbetsflöden har en känd sårbarhet, baserat på GitHub Advisory Database.
• Dependabot-version och säkerhetsuppdateringar kan automatiskt öppna PR:er för att bumpa action-versioner och uppdatera sårbara utgåvor.

Beroendegrafen för arbetsflöden är en annan underskattad funktionGitHub behandlar dina arbetsflödesfiler som manifest och kan visa dig:

• Vilka åtgärder och återanvändbara arbetsflöden du är beroende av.
• Vilka konton eller organisationer som äger dem.
• Vilka versioner eller SHA:er du har fäst till.

Detta gör det enklare att svara på frågor som ”Var använder vi denna komprometterade åtgärd?” när nya rekommendationer utfärdas och för att planera bulkanpassningar.

Övervakning, revision och styrning

Säkerheten slutar inte vid konfigurationen; du behöver också insyn i vad som händer över tid.GitHub tillhandahåller granskningsloggar och säkerhetsloggar på både användar- och organisationsnivå.

Ur ett handlingsperspektiv finns det flera saker som är värda att hålla koll på:

• Händelser relaterade till hemligheter, Såsom org.update_actions_secret eller ändringar i databashemligheter. Dessa indikerar skapande, uppdatering eller borttagning av känsliga inloggningsuppgifter.
• Ändringar av arbetsflöde och regeluppsättningarvem som ändrade skyddsregler, vem som redigerade distributionsarbetsflöden, vem som ändrade miljöskydd.
• Nya eller modifierade marknadsplatsåtgärder och GitHub-appar installerade i organisationen, särskilt de som har beviljats ​​breda databas- eller organisationsomfattningar.

Du kan komplettera GitHubs egna kontroller med appar för policytillämpning som Allstar från OpenSSF., som kontinuerligt kontrollerar att arkiven följer organisationens säkerhetsbaslinje (filialskydd, aktiverad kodskanning, obligatoriska granskningar etc.).

Håll koll på mönster som kan tyda på missbruk på sidan "pågående arbetsflöden".Ovanliga toppar i jobbkörningstider, oväntad utgående trafik från löpare eller jobb som ofta misslyckas runt steg som hanterar hemligheter eller OIDC-tokens. Dessa är inte alltid skadliga, men de är bra ställen att starta undersökningar.

Att sammanföra allt detta innebär att tänka på GitHub Actions som en del av din kärnproduktionsyta., inte bara "limskript". Med noggrant avgränsade hemligheter och tokens, strikta gren- och miljöskydd, konservativ användning av tredjepartsåtgärder, härdade runners och kontinuerlig övervakning med verktyg som CodeQL, Scorecards och Dependabot, ger du din organisation en chans mot den växande klassen av CI/CD- och leveranskedjeattacker som uttryckligen riktar sig mot själva GitHub-arbetsflödena.