Praktisk sikkerhetsforsterkning for GitHub-handlinger

Hjem » Python » Praktisk sikkerhetsforsterkning for GitHub-handlinger

GitHub Actions har blitt den facto CI/CD-motoren for repositorier som ligger på GitHub, som driver alt fra enhetstester til produksjonsdistribusjoner og infrastrukturendringer. Denne bekvemmeligheten kommer med en alvorlig avveining: arbeidsflyter kjører ofte med brede rettigheter, håndterer kraftige tokener og hemmeligheter, og kan nå produksjonssystemer direkte. Hvis du ikke bevisst herder dem, gir du effektivt alle feilkonfigurasjoner, avhengighetsfeil eller kompromitterte kontoer en rask vei inn i pipelines og skykontoer.

Denne veiledningen går gjennom en bred og velfundert sjekkliste for å sikre GitHub Actions fra ende til annen.: hvordan håndtere hemmeligheter riktig, unngå skriptinjeksjon, låse tokens og triggere, vurdere tredjepartshandlinger, administrere løpere og dra nytte av innebygde sikkerhetsfunksjoner som kodeskanning, OIDC, Dependabot og revisjonslogger. Målet er å samle spredte beste praksiser, hardt vunnede lærdommer fra nylige hendelser og GitHubs egen herdingsveiledning i én enkelt, praktisk referanse du kan bruke i virkelige prosjekter.

Den reelle risikoprofilen til GitHub Actions

På et overordnet nivå er en GitHub Actions-arbeidsflyt bare en YAML-fil under .github/workflows som definerer én eller flere jobber, hver sammensatt av trinn. Trinn kan enten kjøre skallkommandoer eller påkalle gjenbrukbare handlinger publisert av GitHub eller fellesskapet. Arbeidsflyter utløses av hendelser som pushes, pull-forespørsler, problemaktivitet, tidsplaner eller manuelle utsendelser.

Fra et sikkerhetsperspektiv ligger disse arbeidsflytene rett oppå programvareforsyningskjeden dinDe bygger og signerer utgivelsesartefakter, sender Docker-bilder, distribuerer til skymiljøer, klargjør infrastruktur, kjører migreringer og mer. Hvis en angriper kan kontrollere koden, konfigurasjonen eller miljøet som en privilegert arbeidsflyt kjører i, kan de ofte:

• Bakdørskompilerte artefakter (binærfiler, containere, pakker) som du senere sender til kunder.
• Eksfiltrer kraftige langlivede tokens og hemmeligheter fra minne, logger, mellomlagringer eller artefakter.
• Misbruk privilegerte skyroller gitt til CI for å distribuere ekstra tjenester, endre nettverk eller få tilgang til data.
• Forgift nedstrømsprosjekter ved å kompromittere utgivelseskanaler med åpen kildekode og distribuere trojanske utgivelser.

Nylige hendelser i den virkelige verden har understreket hvor attraktiv GitHub Actions er som en angrepsflateAngripere har misbrukt sårbare arbeidsflyter til å injisere kryptominere i publiserte pakker, og den populære tj-actions/changed-files Handlingen ble kompromittert i et flertrinnsangrep som forsøkte å nå Coinbase. Den ondsinnede koden hentet ut hemmeligheter fra arbeidsflyter og skrev dem inn i byggelogger, noe som skapte en potensiell kaskade av påfølgende forsyningskjedekompromitteringer.

Hovedideen å huske på er at de fleste GitHub Actions-angrep handler om «sannsynlighet × påvirkning».Du ønsker å redusere sannsynligheten for at du tar i bruk ondsinnede eller buggy komponenter (tredjepartshandlinger, usikre løpere, risikable utløsere), og samtidig begrense eksplosjonsradiusen dramatisk hvis en enkelt komponent blir kompromittert.

Låse hemmeligheter i GitHub Actions

Hemmeligheter er vanligvis det mest attraktive målet i ethvert CI/CD-systemI GitHub-handlinger vises de som hemmeligheter for repositorier, organisasjoner eller miljøer, og som ad hoc-verdier du ved et uhell kan dumme inn i konfigurasjoner, logger, hurtigbuffere eller artefakter.

Det første man må internalisere er tilgangsmodellen: alle med skrivetilgang til et repositorium kan effektivt lese alle hemmeligheter på repositoriumnivåDe kan ganske enkelt endre en eksisterende arbeidsflyt på en ubeskyttet gren, injisere loggings- eller eksfiltreringskode og kjøre den arbeidsflyten for å skrive ut eller lekke hemmeligheter. GitHubs maskering i logger er et forsvar basert på beste innsats, ikke en ufeilbarlig garanti.

For å holde hemmeligheter overlevelige under den modellen, følg disse grunnreglene:

• Bruk prinsippet om minste privilegiumAll legitimasjon som brukes i en arbeidsflyt må bare ha de absolutt nødvendige tillatelsene. Unngå å dele generelle administratortokener som arbeidsflythemmeligheter.
• Foretrekk miljøhemmeligheter fremfor database- eller organisasjonshemmeligheter for sensitive verdierMiljøhemmeligheter er bare tilgjengelige for jobber som deklarerer det miljøet, og du kan gi dem ekstra beskyttelse, som obligatoriske anmeldere og begrensninger for grener.
• Lagre aldri hemmeligheter i klartekst i YAML-filer for arbeidsflyt eller i kode som er sjekket inn i repoet. Alt sensitivt bør gå gjennom GitHub Secrets-mekanismen eller en ekstern hemmelighetsbehandler.
• Unngå å bruke strukturerte blobs (JSON, YAML, XML) som én hemmelig verdi.Maskering er i stor grad avhengig av nøyaktig strengsamsvar; flerfeltsblober er mye vanskeligere å redigere pålitelig. Del i stedet sensitive data opp i flere dedikerte hemmelige oppføringer.
• Registrer alle avledede hemmeligheter eksplisittHvis du transformerer en hemmelighet (Base64, URL-koding, JWT-signering osv.) og resultatet noen gang kan treffe logger, må du registrere den transformerte verdien som en egen hemmelighet, slik at GitHub kan forsøke å maskere den.

Rotasjon og hygiene er like viktig som den første konfigurasjonenGjennomgå regelmessig hvilke hemmeligheter som finnes, hvem og hva som faktisk fortsatt trenger dem, og fjern eller roter alle som er foreldet. Etter enhver mistenkt eksponering (for eksempel en hemmelighet som er skrevet ut uredigert i logger, eller brukt i en kompromittert handling), slett berørte logger umiddelbart, tilbakekal påloggingsinformasjonen og opprett nye.

Unngå skriptinjeksjon og usikker interpolering

En av de vanligste, men likevel subtile, klassene av GitHub Actions-feil er skriptinjeksjon gjennom uttrykk.GitHub tilbyr omfattende «kontekster» som for eksempel github, env, secrets og hendelsesnyttelaster, som du refererer til i arbeidsflyter ved hjelp av ${{ ... }} syntaks. Disse uttrykkene evalueres av GitHub før du skalltrinnet ditt kjører.

Når du legger inn en upålitelig kontekst direkte i en skallkommando, inviterer du til kommandoinjeksjon.Hvis du for eksempel gjør:

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

og en angriper kan kontrollere problemtittelen, kan de sende inn en tittel som $(id)Etter uttrykksevaluering blir trinnet:

echo "new issue $(id) created"

som utfører id på løperenIngen mengde justeringer av sitater eller enkel validering i skallet vil pålitelig redde deg fra dette mønsteret.

Det sikre mønsteret GitHub anbefaler er å bruke en mellomliggende miljøvariabel:

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

Her forblir den potensielt fiendtlige verdien i minnet som en miljøvariabel, og skallet ser bare $TITLE, ikke en dynamisk konstruert kommandolinje. Du trenger fortsatt normal skallhygiene (sitering av variabler, unødvendig evalering osv.), men det farlige interpolasjonstrinnet fjernes.

Når du er fristet til å legge inn ${{ github.* }} eller andre brukerstyrte data direkte inn i run: blokker, stopp og skyv den gjennom env: i stedetDenne ene vanen eliminerer en hel klasse med skriptinjeksjonsproblemer på tvers av arbeidsflytene dine.

Konfigurere tillatelser og tokener på en sikker måte

Ocuco GITHUB_TOKEN som GitHub injiserer i hver arbeidsflytkjøring er utrolig kraftig hvis den beholdes med standardverdierDen kan lese og skrive innhold, åpne og oppdatere pull-forespørsler og samhandle med repoet på mange måter. Historisk sett har mange organisasjoner hatt den som standard satt til lesing og skriving uten å være klar over det.

Det første herdetrinnet bør være å sette standard arbeidsflyttokentillatelser til skrivebeskyttet. på organisasjons- og/eller datalagernivå. Det finnes en egen innstilling for dette i Handlinger-konfigurasjonen. Derfra kan du selektivt gi ekstra tillatelser per arbeidsflyt eller per jobb, for eksempel:

permissions:
contents: read
pull-requests: write

Denne «avslå som standard, tillat der det er nødvendig»-modellen reduserer dramatisk hva en angriper kan gjøre med en kompromittert arbeidsflytDet tvinger også forfattere til å tenke på hvilke evner jobben deres faktisk krever, i stedet for å arve et samletoken.

Hvis organisasjonen din ble opprettet før tidlig i 2023, bør du eksplisitt revidere disse standardinnstillingene.Mange eldre organisasjoner har fortsatt skriveaktiverte arbeidsflyttokener fordi de er eldre enn den sikrere standarden og aldri har valgt å benytte seg av endringen.

I tillegg til token-omfang, vær svært forsiktig med innstillinger som lar GitHub Actions godkjenne eller opprette pull-forespørsler.Å tillate arbeidsflyter å godkjenne PR-er åpner opp for misbruksveier der kompromitterte jobber slår sammen skadelig kode uten menneskelig gjennomgang. Med mindre du har et sterkt brukstilfelle og strenge sikkerhetsrekkverk, bør du holde denne funksjonen deaktivert.

Valg og festing av tredjepartshandlinger

Hver eksterne handling du bruker er en del ekstern kode som kjører med de samme rettighetene som resten av jobben din.Hvis handlingen blir ondsinnet, blir kompromittert eller avbrytes med sårbare avhengigheter, blir den et ferdig fotfeste i pipelinen din.

Det finnes flere forsvarslag du kan bruke når du bruker tredjepartshandlinger:

• Start med en liten, pålitelig tillatelseslisteGitHub-vedlikeholdte handlinger (som actions/checkout, actions/setup-node) og markedsplasshandlinger fra verifiserte utviklere er vanligvis et tryggere utgangspunkt enn tilfeldige repositorier. Mange organisasjoner håndhever dette via «Tillat spesifiserte handlinger og gjenbrukbare arbeidsflyter» på organisasjonsnivå.
• Favoriser populære, aktivt vedlikeholdte handlingerForskning viser at mange markedsplasshandlinger har lave OpenSSF Scorecard-poengsummer, én vedlikeholder og kortlivede eller svært unge eierkontoer. Handlinger som brukes mye, har en tendens til å bli gransket mer nøye og få raskere løsninger.
• Se etter et stort antall åpne Dependabot PR-er i handlingens repoDet er ofte et tegn på at vedlikeholderen ikke installerer sikkerhetsoppdateringer, slik at transitive sårbarheter ikke blir rettet.
• Foretrekk handlinger med mer enn én vedlikeholder og en ikke-arkivert, aktiv kodebaseHundrevis av handlinger på markedsplassen arkiveres, noe som betyr at det ikke finnes nye rettelser eller kompatibilitetsoppdateringer og økende risiko over tid.

Versjonslåsing er et annet kritisk temaHvis du spesifiserer en handling kun etter tagg, for eksempel some-org/some-action@v2, du stoler på at taggen aldri flyttes til skadelig kode. Tagger kan målrettes på nytt hvis vedlikeholderkontoen eller depotet blir kompromittert.

Den mest defensive tilnærmingen i dag er å feste til en full commit SHA:

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

Å feste til en SHA gjør koden i praksis uforanderlig fra ditt perspektiv. (bortsett fra et SHA-1-kollisjonsangrep på Git-objekter). Ulempen er operasjonell: du må oppdatere SHA-en når du vil ha nye funksjoner eller rettelser, og forskjellige arbeidsflyter kan skifte til forskjellige SHA-er hvis du ikke er forsiktig.

For å lette på dette, sentraliserer noen team bruk av tredjepartshandlinger i delte eller sammensatte arbeidsflyterIndividuelle repositorier refererer til disse delte arbeidsflytene via tagg, mens de delte arbeidsflytene fester de underliggende handlingene til godkjente SHA-er og oppdateres i en kontrollert kadens, noen ganger med verktøy som åpner PR-er for nye SHA-er.

Uansett hvilken strategi du velger, husk at pinning ikke er en magisk brannmurEn handling kan fortsatt dynamisk hente kode under kjøring (for eksempel via curl | bash mønstre) og omgå PIN-koden din. Du må fortsatt skumlese kilden for åpenbart usikre mønstre før du stoler på en handling med hemmeligheter eller skrivekompatible tokener.

Utforme tryggere arbeidsflyter og jobber

Hvordan du strukturerer arbeidsflyter og jobber påvirker sterkt eksplosjonsradiusen til et kompromissEt vanlig antimønster er en enkelt gigantisk jobb som sjekker ut kode, bygger, tester, pakker og distribuerer, alt samtidig som man har brede tillatelser og tilgang til produksjonshemmeligheter.

Å dele opp arbeidet i separate jobber og til og med separate arbeidsflyter gir både isolasjon og klarhetFor eksempel kan du ha:

• A bygge- og testjobb som kjører med minimale tillatelser og ingen distribusjonshemmeligheter.
• A pakkejobb som produserer signerte artefakter, men som fortsatt ikke kommuniserer med produksjon.
• A distribuer jobb som er avhengig av de andre og er den eneste som har tilgang til miljøhemmeligheter og påtar seg skyroller.

På GitHub-hostede løpere kjører hver jobb i en arbeidsflyt i en ny virtuell maskin, som gir deg en viss grad av isolasjon mellom jobber. Det tilsvarer ikke en herdet sandkasse, og det finnes kjente kryssjobbvektorer (som delte grenbuffere), men å dele jobber tvinger fortsatt angripere til å jobbe hardere og reduserer utilsiktet lekkasje av hemmeligheter til urelaterte trinn.

Bruk miljøer for å knytte sensitive trinn til beskyttelserEn distribusjonsjobb kan deklarere:

environment: production

og production miljøet kan deretter konfigureres til kun å godta distribusjoner fra en beskyttet gren, muligens med obligatoriske manuelle godkjenninger. Ved å kombinere dette med strenge regler for beskyttelse av grenen (påkrevde gjennomganger, ingen spoling fremover, avvisning av foreldede godkjenninger) kommer du nærmere et fireøyneprinsipp for produksjonsendringer.

Til slutt, vær forsiktig med gjenstander, cacher og loggerDe er praktiske måter å dele data mellom jobber og arbeidsflyter, men:

• Ikke legg hemmeligheter i mellombuffere, spesielt ikke kjente steder som ~/.docker/config.json som kan inneholde vanlige Docker-legitimasjon.
• Unngå å logge hemmeligheter eller dumpe hele kontekster til logger, da dette kan omgå maskering eller avsløre avledede verdier som GitHub ikke vet at skal redigere.
• Husk at alle med lesetilgang til depotet vanligvis kan laste ned artefakter og bla gjennom logger., inkludert eksterne samarbeidspartnere hvis du gir dem tilgang.

OIDC og kortvarige skylegitimasjoner

En av de mest effektive endringene du kan gjøre er å slutte å lagre langvarige skyleverandørlegitimasjoner som GitHub-hemmeligheter helt.Bruk i stedet OpenID Connect (OIDC) for å få kortlivede tokener med godt omfang bundet til en bestemt arbeidsflytidentitet.

Høynivåflyten er enkel:

• Skyleverandøren din (AWS, Azure, GCP osv.) er konfigurert til å stole på GitHubs OIDC-leverandør.
• Du definerer en identitetspolicy som sier «godta bare tokener fra denne organisasjonen/depotet/grenen eller miljøet».
• Under en jobb kan GitHub be om et OIDC-token, og arbeidsflyten din bruker en skyspesifikk handling (for eksempel aws-actions/configure-aws-credentials) for å bytte det mot en kortvarig rolle- eller tjenestekontotoken.

Tillitsbetingelsen er der du kan bli veldig detaljertFor AWS kan en typisk policy inkludere:

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

Det sikrer at bare arbeidsflyter fra et bestemt repositori og en avdeling kan overta rollen.Hvis du ønsker enda strengere omfang, kan du knytte rollen til et bestemt miljø i stedet for en gren, og deretter kreve at det miljøet bare gjelder for distribusjonsjobben. En kompromittert tredjepartshandling i en ikke-distribusjonsjobb vil oppdage at OIDC-kall rett og slett mislykkes.

Bruk av OIDC fjerner ikke behovet for rollepolicyer med minste privilegier i skyen., men det eliminerer statiske tilgangsnøkler som ligger i GitHub Secrets, hvor de kan bli stjålet og gjenbrukt på ubestemt tid utenfra GitHub.

Grenbeskyttelse, regelsett og miljøer som fungerer sammen

Mange av de skumle angrepsstiene i GitHub Actions koker ned til «angriper injiserer ondsinnede endringer i en beskyttet gren»Grenbeskyttelse og regelsett er din viktigste forsvarslinje der.

På grener som main or production, vanligvis vil du ha minst:

• Krev en pull-forespørsel før sammenslåing – forby direkte push.
• Krev minst én (ofte flere) godkjenningsanmeldelse fra noen andre enn den siste dytteren.
• Avvis foreldede godkjenninger når nye commits legges til – slik at angripere ikke kan snike inn kode etter gjennomgang.
• Krev godkjenning av den nyeste gjennomgåbare push-en – hindrer en angriper i å kapre andres PR, pushe dårlig kode og godkjenne seg selv.

Du kan deretter koble disse beskyttelsene til miljøer. For eksempel a production miljøet godtar kanskje bare distribusjoner fra main grenen, og kanskje også kreve manuell godkjenning fra et lite sett med anmeldere (med «forhindre egenvurdering» aktivert). På den måten kan ikke én kompromittert bidragsyterkonto sende vilkårlig kode til produksjon uten noen andres eksplisitte involvering.

Vær forsiktig med miljøregler som er avhengige av selve distribusjonene (for eksempel «krev at distribusjoner lykkes før tagoppdateringer tillates»). Hvis strukturen er dårlig, kan du opprette sirkulære avhengigheter eller pseudokontroller som en samarbeidspartner kan omgå ved å redigere arbeidsflyter. Det sikreste mønsteret er fortsatt: sterk grenbeskyttelse → miljøer med tett omfang → eksplisitt bruk av disse miljøene bare i de minimale jobbene som virkelig trenger dem.

Administrere løpere: GitHub-hostet vs. selvhostet

Løpere er maskinene som faktisk utfører arbeidsflytene dineGitHub-hostede løpere er flyktige virtuelle maskiner som administreres av GitHub; selvhostede løpere er maskiner eller containere du klargjør og kontrollerer.

GitHub-hostede løpere er generelt mye tryggere som standard.:

• De er flyktige og tilbakestilles for hver jobb, så det er ingen vedvarende kompromisser på tvers av kjøringer.
• GitHub publiserer SBOM-er for standardbilder (Ubuntu, Windows, macOS), slik at du kan analysere forhåndsinstallert programvare for sårbarheter.
• Enkelte ondsinnede verter blokkeres umiddelbart (for eksempel kjente kryptominingpooler) via /etc/hosts konfigurasjon.

Selvstyrte løpere er kraftige, men farlige hvis du ikke behandler dem som produksjonsservere:

• De er vanligvis ikke flyktige med mindre du bygger det selv., slik at enhver ondsinnet arbeidsflyt kan forsøke persistens, lateral bevegelse eller datatyveri.
• De har ofte bredere nettverkstilgang og lokale hemmeligheter (SSH-nøkler, skybaserte CLI-er, metadatatjenester), noe som øker risikoen for ethvert kompromiss.
• Offentlige arkiver bør nesten aldri bruke selvhostede løpere., fordi hvem som helst kan åpne en pull-forespørsel som ender opp med å kjøre kode på infrastrukturen din.

Hvis du må bruke selvhostede løpere, del dem opp etter tillitsgrenser.Bruk løpergrupper og restriksjoner slik at:

• Offentlige og private prosjekter deler aldri den samme løperpoolen.
• Høysensitive repos (for eksempel produksjonsinfrastruktur) har sine egne strengt kontrollerte løpere.
• Bare bestemte databaser eller organisasjoner kan sende jobber til en gitt gruppe.

Du kan redusere risikoen ytterligere med just-in-time (JIT)-kjørere som er klargjort via REST API-et.Disse løperne registreres dynamisk, kjører maksimalt én jobb, og fjernes deretter automatisk. Du må fortsatt sørge for at den underliggende verten renses eller ødelegges, men det begrenser vinduet der en kompromittert jobb kan påvirke påfølgende jobber.

Behandle selvhostede løpere som alle andre produksjonssystemerovervåke prosessaktivitet, låse utgående nettverksstier, holde operativsystem og verktøy oppdatert, og anta at enhver bruker med tillatelse til å utløse arbeidsflyter effektivt kjører kode på den maskinen.

Innebygde sikkerhetsfunksjoner: kodeskanning, scorekort og Dependabot

GitHub leverer en rekke førsteklasses funksjoner som er spesielt rettet mot å avdekke arbeidsflyt- og avhengighetsrisiko, og de er verdt den lille oppstartskostnaden.

Kodeskanning (for eksempel med CodeQL) kan nå analysere GitHub Actions-arbeidsflyter selv, ikke bare applikasjonskilden din. Regler som «Overdreven eksponering av hemmeligheter» kan oppdage mønstre der GitHub ikke kan bestemme hvilke hemmeligheter som kreves (for eksempel dynamisk secrets[myKey] bruk i matrisebygg), noe som fører til at den laster inn flere hemmeligheter enn nødvendig i jobbminnet.

OpenSSF-poengsumkort og poengsumkort-handlingen legger til et nytt lag ved å gradere sikkerhetstilstanden til avhengighetene dine.For handlinger i markedet kan scorekort flagge utrygge praksiser i forsyningskjeden, som for eksempel:

• Ikke feste avhengigheter.
• Manglende grenbeskyttelse eller krav til kodegjennomgang.
• Mangel på sikkerhetspolicy eller prosesser for respons på sårbarheter.

Dependabot spiller to roller her:

• Dependabot-varsler advare deg når en avhengighet av handlingene eller arbeidsflytene dine har en kjent sårbarhet, basert på GitHub Advisory Database.
• Dependabot-versjon og sikkerhetsoppdateringer kan automatisk åpne PR-er for å bumpe action-versjoner og oppdatere sårbare utgivelser.

Avhengighetsgrafen for arbeidsflyter er en annen undervurdert funksjonGitHub behandler arbeidsflytfilene dine som manifester og kan vise deg:

• Hvilke handlinger og gjenbrukbare arbeidsflyter du er avhengig av.
• Hvilke kontoer eller organisasjoner eier dem.
• Hvilke versjoner eller SHA-er du har festet til.

Dette gjør det enklere å svare på spørsmål som «Hvor bruker vi denne kompromitterte handlingen?» når nye råd kommer, og for å planlegge masseutbedringer.

Overvåking, revisjon og styring

Sikkerhet stopper ikke ved konfigurasjon; du trenger også innsikt i hva som skjer over tid.GitHub tilbyr revisjonslogger og sikkerhetslogger på både bruker- og organisasjonsnivå.

Fra et handlingsperspektiv er det flere ting som er verdt å følge med på:

• Hendelser relatert til hemmeligheter, Eksempel org.update_actions_secret eller endringer i hemmelige arkiver. Disse indikerer opprettelse, oppdatering eller sletting av sensitive legitimasjonsopplysninger.
• Endringer i arbeidsflyt og regelsetthvem endret beskyttelsesregler, hvem redigerte distribusjonsarbeidsflyter, hvem endret miljøbeskyttelse.
• Nye eller endrede markedsplasshandlinger og GitHub-apper installert i organisasjonen, spesielt de som har fått brede omfang for repositorier eller organisasjoner.

Du kan supplere GitHubs egne kontroller med apper for håndheving av retningslinjer, som Allstar fra OpenSSF., som kontinuerlig sjekker at databaser overholder organisasjonens sikkerhetsgrunnlinje (grenbeskyttelse, kodeskanning aktivert, nødvendige gjennomganger osv.).

På siden om «kjørende arbeidsflyter», følg med på mønstre som kan tyde på misbruk: uvanlige topper i jobbkjøretider, uventet utgående trafikk fra løpere, eller jobber som ofte mislykkes rundt trinn som håndterer hemmeligheter eller OIDC-tokener. Dette er ikke alltid skadelige, men de er gode steder å starte undersøkelser.

Å sette alt dette sammen betyr å tenke på GitHub-handlinger som en del av kjerneproduksjonsflaten din., ikke bare «limskript». Med nøye utvalgte hemmeligheter og tokens, streng beskyttelse av grener og miljøer, konservativ bruk av tredjepartshandlinger, herdede løpere og kontinuerlig overvåking med verktøy som CodeQL, Scorecards og Dependabot, gir du organisasjonen din en sjanse mot den voksende klassen av CI/CD- og forsyningskjedeangrep som eksplisitt retter seg mot GitHub-arbeidsflyter.