GITHUB_TOKEN-rettigheder: Least privilege for hvert workflow

Hvert GitHub Actions-job får et token. GitHub opretter et nyt GITHUB_TOKEN ved starten af hvert job, afgrænset til det repository, workflowet ligger i, og alle trin i jobbet kan bruge det. Hvad det kan, afhænger af indstillinger, mange teams aldrig har set på, og på ældre repositories er svaret stadig "skrive til næsten alt".

Det betyder noget, når noget i jobbet bliver ondsindet. Ved Nx "s1ngularity"-kompromitteringen i august 2025 havde repositoriets token stadig læse- og skriverettigheder. En injection i et pull_request_target-workflow brugte det til at udløse publish-workflowet, som lækkede det npm-token, der blev brugt til at udgive ondsindede versioner af Nx. Et skrivebeskyttet token ville have stoppet det trin.

Dette indlæg gennemgår, hvordan tokenets rettigheder sættes, hvad hver almindelig opgave har brug for, og hvordan du finder minimum for dine workflows.

Hvad GITHUB_TOKEN er

GITHUB_TOKEN er et installation access token for GitHub Actions-appen. Et par egenskaber er lette at overse:

Det findes, uanset om du bruger det eller ej. Workflows refererer til det som secrets.GITHUB_TOKEN, men enhver action kan læse det via github.token-konteksten uden at få det givet.
Det skrives som standard til disk. actions/checkout gemmer tokenet til senere git-kommandoer, medmindre du sætter persist-credentials: false. Før v6 kom det i .git/config, og v6 flyttede det til en separat fil under $RUNNER_TEMP. I 2024 fandt Unit 42's ArtiPACKED-research tokens, der lækkede gennem artefakter, som indeholdt .git/config.
Det udløber med jobbet. På GitHub-hostede runnere betyder det højst 6 timer, jobbets tidsgrænse. På selvhostede runnere kan det fornyes i op til 24 timer.

Fordi tokenet altid er der, er det eneste, du styrer, hvor meget det kan.

Standarden: permissive eller restricted

Hver enterprise, organisation og hvert repository har en standard for tokenet:

Permissive: læse- og skriveadgang på alle rettigheder.
Restricted: skrivebeskyttet på contents og packages, intet andet.

Siden 2. februar 2023 har nye enterprises, organisationer og repositories haft restricted som standard. Ændringen rørte ikke eksisterende, så ethvert repository eller enhver organisation, der er oprettet før da, beholder den permissive standard, medmindre nogen har ændret den. Hvis et højere niveau vælger restricted, kan niveauerne under det ikke vælge permissive.

Tjek det under Settings → Actions → General → Workflow permissions, først på organisationsniveau. Samme afsnit indeholder Allow GitHub Actions to create and approve pull requests, som bør forblive slået fra, medmindre et workflow har brug for det.

Permissions-nøglen

permissions-nøglen i et workflow justerer tokenet i forhold til standarden. Den virker på to niveauer:

permissions:
  contents: read

jobs:
  release:
    permissions:
      contents: write
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@<full-commit-sha>

Reglerne:

Jobniveau tilsidesætter workflow-niveau. Sæt workflow-standarden til skrivebeskyttet, og hæv kun rettighederne i de jobs, der har brug for dem.
Alt, hvad du ikke angiver, bliver none. Så snart du sætter én rettighed, fjernes alle andre. permissions: {} fjerner dem alle.
Værdierne er read, write eller none. write omfatter read. read-all og write-all sætter alt på én gang. Undgå write-all.

De tilgængelige rettigheder pr. september 2026:

Rettighed	Styrer
`actions`	Workflow-kørsler, artefakter og caches
`artifact-metadata`	Metadataposter for artefakter (erstattede `contents` for disse API'er i 2026)
`attestations`	Artefakt-attestationer
`checks`	Check runs og check suites
`code-quality`	Resultater for kodekvalitet, for eksempel dækningsrapporter
`contents`	Repository-indhold, commits, branches, tags og releases
`deployments`	Deployments
`discussions`	Discussions
`id-token`	Anmodning om et OIDC-token (kun `write` eller `none`)
`issues`	Issues og kommentarer
`packages`	GitHub Packages, inklusive container-registret
`pages`	GitHub Pages-builds
`pull-requests`	Pull requests, labels og reviews
`security-events`	Code scanning-alarmer og SARIF-uploads
`statuses`	Commit-statusser
`vulnerability-alerts`	Dependabot-alarmer (kun `read` eller `none`)

Når et job mangler en rettighed, det har brug for, fejler API-kaldet med 403 Resource not accessible by integration. Den fejl er signalet til at tilføje den ene rettighed, trinnet har brug for, ikke til at skifte til write-all.

Hvad almindelige opgaver har brug for

Opgave	Rettigheder
Checke kode ud	`contents: read`
Oprette en release eller pushe et tag	`contents: write`
Kommentere på et issue eller en pull request	`issues: write` (kommentarer på pull requests går gennem issues-API'et)
Tilføje labels eller reviews til en pull request	`pull-requests: write`
Autentificere hos en cloud-udbyder med OIDC	`id-token: write`
Oprette artefakt-attestationer	`id-token: write`, `attestations: write`, `contents: read`, plus `packages: write` for container-images
Pushe et image til GitHub Container Registry	`packages: write`
Uploade SARIF til code scanning	`security-events: write`
Deploye GitHub Pages fra et workflow	`pages: write`, `id-token: write`

De fleste test- og build-jobs har ikke brug for mere end contents: read.

Forks, pull_request_target og Dependabot

Pull requests fra forks får et skrivebeskyttet token på pull_request-eventet, uanset hvad workflowet beder om, medmindre en administrator slår "Send write tokens to workflows from pull requests" til. Lad den være slået fra.
pull_request_target får et token med læse- og skriveadgang, selv for pull requests fra offentlige forks. Derfor står det bag mange af de bedst kendte tokentyverier: Nx-kompromitteringen, Ultralytics-kompromitteringen i december 2024 og kompromitteringen af Trivy-actionen i marts 2026 startede alle med et pull_request_target-workflow. GitHub strammer det: Siden juli 2026 nægter actions/checkout som standard at checke fork-kode ud i disse workflows, og fra den 2. november 2026 får offentlige repositories uden egen policy pull_request_target slået fra som standard.
Dependabot-pull requests behandles som forks: et skrivebeskyttet token og ingen Actions-secrets. Hvis du overvejer andre opdateringsværktøjer, så se alternativer til Dependabot.

Sådan finder du minimumsrettighederne

Du behøver ikke finde frem til det ved at læse hver actions kildekode:

GitHub Security Labs actions-permissions overvåger, hvordan et workflow bruger sit token, og anbefaler minimumsrettighederne. Det er i offentlig beta.
OpenSSF Scorecards Token-Permissions-tjek markerer workflows, der ikke sætter skrivebeskyttede rettigheder på øverste niveau. Det vurderer tjekket som høj risiko.
zizmor, en statisk analysator til workflows, markerer overdrevne rettigheder eller standardrettigheder og checkouts, der gemmer legitimationsoplysninger.
StepSecuritys Secure-Repo og Harden-Runner anbefaler rettigheder på jobniveau ud fra en vidensbase om actions og ud fra de API-kald, et job foretager.

En praktisk udrulning: Sæt organisationens standard til restricted, tilføj permissions: contents: read øverst i hvert workflow, og kør workflowene. Dem, der fejler med Resource not accessible by integration, fortæller dig præcis, hvilket job der har brug for hvilken ekstra rettighed.

Her passer CRACI ind

Least privilege begrænser, hvad et stjålet token kan. Det forhindrer ikke, at det bliver stjålet, og de andre secrets i jobbet, for eksempel npm-tokens og cloud-legitimationsoplysninger, er lige så eksponerede.

CRACI kører dine GitHub Actions-jobs på sine egne runnere. Du ændrer runs-on til craci; GITHUB_TOKEN, permissions-nøglen og dine repository-indstillinger virker som før, fordi GitHub stadig udsteder tokenet. Det, CRACI tilføjer, sker på runneren: en egress-politik, der afgør, hvilke hosts et job må nå, og som valideres, før jobbet starter, og blokerer ved fejl, samt en registrering af hver pakke, jobbet hentede, med et trace af dets netværksforbindelser. Hvis ondsindet kode i et job får fat i et token, begrænser politikken, hvor den kan sende det hen, og registreringen viser, hvad der skete.

For resten af jobbets secrets, se GitHub Actions-secrets: sådan lækker de, og sådan låser du dem ned. Book en demo for at se registreringen af et af dine egne builds.