GitHub Actions-hemmeligheter: loggmaskering er ingen garanti

For å beskytte hemmeligheter i GitHub Actions må du styre hvilke jobber og steg som får bruke dem, begrense rettighetene deres og kontrollere koden som kjører med dem. GitHubs dokumentasjon om hemmeligheter beskriver automatisk maskering i kjørelogger, men sier at maskeringen ikke er garantert når en verdi blir endret.

Prioriter derfor å fjerne varige nøkler der det er mulig. Legg produksjonstilgang bak miljøgodkjenning, gi hver jobb minst mulig myndighet, vurder tredjepartshandlinger og begrens hva kjøreren kan sende ut. En lagret hemmelighet er kryptert før bruk, men koden som får verdien under kjøringen, kan også skrive eller sende den videre.

Bruk kortlivede legitimasjoner og snevre rettigheter

Start med å undersøke om jobben trenger en lagret nøkkel i det hele tatt. Når den bare skal arbeide i sitt eget kodearkiv, kan den bruke jobbens GITHUB_TOKEN. Angi tillatelsene uttrykkelig på arbeidsflyt- eller jobbnivå: en byggejobb trenger normalt lesetilgang, mens skriveadgang bør ligge hos jobben som faktisk publiserer. GITHUB_TOKEN er tilgjengelig for handlinger gjennom jobbens kontekst selv om du ikke sender det som en egen inndataverdi.

For en skytjeneste som støtter OpenID Connect (OIDC), kan arbeidsflyten få et kortlivet tilgangstoken i stedet for å lagre en varig skynøkkel. Tillitsregelen hos skyleverandøren må samtidig avgrenses til riktig kodearkiv og relevant gren eller miljø. Ved AWS-distribusjon er en for bred tillitsregel nettopp en måte å gi flere arbeidsflyter tilgang enn planlagt.

Trenger jobben GitHub-tilgang utover det GITHUB_TOKEN gir, kan et kortlivet installasjonstoken fra en GitHub App erstatte et langlivet personlig tilgangstoken. Hvis en statisk nøkkel fortsatt er nødvendig, gi den en egen identitet med snevre rettigheter og en plan for rotasjon. Kort levetid reduserer tiden et stjålet token kan brukes; den reduserer ikke hvilke ressurser tokenet kan nå mens det er gyldig.

Gi produksjonshemmeligheter til riktig miljø

Velg lagringsnivå etter hvem som trenger verdien. En organisasjonshemmelighet kan deles mellom utvalgte kodearkiver, en hemmelighet på kodearkivnivå kan brukes av arbeidsflyter der, og en miljøhemmelighet kan knyttes til en bestemt distribusjon. Legg produksjonsverdier i produksjonsmiljøet når bygging og testing ikke trenger dem. Konfigurer påkrevde godkjennere og begrens hvilke grener som kan distribuere til miljøet.

Skill testing av pull requests fra distribusjon i egne jobber. Testjobben kan da kjøre uten produksjonshemmeligheter, mens distribusjonsjobben må velge miljøet og vente på godkjenning før den får tilgang til miljøets verdier. Godkjenningen avgjør når tilgangen åpnes; den gjør ikke koden som kjører etterpå trygg. Gå derfor gjennom arbeidsflytfilen og handlingene som får bruke verdiene.

Send hemmeligheter til de stegene som faktisk trenger dem, fremfor å legge dem i miljøet for hele jobben. Ved gjenbrukbare arbeidsflyter bør nødvendige verdier sendes uttrykkelig. Valget secrets: inherit kan ellers gi den kalte arbeidsflyten flere hemmeligheter enn oppgaven krever. Kontroller også hvilket miljø den gjenbrukbare arbeidsflyten selv velger, siden miljøets egne hemmeligheter kan bli brukt der.

Kontroller koden som får tilgang

En tredjepartshandling i en privilegert jobb er kode som kan bruke jobbens tilgjengelige legitimasjoner. Undersøk hvem som vedlikeholder handlingen, hvilke tillatelser den trenger, og om den sender inndata eller hemmeligheter til eksterne verter. GitHubs råd om sikker bruk anbefaler en låsefil for arbeidsflytavhengigheter der den kan brukes, og ellers feste handlinger til en fullstendig commit-hash som er kontrollert mot riktig kodearkiv.

En flyttbar versjonstagg kan peke på annet innhold ved en senere kjøring. En låsefil eller fast commit gjør det tydeligere hvilken kode som faktisk kjøres, men innholdet må fremdeles vurderes når avhengigheten velges og oppdateres. De samme prinsippene gjelder gjenbrukbare arbeidsflyter fra andre kodearkiver.

Hold upålitelige verdier fra pull requests unna skallkommandoer. Titler og kommentarer kan inneholde tegn som får en kommando bygget direkte fra en GitHub-kontekst til å gjøre noe annet enn tiltenkt. Send slike verdier gjennom en mellomliggende miljøvariabel eller som inndata til en handling som behandler dem som data. Vær særlig forsiktig med privilegerte utløsere som pull_request_target eller workflow_run når jobben også henter inn kode fra en upålitelig pull request.

Avgrens kjøreren og nettverket

En selvdriftet kjører kan ha tilgang til interne tjenester eller filer fra tidligere jobber. OWASPs sjekkliste for GitHub Actions fraråder generelt selvdriftede kjørere for offentlige kodearkiver og anbefaler flyktige kjørere, atskilte kjørergrupper og kontroll med utgående trafikk.

Bruk kjørergrupper til å skille jobber med produksjonstilgang fra tester og analyser med lavere rettigheter. En jobb uten hemmeligheter bør heller ikke havne på en maskin som allerede har nettverkstilgang til følsom infrastruktur. En flyktig kjører må få et rent miljø for hver jobb; å avregistrere kjøreren alene fjerner ikke nødvendigvis data fra maskinvaren den brukte.

Kartlegg hvilke eksterne tjenester bygging og distribusjon faktisk må nå, og begrens andre utgående forbindelser der infrastrukturen tillater det. Det gjør det vanskeligere for skadelig kode å sende legitimasjoner til et uvedkommende endepunkt. Nettverkskontroll dekker også en lekkasjekanal som loggmaskering ikke påvirker: en hemmelighet kan sendes ut uten noen gang å bli skrevet i kjøreloggen.

Behandle logger og artefakter som mulige lekkasjekanaler

Unngå å skrive hemmeligheter, komplette miljøvariabler eller kommandolinjer med legitimasjoner til standardutdata og feilutdata. Bruk en miljøvariabel eller standardinndata når verktøyet støtter det, og gjør verdien tilgjengelig bare i steget som trenger den. Feilmeldinger kan inneholde andre data enn normal kjøreutskrift, så gjennomgå logger fra både vellykkede og mislykkede kjøringer.

Maskeringen er særlig sårbar når en verdi blir kodet om, satt sammen på nytt eller brukt til å lage et nytt token. Registrer nye følsomme verdier for maskering før de kan nå loggen, men behandle dette som en ekstra barriere. Unngå også å lagre flere legitimasjoner som én strukturert JSON- eller YAML-verdi: maskeringen bygger i stor grad på treff mot den registrerte verdien. Artefakter som lastes opp fra jobben, må vurderes separat; loggmaskering fjerner ikke hemmeligheter fra en publisert fil.

Blir en legitimasjon synlig, tilbakekall eller roter den og slett den eksponerte loggen. Undersøk deretter hvilke rettigheter den hadde, hvilken kode som fikk bruke den, og om verdien også kan ha havnet i artefakter eller hos en ekstern tjeneste. Den gjennomgangen avgjør hvilken tilgangsgrense som må strammes inn før jobben kjøres igjen.

Les også:

• GitHub Actions uten AWS-nøkler: en for bred trust policy åpner kontoen
• GitHub Copilot eller Cursor: billigst abonnement vinner ikke agentjobben
• Claude Code eller GitHub Copilot: høyere fletterate avgjør ikke alene