Kortversion: När en token, SSH-nyckel eller appintegration misstänks vara komprometterad är den första svåra frågan sällan ”hur återkallar vi den?”. Den är ”vad har den åtkomst till, vem äger den och var används den?”. GitHubs nya credential inventory-export för Enterprise Cloud pekar på en praktisk lärdom för alla team: behandla åtkomstuppgifter som en förteckning över verksamhetskritiska kopplingar, inte som osynliga tekniska detaljer.
De flesta team vet var deras källkod finns. Färre kan på kort tid svara på vilka identiteter som kan läsa den, ändra den, starta en deploy eller agera för en app. I en vardag med CI, SaaS-integrationer, deployrobotar, GitHub Apps och AI-assisterade verktyg blir den skillnaden dyr när något händer.
Den 21 september 2026 gjorde GitHub en komplett credential inventory-export tillgänglig för GitHub Enterprise Cloud. Exporten kan omfatta bland annat SSH-nycklar, klassiska och finfördelade personliga access tokens, OAuth-app-token och GitHub App-token. Den visar ägare, behörigheter, skapande- och utgångsdatum, senaste användning och vilka organisationer eller repositories uppgiften är kopplad till. Funktionen är enterprise-specifik, men informationsmodellen är användbar långt utanför GitHub Enterprise.
Hemligheten är inte det enda ni behöver känna till
Ett värde i en secret manager eller en CI-variabel säger inte i sig vad en åtkomstuppgift betyder. En användbar inventering har åtminstone svar på sex frågor:
- Typ: Är det en personlig token, en SSH-nyckel, en deploynyckel, en OAuth-app eller en maskinidentitet?
- Ägare: Vilken person, vilket team eller vilken tjänst ansvarar för den?
- Syfte: Vilket exakt arbetsflöde behöver den – bygga, läsa paket, deploya eller administrera?
- Räckvidd: Vilka system, organisationer, repositories, zoner eller miljöer kan den nå?
- Livslängd: När skapades den, när upphör den och när användes den senast?
- Åtgärd: Vem kan återkalla eller ersätta den utan att stoppa ett kritiskt flöde?
Det är den skillnaden som gör en lista operativ. ”Vi har tolv GitHub-tokens” hjälper inte mycket. ”Den här tokenen ägs av plattformsteamet, används av releaseflödet för paket A, kan skriva till repository B och ska roteras före november” är ett underlag för ett beslut.
En incident blir kortare när inventeringen redan finns
När en nyckel exponeras eller ett konto misstänks ha tagits över behöver teamet agera parallellt: begränsa åtkomst, förstå omfattningen, kontakta berörda personer och få igång nödvändiga flöden igen. Utan inventering blandas dessa aktiviteter ihop i panik.
En färdig förteckning gör att ni kan sortera efter risk:
- Åtkomstuppgifter med bred skriv- eller administrationsrätt.
- Uppgifter som kan initiera deploy eller publicera artefakter.
- Personliga uppgifter där ägaren inte längre arbetar aktivt i teamet.
- Uppgifter som saknar utgångsdatum eller inte använts på länge.
- Integrationer som är svåra att återskapa därför att syfte och ägare är oklara.
Det betyder inte att alla gamla tokens automatiskt ska tas bort. ”Senast använd” är en signal, inte ett säkert bevis på att en identitet är överflödig. Ett sällan kört årsjobb kan fortfarande vara viktigt. Men en lista med ägare och syfte gör det möjligt att fråga rätt person innan en nyckel återkallas.
GitHubs funktion är ett verktyg – inte en komplett säkerhetsstrategi
GitHubs nya export kan ge Enterprise Cloud-organisationer en konkret startpunkt. Enligt dokumentationen är inventeringen skrivskyddad och kopplar credential-data till bland annat ägare, status, skapande, senaste användning och utgångsdatum. Den visar inte tokenvärden, vilket är rätt: en inventering ska hjälpa er att styra och utreda åtkomst, inte sprida fler hemligheter.
Men funktionen täcker GitHub-åtkomst i GitHub Enterprise Cloud. Den ersätter inte en inventering av molnnycklar, domänkonton, databasanvändare, betalningsintegrationer, kundsystem eller en separat CI-leverantör. Den löser heller inte automatiskt otydliga ägare eller för breda rättigheter. Se den som bevis för att frågan är värd en egen process – inte som bevis för att processen är klar.
Bygg en minsta användbar förteckning
Ett mindre svenskt produktteam behöver inte börja med ett omfattande GRC-projekt. En kontrollerad tabell eller ett system ni redan använder kan räcka, så länge den har ett tydligt ansvar och inte innehåller hemliga värden.
För varje åtkomstuppgift, dokumentera:
- ett stabilt namn eller id,
- system och miljö,
- ägande team och en namngiven backup,
- syfte och beroende arbetsflöde,
- nivå av behörighet,
- rotations- eller utgångsdatum,
- senaste bekräftade kontroll,
- vad som bryts om den återkallas och hur den ersätts.
Länka gärna till den workflow, integration eller runbook som förklarar användningen. Lägg däremot aldrig in tokensträngar, privata nycklar eller lösenord i tabellen. Inventeringen är metadata om säkerhet; secret managern är platsen för hemligheten.
Gör ägarskap tydligt för automation och AI
Automatisering gör ofta åtkomstbilden otydligare. En CI-token kan användas av många contributors utan att någon egentligen ”har” den. En GitHub App kan installeras i flera repositories. En AI-agent kan få tillgång till verktyg genom en plugin, en MCP-server eller en serviceidentitet.
Det viktiga är att ägaren inte behöver vara samma sak som den identitet som gör anropet. En token kan tillhöra en releasebot, men ett team och en person måste vara ansvariga för dess räckvidd, rotation och avveckling. När ni introducerar ett nytt agentflöde bör inventeringsfrågan komma före ”kan den skapa PR:er?” Fråga i stället: vilken identitet använder den, vilka resurser når den, vilket godkännande krävs för skrivning och vem kan stänga av den?
Det hjälper er att skilja en nyttig begränsad integration från en otydlig superanvändare som råkar vara automatiserad.
En 30-dagars startplan
- Vecka 1: Lista era fem mest kritiska system och alla kända sätt som människa eller automation kan nå dem. Börja med kod, CI, produktion och paketregister.
- Vecka 2: Tilldela ägare och kontrollera behörighetsnivå, utgångsdatum och senaste användning. Markera okända eller breda identiteter som risker, inte som fel som måste lösas samma dag.
- Vecka 3: Rotera eller avveckla en liten grupp tydligt onödiga uppgifter efter att ni testat ersättningsflödet. Dokumentera rollback för de kritiska.
- Vecka 4: Gör inventeringen till en del av onboarding, offboarding och införandet av nya integrationer. Bestäm vem som kontrollerar den kvartalsvis eller inför en större release.
Det här är ett arbete där ”helt perfekt” lätt blir ett skäl att inte börja. En ofullständig men ägd lista över era viktigaste identiteter är betydligt bättre än ett tekniskt landskap som bara går att förstå när allt fungerar.
När bör ni välja en plattformsfunktion?
Om flera organisationer, många appar eller ett stort antal contributors använder GitHub kan Enterprise Clouds centraliserade export vara värd att utvärdera. Den kan göra incidentanalys och compliance-uppföljning mer konsekvent och ger standardiserade fält för just GitHub-identiteter.
Om teamet är mindre är beslutet ofta enklare: skapa en lättskött ägandemodell först och koppla den till de verktyg ni redan använder. Köp eller bygg inte en större lösning förrän ni ser vilken data och vilka processer som saknas.
Slutsats
Oavsett verktyg är principen densamma: möjlig åtkomst ska ha en synlig ägare, en avgränsad räckvidd och ett sätt att avvecklas. Inventera metadata, inte hemliga värden, och börja med de identiteter som kan skriva, deploya eller administrera verksamhetskritiska system.