GITHUB_TOKENin oikeudet: vähimmät oikeudet jokaiselle työnkululle

Jokainen GitHub Actions -jobi saa tunnuksen. GitHub luo jokaisen jobin alussa uuden GITHUB_TOKEN-tunnuksen, joka on rajattu siihen repositorioon, jossa työnkulku on, ja mikä tahansa jobin vaihe voi käyttää sitä. Se, mitä tunnus voi tehdä, riippuu asetuksista, joita monet tiimit eivät ole koskaan katsoneet, ja vanhemmissa repositorioissa vastaus on yhä "kirjoittaa lähes kaikkeen".

Tällä on merkitystä, kun jokin jobissa muuttuu haitalliseksi. Elokuun 2025 Nx:n "s1ngularity"-murrossa repositorion tunnuksella oli yhä luku- ja kirjoitusoikeudet. Injektio pull_request_target-työnkulussa käytti sitä julkaisutyönkulun käynnistämiseen, mikä vuoti npm-tunnuksen, jolla julkaistiin Nx:n haitallisia versioita. Vain lukuoikeuksin varustettu tunnus olisi pysäyttänyt tämän vaiheen.

Tämä kirjoitus käy läpi, miten tunnuksen oikeudet asetetaan, mitä kukin yleinen tehtävä tarvitsee ja miten löydät työnkuluillesi minimin.

Mikä GITHUB_TOKEN on

GITHUB_TOKEN on GitHub Actions -sovelluksen asennuskohtainen käyttötunnus (installation access token). Muutama ominaisuus jää helposti huomaamatta:

Se on olemassa, käytitpä sitä tai et. Työnkulut viittaavat siihen muodossa secrets.GITHUB_TOKEN, mutta mikä tahansa action voi lukea sen github.token-kontekstin kautta, vaikka sitä ei annettaisi sille.
Se kirjoitetaan oletuksena levylle. actions/checkout tallentaa tunnuksen myöhempiä git-komentoja varten, ellet aseta persist-credentials: false. Ennen v6:ta se meni tiedostoon .git/config; v6 siirsi sen erilliseen tiedostoon hakemistoon $RUNNER_TEMP. Vuonna 2024 Unit 42:n ArtiPACKED-tutkimus löysi tunnuksia, jotka vuotivat artefakteista, joihin .git/config oli sisällytetty.
Se vanhenee jobin mukana. GitHubin ylläpitämillä runnereilla se tarkoittaa enintään 6 tuntia, jobin aikarajaa. Itse ylläpidetyillä runnereilla sitä voidaan uusia jopa 24 tunnin ajan.

Koska tunnus on aina olemassa, ainoa asia, jota hallitset, on se, kuinka paljon se voi tehdä.

Oletus: permissive tai restricted

Jokaisella enterprisellä, organisaatiolla ja repositoriolla on tunnukselle oletusasetus:

Permissive: luku ja kirjoitus jokaisessa oikeudessa.
Restricted: vain luku contents- ja packages-oikeuksissa, ei mitään muuta.

2.2.2023 alkaen uudet enterpriset, organisaatiot ja repositoriot ovat oletuksena restricted-tilassa. Muutos ei koskenut olemassa olevia, joten jokainen ennen tätä luotu repositorio tai organisaatio säilyttää permissive-oletuksen, ellei joku ole muuttanut sitä. Jos ylempi taso valitsee restricted-tilan, sen alapuolella olevat tasot eivät voi valita permissive-tilaa.

Tarkista asetus kohdasta Settings → Actions → General → Workflow permissions, ensin organisaation tasolla. Samassa osiossa on Allow GitHub Actions to create and approve pull requests, jonka pitäisi olla pois päältä, ellei jokin työnkulku tarvitse sitä.

Permissions-avain

Työnkulun permissions-avain säätää tunnusta oletuksesta. Se toimii kahdella tasolla:

permissions:
  contents: read

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

Säännöt:

Jobitaso ohittaa työnkulkutason. Aseta työnkulun oletukseksi vain luku ja nosta oikeuksia vain niissä jobeissa, jotka tarvitsevat niitä.
Kaikesta, mitä et listaa, tulee none. Heti kun asetat yhden oikeuden, kaikki muut poistetaan. permissions: {} poistaa ne kaikki.
Arvot ovat read, write tai none. write sisältää read-oikeuden. read-all ja write-all asettavat kaiken kerralla; vältä write-all-arvoa.

Käytettävissä olevat oikeudet syyskuussa 2026:

Oikeus	Hallitsee
`actions`	Työnkulkujen ajot, artefaktit ja välimuistit
`artifact-metadata`	Artefaktien metatietokirjaukset (korvasi `contents`-oikeuden näille API:ille 2026)
`attestations`	Artefaktien attestaatiot
`checks`	Check runit ja check suitet
`code-quality`	Koodin laatutulokset, kuten kattavuusraportit
`contents`	Repositorion sisältö, commitit, haarat, tagit ja julkaisut
`deployments`	Deploymentit
`discussions`	Keskustelut (Discussions)
`id-token`	OIDC-tunnuksen pyytäminen (vain `write` tai `none`)
`issues`	Issuet ja kommentit
`packages`	GitHub Packages, konttirekisteri mukaan lukien
`pages`	GitHub Pages -buildit
`pull-requests`	Pull requestit, labelit ja katselmoinnit
`security-events`	Code scanning -hälytykset ja SARIF-lataukset
`statuses`	Commitien tilat
`vulnerability-alerts`	Dependabot-hälytykset (vain `read` tai `none`)

Kun jobilta puuttuu tarvittava oikeus, API-kutsu epäonnistuu virheellä 403 Resource not accessible by integration. Virhe on merkki lisätä se yksi oikeus, jota vaihe tarvitsee, eikä siirtyä write-all-arvoon.

Mitä yleiset tehtävät tarvitsevat

Tehtävä	Oikeudet
Koodin checkout	`contents: read`
Julkaisun luominen tai tagin pushaaminen	`contents: write`
Kommentointi issueen tai pull requestiin	`issues: write` (pull requestien kommentit kulkevat issues-API:n kautta)
Labelien tai katselmointien lisääminen PR:ään	`pull-requests: write`
Tunnistautuminen pilvipalveluun OIDC:llä	`id-token: write`
Artefaktien attestaatioiden luominen	`id-token: write`, `attestations: write`, `contents: read` sekä `packages: write` konttikuville
Konttikuvan pushaaminen GitHub Container Registryyn	`packages: write`
SARIFin lataaminen code scanningiin	`security-events: write`
GitHub Pagesin deploy työnkulusta	`pages: write`, `id-token: write`

Useimmat testi- ja build-jobit eivät tarvitse muuta kuin contents: read.

Forkit, pull_request_target ja Dependabot

Forkeista tulevat pull requestit saavat pull_request-tapahtumassa vain lukuoikeuksin varustetun tunnuksen riippumatta siitä, mitä työnkulku pyytää, ellei ylläpitäjä ota käyttöön asetusta "Send write tokens to workflows from pull requests". Jätä se pois päältä.
pull_request_target saa luku- ja kirjoitusoikeuksin varustetun tunnuksen myös julkisista forkeista tuleville pull requesteille. Siksi se on monen tunnetuimman tunnusvarkauden taustalla: Nx-murto, Ultralytics-murto joulukuussa 2024 ja Trivy-actionin murto maaliskuussa 2026 alkoivat kaikki pull_request_target-työnkulusta. GitHub rajoittaa sitä: heinäkuusta 2026 lähtien actions/checkout kieltäytyy oletuksena hakemasta forkin koodia näissä työnkuluissa, ja 2.11.2026 alkaen pull_request_target on oletuksena pois käytöstä julkisissa repositorioissa, joilla ei ole omaa käytäntöä.
Dependabotin pull requesteja käsitellään kuten forkeja: vain lukuoikeuksin varustettu tunnus eikä Actions-salaisuuksia. Jos punnitset muita päivitystyökaluja, katso vaihtoehdot Dependabotille.

Miten löydät vähimmät oikeudet

Sinun ei tarvitse selvittää tätä lukemalla jokaisen actionin lähdekoodia:

GitHub Security Labin actions-permissions seuraa, miten työnkulku käyttää tunnustaan, ja suosittelee vähimmät oikeudet. Se on julkisessa betassa.
OpenSSF Scorecardin Token-Permissions-tarkistus merkitsee työnkulut, jotka eivät aseta vain luku -oikeuksia ylimmällä tasolla. Se arvioi tarkistuksen korkeaksi riskiksi.
zizmor, työnkulkujen staattinen analysaattori, merkitsee liialliset tai oletusoikeudet sekä checkoutit, jotka tallentavat tunnistetiedot.
StepSecurityn Secure-Repo ja Harden-Runner suosittelevat jobikohtaisia oikeuksia actioneita koskevan tietokannan ja jobin tekemien API-kutsujen perusteella.

Käytännöllinen käyttöönotto: aseta organisaation oletukseksi restricted, lisää permissions: contents: read jokaisen työnkulun alkuun ja aja työnkulut. Ne, jotka epäonnistuvat virheellä Resource not accessible by integration, kertovat tarkalleen, mikä jobi tarvitsee minkäkin lisäoikeuden.

Mihin CRACI sopii

Vähimmät oikeudet rajoittavat sitä, mitä varastetulla tunnuksella voi tehdä. Ne eivät estä sen varastamista, ja jobin muut salaisuudet, kuten npm-tunnukset ja pilvipalvelujen tunnistetiedot, ovat yhtä lailla alttiina.

CRACI ajaa GitHub Actions -jobisi omilla runnereillaan. Vaihdat runs-on-arvoksi craci; GITHUB_TOKEN, permissions-avain ja repositoriosi asetukset toimivat kuten ennenkin, koska GitHub myöntää tunnuksen edelleen. CRACI lisää runnerille kaksi asiaa: egress-käytännön, joka päättää, mihin palvelimiin jobi saa ottaa yhteyttä, validoidaan ennen jobin alkua ja noudattaa fail closed -periaatetta, sekä tallenteen jokaisesta paketista, jonka jobi haki, ja jäljen sen verkkoyhteyksistä. Jos jobissa oleva haitallinen koodi saa tunnuksen haltuunsa, käytäntö rajoittaa sitä, minne se voi lähettää sen, ja tallenne näyttää, mitä tapahtui.

Jobin muista salaisuuksista kerrotaan kirjoituksessa GitHub Actions -salaisuudet: miten ne vuotavat ja miten ne lukitaan. Varaa demo nähdäksesi tallenteen yhdestä omasta buildistasi.