OpenAI lanserar Codex Security – AI-agenten som hittar, bekräftar och hjälper till att laga sårbarheter

OpenAI har gjort Codex Security tillgängligt som en research preview. Det är en AI-agent för applikationssäkerhet som analyserar kodprojekt, bygger en projektspecifik hotmodell, söker efter verkliga sårbarheter och försöker validera de mest trovärdiga fynden i isolerade miljöer.

Målet är inte att skapa ännu en skanner som producerar tusentals varningar. OpenAI vill i stället minska säkerhetsteamens största praktiska problem: för många fynd med låg betydelse, överdriven allvarlighetsgrad och falska positiva resultat.

Codex Security försöker därför förstå vad systemet faktiskt gör, vilka komponenter det litar på, vilka data som är känsliga och var en angripare realistiskt kan ta sig in.

När ett misstänkt problem hittas kan agenten samla bevis, försöka reproducera sårbarheten i en sandlåda och föreslå en begränsad patch som en människa granskar innan någon kod ändras.

Det gör Codex Security till något mer än traditionell statisk kodanalys. Samtidigt är produkten fortfarande en förhandsversion och ska inte betraktas som en ersättning för säkerhetsingenjörer, penetreringstester eller etablerade SAST-, DAST- och SCA-verktyg.

Från Aardvark till Codex Security

Codex Security hette tidigare Aardvark och började som en sluten betaversion med ett mindre antal kunder.

OpenAI uppger att tidiga interna körningar hittade verkliga problem, däribland:

• en server-side request forgery, förkortad SSRF,
• en kritisk autentiseringssårbarhet mellan klienter,
• flera andra säkerhetsproblem som företagets säkerhetsteam åtgärdade inom några timmar.

Under betaperioden arbetade OpenAI med att förbättra signal-brus-förhållandet. Företaget säger att samma kodlager, skannade över tid, visade tydligt bättre precision.

I ett projekt minskade bruset med 84 procent jämfört med den första versionen. OpenAI uppger även att:

• andelen fynd med överdriven allvarlighetsgrad minskade med mer än 90 procent,
• andelen falska positiva detektioner minskade med mer än 50 procent i samtliga testade kodlager.

Siffrorna kommer från OpenAI:s egen betautvärdering. De visar produktens avsedda riktning, men oberoende tester behövs för att avgöra hur väl resultaten överförs till andra språk, arkitekturer och utvecklingsmiljöer.

Så fungerar Codex Security

Codex Security arbetar i flera steg.

1. Agenten bygger en hotmodell

Efter att ett kodlager har anslutits analyserar agenten systemets säkerhetsrelevanta struktur.

Den försöker bland annat förstå:

• vilka komponenter som tar emot extern input,
• vilka autentiserings- och behörighetsgränser som finns,
• vilka databaser och externa tjänster som används,
• var känsliga uppgifter hanteras,
• vilka delar som är internetexponerade,
• vilka antaganden systemet gör om betrodda användare och tjänster.

Resultatet blir en redigerbar hotmodell. Teamet kan korrigera modellen och lägga till verksamhetskunskap som inte framgår direkt av koden.

Exempel:

```text

• Administratörspanelen är endast åtkomlig via företagets VPN.
• Webhook-endpointen är publik och tar emot osignerad JSON.
• Kund A och kund B måste vara fullständigt isolerade.
• Filsystemet innehåller inga beständiga hemligheter.
• Betalningsflödet är den mest kritiska delen av systemet.

```

Den här kontexten hjälper agenten att skilja ett verkligt kritiskt problem från kod som ser farlig ut men ligger bakom andra skydd.

2. Koden skannas commit för commit

Molnversionen analyserar anslutna GitHub-repositoryn från de senaste ändringarna och bakåt genom den historik som teamet väljer.

En längre historik ger mer kontext, men den första genomgången tar längre tid. OpenAI anger att initial backfill i ett större repository kan ta flera timmar.

Commit-baserad analys kan hjälpa agenten att förstå:

• när en risk introducerades,
• vilka funktioner som ändrades samtidigt,
• om en skyddskontroll togs bort,
• hur en sårbar kodväg har utvecklats,
• vilken patch som kan göras utan att bryta avsedd funktion.

3. Misstänkta fynd valideras i en sandlåda

När Codex Security hittar ett trovärdigt problem försöker systemet, där det är möjligt, validera fyndet i en isolerad miljö.

Enligt OpenAI körs varje analys- och valideringsjobb i en tillfällig Codex-container med sessionsbegränsade verktyg. Relevanta artefakter hämtas ut för granskning och containern förstörs när jobbet är färdigt.

Valideringen kan innehålla:

• reproduktionssteg,
• kraschutskrifter,
• anropsvägar,
• testdata,
• bevis på att en skyddskontroll kan kringgås,
• en fungerande proof of concept.

Det är en viktig skillnad mot en skanner som endast hittar ett riskabelt kodmönster. Codex Security försöker avgöra om mönstret faktiskt går att utnyttja i projektets sammanhang.

4. Fynden prioriteras efter verklig påverkan

Fynden rangordnas efter förväntad risk i det aktuella systemet.

Ett oskyddat endpoint kan exempelvis vara:

• kritiskt om det är internetexponerat och ändrar betalningsdata,
• medelhögt om det endast är tillgängligt internt,
• irrelevant om koden är ett oanvänt testexempel.

Användaren får bland annat:

• allvarlighetsgrad,
• valideringsstatus,
• teknisk förklaring,
• reproduktionsbevis,
• relaterad kodkontext,
• föreslagen åtgärd,
• ibland en färdig patch.

5. Codex föreslår en patch

Codex Security kan föreslå ändringar som tar hänsyn till systemets avsikt och omgivande beteende.

Det är viktigt att verktyget inte automatiskt applicerar patchar i repositoryt.

Användaren granskar förslaget och kan därefter välja att skapa en pull request i GitHub. Detta minskar risken för att en AI-genererad säkerhetsfix introducerar regressioner eller förändrar affärslogiken på ett oväntat sätt.

Vad är en hotmodell?

En hotmodell är en strukturerad beskrivning av:

• vad som behöver skyddas,
• vilka angripare som är relevanta,
• var systemets förtroendegränser går,
• hur data rör sig,
• vilka attackvägar som är mest sannolika,
• vilka konsekvenser ett intrång kan få.

Traditionella kodskannrar ser främst kod. En hotmodell försöker lägga till frågan:

> Spelar det här problemet faktiskt roll i just detta system?

Exempelvis kan samma SQL-injektionsliknande kodrad få olika prioritet beroende på om den används i ett internt administrationsskript eller i en publik endpoint som hanterar kunddata.

Hotmodellen är inte garanterat korrekt bara för att den har genererats av en AI. Teamet behöver granska:

• systemets verkliga gränser,
• nätverksarkitektur,
• externa skydd,
• dataklassning,
• vilka användare som ska betraktas som betrodda,
• verksamhetens egen riskaptit.

Dålig eller ofullständig produktkontext kan annars leda till att agenten prioriterar fel.

Hur skiljer det sig från vanliga säkerhetsverktyg?

SAST

• Analyserar: källkod och kodmönster.
• Styrka: snabb, repeterbar och väl integrerad i CI.
• Begränsning: kan ge många falska positiva resultat.

SCA

• Analyserar: beroenden och kända CVE:er.
• Styrka: bra på kända tredjepartsrisker.
• Begränsning: hittar inte unik logik i den egna applikationen.

DAST

• Analyserar: en körande applikation utifrån.
• Styrka: testar verkligt exponerade gränssnitt.
• Begränsning: ser ofta inte den bakomliggande kodorsaken.

Manuell kodgranskning

• Analyserar: kod och systemkontext.
• Styrka: djup förståelse och mänskligt omdöme.
• Begränsning: kostsam och tidskrävande.

Codex Security

• Analyserar: kod, historik, hotmodell och validering.
• Styrka: kan resonera över flera filer och försöka bekräfta fynd.
• Begränsning: icke-deterministiskt och fortfarande research preview.

Codex Security bör användas tillsammans med de andra metoderna.

Ett välbyggt säkerhetsflöde kan exempelvis använda:

1. SCA för att hitta sårbara paket.

2. SAST vid varje pull request.

3. Codex Security för djupare kontextuell analys.

4. DAST mot stagingmiljön.

5. Manuell granskning av kritiska förändringar.

6. Penetreringstest före större lanseringar.

Resultaten från betaprogrammet

Under de 30 dagar som OpenAI redovisade skannade Codex Security över 1,2 miljoner commits i externa repositoryn inom betakohorten.

Systemet identifierade:

• 792 kritiska fynd,
• 10 561 fynd med hög allvarlighetsgrad.

OpenAI säger att kritiska problem förekom i drygt 0,1 procent av de skannade commitsen. Det illustrerar produktens mål: att söka igenom mycket stora kodmängder och lyfta fram en liten andel problem som kan få verkliga konsekvenser.

Siffrorna betyder inte automatiskt att samtliga fynd var unika, exploaterbara sårbarheter eller senare tilldelades CVE-nummer. Ett fynd kan vara projektspecifikt och fortfarande mycket allvarligt utan att bli en offentlig CVE.

OpenAI använde Codex Security på öppen källkod

OpenAI har använt verktyget för att skanna projekt med öppen källkod som företagets egna system är beroende av.

Företaget säger att kritiska sårbarheter rapporterades till bland annat:

• OpenSSH,
• GnuTLS,
• GOGS,
• Thorium,
• libssh,
• PHP,
• Chromium.

OpenAI uppger att 14 CVE-nummer hade tilldelats, med dubbel rapportering i två fall.

Exempel i företagets bilaga omfattar:

• heap-buffer overflow i GnuTLS `certtool`,
• heap-overread i SCT-parsning,
• double-free i hantering av `otherName`,
• kringgående av tvåfaktorsautentisering i GOGS,
• oautentiserat autentiseringskringgående i GOGS,
• path traversal med möjlighet till godtycklig skrivning,
• LDAP-injektion,
• stackbaserade buffertöverflöden i GnuPG-relaterade komponenter.

En tilldelad CVE är ett starkare bevis än en vanlig modellgenererad varning, eftersom problemet då har gått genom en extern rapporterings- och koordineringsprocess.

Det visar däremot inte att agenten ensam genomförde hela processen. Ansvarsfull sårbarhetsrapportering kräver fortfarande människor som verifierar, kommunicerar med underhållare och bedömer när tekniska detaljer kan publiceras.

Codex for OSS

OpenAI kopplar även Codex Security till programmet Codex for OSS.

Programmet ska ge vissa underhållare av öppen källkod kostnadsfria ChatGPT Pro- eller Plus-konton, kodgranskning och tillgång till Codex Security.

Bakgrunden är ett välkänt problem i open source-världen: underhållare får ofta stora mängder automatiska säkerhetsrapporter av låg kvalitet. Att behandla dessa rapporter tar tid från själva utvecklingen.

OpenAI säger att Codex Security därför ska prioritera färre fynd med högre tillförlitlighet, snarare än att maximera antalet varningar.

Projektet vLLM har enligt OpenAI redan använt systemet för att identifiera och åtgärda problem i sitt vanliga utvecklingsflöde.

Tre olika sätt att använda Codex Security

Den aktuella dokumentationen beskriver flera produktvägar.

Codex Security-plugin

Pluginet körs i en Codex-chatt och kan användas mot ett lokalt repository i:

• ChatGPTs skrivbordsapp,
• Codex CLI.

Det kan bland annat:

• köra en vanlig säkerhetsskanning,
• köra en djupare skanning,
• granska en branch eller pull request,
• triagera befintliga säkerhetsfynd,
• föreslå och verifiera avgränsade fixar,
• exportera resultat,
• skriva sårbarhetsrapporter,
• föreslå generell härdning.

OpenAI rekommenderar i snabbstarten modellen `gpt-5.6-sol` med reasoning-läget `xhigh` för bästa skanningskvalitet.

Codex Security Cloud

Molnversionen är fortfarande märkt research preview.

Den ansluter till GitHub-repositoryn genom Codex Cloud och:

• bygger kontext från kod och commit-historik,
• skannar nya ändringar,
• validerar starka fynd i en isolerad miljö,
• presenterar rankade fynd och patchförslag,
• kan skapa en granskningsbar pull request.

Första genomgången kan ta flera timmar i större repositoryn.

CLI och TypeScript-SDK

CLI:n och SDK:n är enligt OpenAI i begränsad beta för godkända kunder och partners.

De kan användas för:

• skanning av flera repositoryn,
• återupptagningsbara skanningskampanjer,
• repositoryinventering via CSV,
• kostnadsgränser,
• lagring av falsk-positiv-feedback,
• körningar före commits,
• CI-integration,
• SARIF-export,
• integration i egna utvecklarverktyg.

Så kör du en första lokal skanning

I ChatGPTs skrivbordsapp

1. Öppna repositoryt i Codex.

2. Öppna Plugins.

3. Sök efter Codex Security.

4. Installera pluginet.

5. Starta en ny Codex-chatt för repositoryt.

6. Skriv:

```text

Run a Codex Security scan on this repository.

```

7. Kontrollera att rätt repository, branch och senaste commit har valts.

8. Börja med:

• Scan type: `Codebase`
• Deep scan: `Off`
• Scan area: `Entire codebase`

9. Starta skanningen.

10. Granska resultaten i gränssnittet eller öppna den genererade `report.md`.

I Codex CLI

Starta Codex i repositoryt:

```bash

cd /sokvag/till/projektet

codex

```

Installera pluginet:

```text

/plugins

```

Sök efter Codex Security, installera det och starta en ny chatt:

```text

/new

```

Kör sedan:

```text

Run a Codex Security scan on this repository.

```

Skanna endast kod som du äger eller uttryckligen har tillstånd att säkerhetsgranska.

Exempel på bättre instruktioner

En generell skanning är en bra start, men resultatet blir ofta bättre med relevant systemkontext.

```text

Run a Codex Security scan on this repository.

Prioritize:

• authentication and authorization boundaries,
• tenant isolation,
• file uploads,
• webhook signature verification,
• secrets handling,
• SQL injection,
• SSRF,
• path traversal.

The public API is exposed to the internet.

The admin interface is only available through our VPN.

Do not modify files or open a pull request without approval.

```

För svensk rapport:

```text

Kör en säkerhetsgranskning av detta repository.

Prioritera:

• autentisering,
• behörighetskontroller,
• separation mellan kunder,
• filuppladdningar,
• API-nycklar och hemligheter,
• webhook-verifiering,
• SSRF,
• SQL-injektion,
• path traversal.

Skriv rapporten på svenska.

Ändra ingen kod utan mitt godkännande.

```

Vad Codex Security inte gör

Det garanterar inte att koden är säker

Ingen skanner kan bevisa att ett komplext system saknar sårbarheter.

Agenten kan missa problem på grund av:

• ofullständig hotmodell,
• saknade miljöberoenden,
• otillgängliga externa tjänster,
• okänd produktionskonfiguration,
• modellfel,
• begränsad testtid,
• bristande testdata.

Det applicerar inte patchar automatiskt

OpenAI säger uttryckligen att föreslagna patchar måste granskas. Verktyget kan hjälpa till att öppna en pull request, men ändringarna ska inte automatiskt landa i huvudbranchen.

Det ersätter inte ett penetreringstest

Kodanalys kan hitta mycket, men ett realistiskt penetrationstest undersöker även:

• nätverk,
• molnkonfiguration,
• identitetssystem,
• produktionsbeteende,
• mänskliga arbetsflöden,
• kedjor mellan flera system.

Det ersätter inte en säkerhetsansvarig

Någon måste fortfarande:

• äga riskbeslutet,
• prioritera åtgärder,
• verifiera verksamhetspåverkan,
• koordinera sårbarhetsrapportering,
• godkänna patchar,
• hantera incidenter.

Säkerhetsrisker med en AI-säkerhetsagent

Ett verktyg som kan hitta och validera sårbarheter är kraftfullt. Det måste därför köras med tydliga begränsningar.

Koden kan vara känslig

Molnversionen behöver åtkomst till anslutna GitHub-repositoryn. Företag bör kontrollera:

• vilken organisation som är ansluten,
• vilka repositoryn som är synliga,
• vilka branches som skannas,
• workspace-behörigheter,
• datalagring och avtal,
• revisionsloggar,
• regionala och regulatoriska krav.

Proof of concept kan vara farlig

En fungerande verifiering av en sårbarhet kan även användas offensivt. Resultat bör därför behandlas som känslig säkerhetsinformation.

AI-genererade patchar kan introducera fel

En patch kan:

• bryta kompatibilitet,
• ändra affärslogik,
• skapa en ny sårbarhet,
• lösa symptomet men inte grundorsaken,
• försämra prestanda.

Kräv kodgranskning och automatiska tester före merge.

Agenten behöver en begränsad miljö

Validering bör ske mot testdata och isolerade miljöer, inte direkt mot produktion.

OpenAI säger att molnjobben körs i tillfälliga Codex-containrar med sessionsbegränsade verktyg. Teamet behöver fortfarande kontrollera vad den anslutna miljön innehåller och vilka externa resurser som är åtkomliga.

Research preview betyder att produkten kan förändras

Begreppet research preview innebär att funktionen fortfarande utvärderas och kan förändras snabbt.

Det kan innebära:

• ändrad tillgänglighet,
• nya begränsningar,
• justerade priser,
• ofullständig dokumentation,
• variation i resultat,
• nya säkerhetskontroller,
• funktioner som flyttas mellan plugin, cloud, CLI och SDK.

När OpenAI publicerade lanseringen den 6 mars 2026 började Codex Security rullas ut till ChatGPT Enterprise-, Business- och Edu-kunder, med gratis användning under den efterföljande månaden.

Det erbjudandet var tidsbegränsat och ska inte tolkas som att tjänsten fortfarande är gratis i juli 2026. Den aktuella offentliga dokumentationen anger ingen enkel fristående prislista för Codex Security. Organisationer bör därför kontrollera sin workspace-konfiguration eller kontakta OpenAI för aktuella villkor.

CLI:n och TypeScript-SDK:n är fortfarande begränsade till godkända kunder och partners.

Fördelar och nackdelar

Fördelar

• bygger projektspecifik hotmodell,
• analyserar flera filer och commit-historik,
• försöker bekräfta sårbarheter i en sandlåda,
• kan minska falska positiva resultat,
• prioriterar efter verklig påverkan,
• föreslår granskningsbara patchar,
• kan användas lokalt, i molnet, CLI och SDK,
• stödjer CI och SARIF genom betaversionen,
• kan lära sig av teamets feedback,
• har redan bidragit till flera tilldelade CVE:er.

Nackdelar

• fortfarande research preview,
• kan missa sårbarheter,
• leverantörens precisionssiffror är inte oberoende,
• molnversionen kräver kodåtkomst,
• djupa skanningar kan ta lång tid,
• kostnaden är inte tydligt offentligt specificerad,
• CLI och SDK har begränsad tillgång,
• AI-genererade patchar kräver noggrann granskning,
• resultatet påverkas av hotmodellens kvalitet.

Vem bör använda Codex Security?

Codex Security är främst relevant för:

• säkerhetsteam som granskar många repositoryn,
• produktteam utan tillräcklig AppSec-kapacitet,
• företag som redan använder GitHub och Codex Cloud,
• open source-underhållare,
• utvecklare som vill säkerhetsgranska en branch före merge,
• organisationer som vill prioritera befintliga säkerhetsbackloggar,
• team som behöver bättre förklaringar och reproduktionsbevis.

Mindre projekt kan börja med det lokala pluginet och en skrivskyddad skanning. Större organisationer behöver först definiera åtkomst, ansvar, dataklassning och hur resultaten ska föras in i det befintliga sårbarhetsflödet.

Slutsats

Codex Security visar hur AI-kodagenter håller på att flytta från att bara skriva funktioner till att förstå och granska hela systems säkerhetsmodell.

Den stora innovationen är inte att modellen kan känna igen en farlig kodrad. Det har traditionella skannrar kunnat göra länge.

Det nya är kombinationen av:

• projektspecifik hotmodell,
• analys över flera filer och commits,
• agentiskt resonemang,
• validering i isolerad miljö,
• reproduktionsbevis,
• föreslagna patchar,
• återkoppling från säkerhetsteamet.

Det kan minska tiden från misstänkt kod till verifierat och åtgärdbart säkerhetsproblem.

Men ett AI-system som hittar och exploaterar sårbarheter måste behandlas som ett känsligt säkerhetsverktyg. Repositoryåtkomst, körmiljö, resultat, proof of concept och patchar behöver samma styrning som annan offensiv och defensiv säkerhetsteknik.

Codex Security är därför mest lovande som en förstärkning av mänskliga säkerhetsteam – inte som en automatisk ersättare för dem.

Vanliga frågor

Vad är Codex Security?

Codex Security är OpenAI:s AI-agent för applikationssäkerhet. Den bygger en hotmodell, hittar misstänkta sårbarheter, försöker validera dem och föreslår åtgärder.

Är Codex Security samma sak som vanlig Codex-kodgranskning?

Nej. Vanlig kodgranskning fokuserar bredare på kvalitet och korrekthet. Codex Security har ett särskilt arbetsflöde för hotmodellering, säkerhetsdetektion, validering och patchförslag.

Ändrar verktyget min kod automatiskt?

Nej. Patchar är rekommendationer som användaren måste granska. De kan skickas som pull requests, men tillämpas inte automatiskt.

Vilka programmeringsspråk stöds?

OpenAI beskriver systemet som språkagnostiskt. Den praktiska kvaliteten beror på modellens förståelse av det aktuella språket och ramverket.

Körs exploateringsförsök mot produktion?

Valideringsjobben ska köras i tillfälliga, isolerade Codex-containrar. Teamet bör ändå använda testkonfiguration och säkerställa att agenten inte får onödig produktionsåtkomst.

Vilka planer har tillgång?

Molnversionen lanserades för ChatGPT Enterprise, Business och Edu och är fortfarande märkt research preview. Pluginets synlighet beror på konto och workspace. CLI och SDK är begränsad beta för godkända kunder och partners.

Vad kostar Codex Security?

OpenAI erbjöd gratis användning under en månad efter lanseringen den 6 mars 2026. Den aktuella offentliga dokumentationen visar ingen enkel separat prislista. Kontrollera workspace eller kontakta OpenAI för aktuella villkor.

Kan det ersätta SAST?

Nej. Codex Security kompletterar SAST genom djupare systemkontext och validering. SAST är fortfarande värdefullt för snabb och deterministisk kontroll vid varje kodändring.

Har Codex Security hittat verkliga sårbarheter?

OpenAI uppger att verktyget bidragit till rapportering av kritiska problem i flera open source-projekt och att 14 CVE-nummer hade tilldelats, med två dubbelrapporterade fall.

Hur börjar jag?

Installera Codex Security-pluginet i ChatGPTs skrivbordsapp eller genom `/plugins` i Codex CLI. Starta en ny chatt och be agenten köra en skrivskyddad säkerhetsskanning av ett repository som du äger eller har tillstånd att granska.

Källor

• OpenAI, Codex-säkerhet är nu tillgängligt som en förhandsvisning för forskning, 6 mars 2026:

https://openai.com/sv-SE/index/codex-security-now-in-research-preview/

• OpenAI-dokumentation, Codex Security overview:

https://learn.chatgpt.com/docs/security

• OpenAI-dokumentation, Codex Security plugin quickstart:

https://learn.chatgpt.com/docs/security/plugin

• OpenAI-dokumentation, Codex Security cloud setup:

https://learn.chatgpt.com/docs/security/setup

• OpenAI-dokumentation, Codex Security cloud FAQ:

https://learn.chatgpt.com/docs/security/faq