Frånvaron av CodeQL default setup är inte längre ett stoppvillkor för AI Scan. Det är däremot fortfarande nödvändigt att code scanning är aktivt, att den effektiva AI Scan-inställningen tillåter körning och att en kvalificerad pull request innehåller kvalificerande ändringar. Inventera därför varje villkor separat och kalla inte ett repository verifierat förrän en ny commit har gett ett observerbart AI Scan-förlopp i PR-vyn.
Det borttagna kravet är bara en rad i beslutet
I en släppnotis den 16 september 2026 meddelar GitHub att AI Scan för pull requests inte längre kräver att CodeQL default setup är konfigurerat i repositoryt. Tidigare kördes funktionen bara i repositoryn där den konfigurationen fanns. Har en organisation redan aktiverat AI Scan kan funktionen därmed nå fler kvalificerade repositoryn än före ändringen.
Det betyder inte att alla repositoryn eller alla PR:er nu skannas. GitHubs dokumentation anger tre kumulativa villkor: code scanning ska vara aktivt för repositoryt, den effektiva AI Scan-inställningen ska vara aktiv och PR:en ska innehålla kvalificerande ändringar i ett språk eller ramverk som CodeQL inte täcker. Ett team som bara söker efter en CodeQL-workflow missar alltså både nya kandidater och andra orsaker till att en körning uteblir.
Ändringen är public preview på github.com för organisationsägda och personliga repositoryn. GitHub Enterprise Server omfattas inte av det här släppet. Dokumentationen anger också licenskrav för både GitHub Advanced Security och GitHub Copilot under previewn samt att användning förbrukar AI credits. Kontrollera därför avtal och kreditbudget innan ni öppnar ett brett prov; artikeln anger inga priser eller framtida villkor.
Bygg en inventering som visar effektivt läge
Börja med en rad per repository, inte en skärmbild från organisationsinställningen. Policyn har flera nivåer. En enterpriseägare behöver tillåta AI Scan innan en organisation kan aktivera funktionen. Organisationsinställningen gäller kvalificerade repositoryn där code scanning är aktivt, men en repositoryadministratör kan välja bort ett enskilt organisationsägt repository. För ett kvalificerat publikt repository på ett personligt konto sker aktiveringen direkt på repositorynivå.
| Fält | Vad ni ska anteckna | Varför det behövs |
|---|---|---|
| Ägare och plattform | Organisation eller personligt konto, github.com eller GHES | Släppets omfattning skiljer sig mellan plattformarna. |
| Licens och budget | Verifierad behörighet och ansvarig för AI credits | En synlig inställning är inte samma sak som godkänd användning. |
| Code scanning | Aktivt eller avstängt, med kontrolltid | AI Scan kräver code scanning även utan CodeQL default setup. |
| Effektiv AI Scan-policy | Enterprise, organisation, repository och eventuellt opt-out | Slutläget kan avvika från toppnivåns avsikt. |
| PR-flöde | Vanlig gren, fork eller Dependabot | Fork- och Dependabot-PR:er stöds inte. |
| Språk och diff | Språk, ramverk och den ändring som ska provas | En PR utan kvalificerande ändring bevisar inte att policyn är fel. |
Tidsstämpla inventeringen. GitHub skriver uttryckligen att språk, ramverk och detektionskategorier kan ändras medan funktionen utvecklas. En tabell från september 2026 är ett beslutsunderlag för den kontrollen, inte en permanent karta över framtida täckning.
Välj ett prov som kan svara på en fråga
Ta först ett repository som enligt tabellen borde omfattas och där provet kan raderas utan påverkan på produktion. Skapa en vanlig arbetsgren i samma repository. Använd inte en fork och låt inte Dependabot skapa PR:en, eftersom de flödena är dokumenterade undantag. Välj en liten ändring i ett språk eller ramverk som den aktuella dokumentationen anger som relevant för AI Scan och som CodeQL inte täcker i just det här sammanhanget.
Provet behöver inte plantera en sårbarhet. Första frågan är om funktionen kör, inte om den hittar ett visst fel. Öppna PR:en, spara bas- och head-SHA och notera vad som visas i Conversation och Files changed. Lägg sedan till en ofarlig ny commit som fortfarande innehåller en kvalificerande ändring. GitHub anger att AI Scan triggas när PR:en skapas och efter varje ny commit, på samma sätt som CodeQL.
Spara fyra datapunkter: repository, PR-länk, head-SHA och observerad status eller AI-märkt presentation. Om ni ser ett fynd dokumenterar ni även fil, rad, kategori och triagebeslut. AI Scan använder ett eget analysflöde och kan köras även när CodeQL väntar eller misslyckas, så en grön eller röd CodeQL-status är inte bevis för AI Scan-körningen.
Ett prov utan fynd kan betyda att inga relevanta fynd identifierades, men också att något körvillkor saknades eller att diffen inte var kvalificerande. Dokumentera därför körbevis och villkor separat från antal fynd. AI-baserade fynd kan dessutom innehålla falska positiva, så ett fynd behöver mänsklig triage innan det blir ett åtgärdsbeslut.
Prova ett negativt kontrollfall
Ett positivt test blir tydligare om ni parar det med ett avsiktligt undantag. Välj exempelvis ett fork-baserat PR-flöde eller ett repository där AI Scan är uttryckligen avstängt, utan att ändra produktionspolicyn bara för testets skull. Dokumentera att kontrollfallet inte ska räknas som täckt och varför. Syftet är inte att bevisa exakt vilket gränssnittsmeddelande GitHub visar, utan att säkerställa att inventeringen skiljer ”behörigt och verifierat” från ”undantaget genom design”.
Om det positiva fallet inte ger ett observerbart förlopp, felsök kolumn för kolumn. Bekräfta github.com, licenser, code scanning, enterprise-tillåtelse, organisationsinställning, repositoryts opt-out och PR-typ. Byt inte fem saker samtidigt. En ändring per omkörning gör att ni kan förklara vilket villkor som faktiskt saknades.
Dokumentera vad funktionen inte ersätter
AI Scan analyserar pull requests, inte hela repositoryn. Fynden visas i PR:ens Conversation- och Files changed-flikar och skapar inte backlog-varningar i repositoryts säkerhetsvy. De är rådgivande och blockerar inte merge, och GitHub anger att de ännu inte kan användas som ruleset-krav. En tom säkerhetsvy, en merge som gick igenom eller en gammal standardgren säger därför inget säkert om AI Scan-resultatet.
Koppla inventeringen till den bredare kontrollkedjan. AI-kreatörs guide om att säkerhetsgranska en AI-byggd kodbas täcker bland annat autentisering, beroenden och loggar som inte kan reduceras till ett PR-fynd. För blockerande mergevillkor behövs fortfarande uttryckliga statuskontroller och ägarskap enligt guiden om stoppregler före merge. AI Scan blir en extra signal i den kedjan, inte ett certifikat på att koden är säker.
Godkänn täckningen repository för repository. När nästa repository skiljer sig i ägare, språk, PR-flöde eller policyhierarki är det ett nytt fall, inte en kopia av det första. Det är just den skillnaden som ändringen efter CodeQL default setup gör lätt att missa: fler repositoryn kan vara berättigade, men endast ett verifierat körförlopp visar vilka som faktiskt deltar.
Källor
- GitHub Changelog: Code scanning AI Scan no longer requires CodeQL default setup – datum, det borttagna CodeQL-kravet, kvarvarande aktiveringskrav och previewns plattformsomfattning.
- GitHub Docs: AI Scan for pull requests – körvillkor, policyhierarki, licenser, presentation av fynd och dokumenterade begränsningar.
Uppgifterna kontrollerades mot GitHubs primärkällor den 17 september 2026. Inventeringstabellen, kontrollfallet och godkännandekriterierna är AI-kreatörs metod, inte GitHub-krav. Funktionen är public preview och kan ändras.