Dependabot läser privata GitHub Packages utan PAT – kontrollera behörigheten

Nyheten: repositoryts grant ersätter användarens PAT

GitHub meddelade den 8 september 2026 att automatisk åtkomst från Dependabot till GitHub-värdade register hade återaktiverats. Enligt GitHubs changelog kan Dependabots GITHUB_TOKEN begära packages: read. Jobbet skickar token när det hämtar från *.pkg.github.com och ghcr.io.

Kontrollpunkten ligger på paketet: under Manage Actions access ska paketet ge det repository som kör Dependabot behörigheten Read. Dependabot återanvänder då samma grant som ett vanligt Actions-workflow. GitHub avgränsar stödet till de GitHub Packages-ekosystem som Dependabot stöder; beskedet är alltså inte en generell ersättning för autentisering mot valfritt privat register.

Varför du ska prova routing före städning

Funktionen släpptes först den 23 juni 2026 men rullades tillfälligt tillbaka. GitHub hade identifierat en konflikt där vissa npm-uppdateringsjobb löste publika paket genom GitHub Packages. I den återaktiverade lösningen används den automatiska GitHub Packages-autentiseringen endast som fallback. Uttryckliga registeruppgifter och normal register-routing fortsätter att ha företräde.

Det är en viktig skillnad mellan att få ett grönt Dependabot-jobb och att bevisa att jobbet använde rätt källa. Ett paket med samma namn kan finnas i flera register, en gammal lockfil kan dölja en felaktig väg och ett redan öppet pull request-resultat kan vara skapat före behörighetsändringen. Provet behöver därför innehålla både ett paket som ska komma från GitHub Packages och en kontroll som ska fortsätta följa din befintliga routing.

Steg 1: bygg ett litet testrepository

Utgå från ett repository där du kan återställa allt efter provet. Kopiera bara de delar som behövs för en reproducerbar hämtning: paketmanifest, relevant lockfil, det berörda avsnittet i .github/dependabot.yml och en privat dependency med en känd nyare version. Behåll den uttryckliga register-routing som används i produktion. Då mäter du autentiseringsändringen i stället för att samtidigt ändra källvalet.

Skriv ned fyra förväntningar innan du startar: paketnamn, installerad version, målversion och förväntad registervärd. Lägg till ett negativt kontrollpaket som inte ska hämtas från GitHub Packages. För npm kan det vara ett publikt paket vars källa framgår av lockfilen; för ett annat ekosystem väljer du motsvarande bevis i dess lås- eller metadatafil. Kontrollens poäng är inte ett visst filformat utan att en oväntad registerväxling ska bli synlig.

Steg 2: ge exakt repository Read-åtkomst

1. Öppna inställningssidan för det privata paket som testet behöver läsa.
2. Under Manage Actions access, lägg till testrepositoryt med Read.
3. Kontrollera att repositorynamnet och ägaren är de avsedda; ett likadant namn i en annan organisation är en annan behörighetsyta.
4. Lämna produktionsrepositoryts grant och gamla PAT-post orörda under första körningen.

GitHub säger att dependabot.yml inte behöver ändras för den automatiska åtkomsten. Just därför bör testets första diff bara vara paketets Read-grant. Om du samtidigt tar bort registry-konfiguration eller byter URL går det inte längre att avgöra vilken ändring som gjorde jobbet grönt eller rött.

Steg 3: kräv tre bevis från samma körning

Starta en ny Dependabot-uppdatering efter att grantet är sparat. Godkänn inte provet enbart för att körningen avslutas utan fel. Spara körningens tidpunkt och länk, den resulterande diffen och den uppdaterade låsfilen eller motsvarande metadata. De ska tillsammans visa tre saker:

Om ekosystemets lockfil inte sparar en läsbar URL får du välja ett annat verifierbart bevis, exempelvis package manager-logg från testkörningen eller ett checksummavärde som du på förhand kopplat till rätt artefakt. Skriv i protokollet vilket bevis du använder. “Jobbet blev grönt” är annars svårt att granska i efterhand.

Steg 4: ta bort PAT-posten som en egen ändring

När första körningen är godkänd tar du bort endast den PAT-baserade registerpost som användes för de provade GitHub Packages-paketen. Sök först efter fler konsumenter av hemligheten så att du inte blandar ihop Dependabots behov med ett workflow, publiceringsjobb eller lokalt installationsrecept. I Bash kan du börja så här:

rg -n "registries:|token:|DEPENDABOT|PACKAGE" \
  .github package.json package-lock.json 2>/dev/null

Byt söktermer efter hemlighetens faktiska namn och ekosystem. Radera inte själva repository- eller organisationshemligheten förrän referenssökningen är tom för avsedda konsumenter. Kör sedan exakt samma Dependabot-prov igen. Samma tre bevis ska hålla efter borttagningen; annars återställer du PAT-posten och utreder vilken autentiseringsväg som faktiskt användes.

Den ordningen ligger nära principen i Monkeybases säkerhetsguide: minska hemligheter, men gör förändringen spårbar och avgränsad. Om uppdateringen introducerar ett nytt paket eller en oväntad transitiv dependency hör den bedömningen hemma i fyrkontrollen för beroenden som AI föreslår. Den här nyheten avgör bara åtkomst och registerväg.

Felsök ett rött prov utan att bredda behörigheten

Ett behörighetsfel ska först leda tillbaka till paketets inställning: finns rätt testrepository där och är nivån Read? Ett fel på bara ett paket talar för att just det paketets grant eller namn behöver kontrolleras. Ett routingfel ska i stället jämföras med den uttryckliga registry-konfigurationen och den negativa kontrollen. Lägg inte till Write-behörighet för att “se om det hjälper”; hämtningen som provas behöver Read och ett bredare grant gör inte rotorsaken tydligare.

Om testet passerar med PAT men faller utan den sparar du båda körningarnas underlag. Då har du ett konkret före/efter-fall: samma repository, manifest, paketversion och routing men olika autentisering. Återställ PAT-posten tills repository-grantet är rättat. Resultatet är mer användbart än att ändra flera inställningar på måfå och tappa bort vilken kombination som fungerade.

Ge kodagenten ett mätbart uppdrag

Ett avgränsat uppdrag kan lyda: “Inventera PAT-referenserna för Dependabots GitHub Packages-register utan att ändra filer. Föreslå ett test med ett privat målpaket och ett kontrollpaket, och ange vilket lockfilsfält eller loggbevis som visar registervärden. Ändra inte paketgrant, hemligheter eller dependabot.yml.”

Godkänn agentens svar först när det namnger de två paketen, de två förväntade registervägarna, det konkreta beviset och återställningen om körningen faller. Efter en mänskligt utförd grant och två lyckade körningar – före och efter PAT-borttagningen – har du ett reproducerbart beslut i stället för ett antagande om att den nya fallbacken används.