OpenAI Daybreak Blue-test: Ett verkligt säkerhetsfynd på en webbplats
Mitt OpenAI Daybreak Blue-test hittade ett säkerhetsproblem på min egen produktionswebbplats som jag kunde återskapa i en ny webbläsare: inloggningssidan låg kvar på HTTP i stället för att omdirigera till HTTPS. Sidan laddade dessutom 20 förstapartsresurser över samma okrypterade anslutning.
Resultatet var användbart av en enkel anledning. Modellen behövde inte en exotisk exploit för att hitta något meningsfullt. Den identifierade ett grundläggande transportfel, prioriterade det och gav mig ett konkret påstående att verifiera. Ett oberoende baslinjetest hittade samma kärnproblem.
Detta var en auktoriserad, icke-destruktiv granskning av Mixanalytic, en tjänst jag äger. Jag skickade inte in några inloggningsuppgifter, loggade inte in, utnyttjade inte webbplatsen, ändrade inga data och försökte inte skapa beständig åtkomst.
Varför jag testade Daybreak Blue på en verklig webbplats
Demonstrationer av säkerhetsmodeller använder ofta förberedda kodexempel eller kända sårbara labbmiljöer. Dessa tester är kontrollerade, men de visar inte hur modellen hanterar ett vanligt produktionssystem med ofullständig kontext.
Jag ville genomföra ett mer avgränsat test med ett tydligt godkänt resultat: kunde modellen inspektera den offentliga ytan på en webbplats jag äger, hitta ett reproducerbart problem och skilja bevis från spekulation?
Jag ville också jämföra resultatet med en oberoende baslinje. Jag har testat andra AI-system med ett liknande evidensförst-perspektiv i mitt säkerhetstest av en AI-chattbot→, där det användbara resultatet var en verifierad teknisk förändring snarare än en dramatisk attackberättelse.
Vilken modell körde jag egentligen?
Den första granskningen kördes i en separat Codex-worker som tilldelats modellidentifieraren `gpt-daybreak-blue-latest`. OpenAI:s dokumentation kallar det godkända erbjudandet GPT-Daybreak-Blue.
Den skillnaden är viktig. Att ändra den valda modellen i en senare chatt gör inte i efterhand en tidigare körning till ett Daybreak-test. Den exekvering som utför granskningen måste använda den godkända Daybreak-modellen och produktytan.
OpenAI beskriver Daybreak Blue som utgångspunkten för de flesta auktoriserade defensiva uppgifter, inklusive sårbarhetsidentifiering, säker kodgranskning, hotmodellering, detekteringsutveckling, incidenthantering och validering av patchar. Företaget rekommenderar också kontrollerade miljöer, minsta möjliga behörighet, definierad omfattning och mänsklig granskning för känsliga åtgärder (Models and Trusted Access).
Upplägg och omfattning för OpenAI Daybreak Blue-testet
Jag gav modellen tillstånd att inspektera Mixanalytic och dess lokala projektfiler. Jag höll de externa kontrollerna icke-destruktiva:
Modellen fick inte skicka in inloggningsformuläret, testa riktiga inloggningsuppgifter, skapa konton, ladda upp payloads, utnyttja en misstänkt svaghet eller ändra produktionen.
Denna avgränsning gjorde resultatet lättare att tolka. Varje fynd behövde komma från offentligt beteende eller skrivskyddade källbevis.
Huvudfyndet: en inloggningssida låg kvar på HTTP
Black-box-kontrollen visade att både webbplatsens rot och inloggningsrouten returnerade `200 OK` över HTTP. Inget av svaren omdirigerade webbläsaren till HTTPS.
Jag öppnade sedan inloggningssidan i en ny Chromium-kontext. Webbläsaren stannade på en `http://`-URL medan den visade fält för användarnamn och lösenord. Under sidladdningen använde även 20 förstapartsförfrågningar för JavaScript, CSS, bilder och dokument HTTP.
| Kontroll | Observerat resultat |
|---|---|
| --- | --- |
| HTTP-omdirigering | Ingen omdirigering till HTTPS på den testade roten eller inloggningssidan |
| Ny webbläsare | Chromium stannade på HTTP-inloggningssidan |
| Förstapartsresurser | 20 förfrågningar laddades över HTTP under webbläsarkörningen |
| Anonym sessionscookie | `Secure=false`, `HttpOnly=true`, `SameSite=Lax` |
Cookie-resultatet behöver sättas i sitt sammanhang. `HttpOnly` och `SameSite=Lax` var positiva attribut, men den saknade `Secure`-flaggan gjorde att den anonyma sessionscookien kunde skickas över en okrypterad anslutning.
Jag bedömde transportproblemet som en hög risk efter webbläsartestet. En angripare som befinner sig på nätverksvägen skulle kunna observera eller ändra HTTP-trafik. Om en användare skickade in inloggningsuppgifter på sidan skulle den okrypterade anslutningen kunna exponera dem. Jag hittade inga bevis för att någon hade stulit inloggningsuppgifter, och jag skickade inte in några under testet.
Webbläsarverifieringen ändrade allvarlighetsbedömningen
Den första oberoende baslinjen klassificerade HTTP-beteendet som medelhög allvarlighetsgrad. Bedömningen ändrades efter att körningsverifieringen visade ett verkligt lösenordsformulär som låg kvar på HTTP, samtidigt som dess stödresurser också laddades över HTTP.
Denna förändring säger mer om testmetoden än om modellerna. Inspektion av svarshuvuden identifierade konfigurationsproblemet. Webbläsarbevis visade hur en besökare skulle möta det. Den extra evidensen gjorde påverkan tillräckligt konkret för att motivera högre prioritet.
Daybreak Blue nådde samma kärnslutsats. Båda körningarna gynnades av samma regel: ett fynd bör innehålla en reproducerbar observation, ett avgränsat påstående om påverkan och en tydlig lista över åtgärder som inte utfördes.
Vad de sekundära kontrollerna hittade
Granskningen gav också flera resultat med lägre prioritet.
Moderna TLS-versioner fungerade
Den testade värden avvisade TLS 1.0 och 1.1 samtidigt som den accepterade TLS 1.2 och 1.3. Det är ett positivt resultat för HTTPS-slutpunkten. Det kompenserar inte för att inloggningsupplevelsen tillåts ligga kvar på HTTP.
Content Security Policy tillät inline-kod
Den observerade Content Security Policy inkluderade `'unsafe-inline'` för skript och stilar. Jag behandlade detta som en brist i härdningen, inte som ett bevis på en cross-site scripting-sårbarhet. Att ta bort inline-tillåtelser kräver vanligtvis applikationsändringar och regressionstester, så det bör göras efter transportfixen.
Webbplatsen saknade `security.txt`
Standardsökvägen `/.well-known/security.txt` returnerade `404`. Jag klassificerade detta som informativt. En säkerhetskontaktfil ger forskare en tydlig rapporteringsväg, men frånvaron av den skapar inte en exploaterbar brist.
Den testade CORS-preflight-begäran tillät inte den externa origin
En preflight-begäran från en orelaterad origin fick inte tillstånd att komma åt den testade offentliga routen. Det är ett användbart negativt resultat, begränsat till den slutpunkt och preflight jag kontrollerade. Det är inte en fullständig CORS-granskning av hela webbplatsen.
Överträffade Daybreak Blue baslinjen?
Detta test stöder inte någon generell modellrankning. Daybreak Blue och den oberoende baslinjen hittade båda transportproblemet. Baslinjens allvarlighetsbedömning förbättrades när jag lade till webbläsarbevis.
Daybreak Blue var värdefull eftersom den höll sig fokuserad på en auktoriserad defensiv uppgift och producerade ett fynd som jag kunde verifiera. En webbplats, en omfattning och ett testdatum kan inte fastställa att den kommer att överträffa en annan modell inom källgranskning, incidenthantering, malwareanalys eller större penetrationstester.
Ett starkare benchmark skulle upprepa samma dolda testfall över flera ägda applikationer, ge varje modell samma verktyg och tidsbudget samt bedöma reproducerbarhet, falska positiva, missade fynd, kalibrering av allvarlighetsgrad och kvaliteten på åtgärdsförslagen.
Jag använder den bredare utvärderingsmetoden i Så benchmarkar du AI-modeller för verkligt arbete→. Denna Daybreak-körning är en fältrapport, inte ett fullständigt benchmark.
Hur får man OpenAI Daybreak Blue?
Daybreak-åtkomst kräver godkännande genom OpenAI:s Trusted Access for Cyber-program. Privatpersoner kan ansöka via den individuella Trusted Access-ansökan, medan organisationer kan använda formuläret för företagsförfrågningar.
Godkännandet är knutet till den godkända identiteten eller tjänsten, arbetsytan eller API-organisationen och projektet, modellen samt produktytan. Att slutföra identitetsverifieringen eller skicka in formuläret garanterar inte åtkomst. Daybreak Red kräver också separat godkännande; Blue-åtkomst inkluderar det inte automatiskt.
OpenAI:s bredare Daybreak-arbetsflöde kopplar samman utredning, granskning av kodarkiv, bevis, föreslagna korrigeringar och mänsklig verifiering. Den egna vägledningen håller ingenjören ansvarig för konsekvensrika ändringar (Scaling cyber defenders with Daybreak).
Källor och testprotokoll
Jag genomförde de auktoriserade kontrollerna den 30 augusti 2026. Webbläsar-, header-, cookie-, TLS-, CSP-, `security.txt`- och CORS-observationerna i denna artikel kommer från det testprotokollet.
Påståendena om modellen och åtkomsten kommer från två primära OpenAI-källor:
Enligt OpenAI:s åtkomstvägledning är godkännandet fortfarande specifikt för identiteten, arbetsytan eller API-projektet, modellen och produktytan. Mina testresultat sträcker sig inte utanför den Mixanalytic-omfattning som beskrivs ovan.
Vad jag skulle åtgärda och testa om härnäst
Transportfyndet har en kort prioriteringsordning:
Omtestet bör misslyckas om någon inloggningssida, formuläråtgärd, förstapartsresurs eller sessionscookie faller tillbaka till HTTP. Jag skulle också köra Daybreak- och baslinjegranskningarna igen mot den åtgärdade versionen för att kontrollera om de känner igen korrigeringen och undviker att rapportera samma fynd på nytt.
Det första testet gav ett användbart resultat utan att överskrida auktoriseringsgränsen. Daybreak Blue hittade en verklig brist. Oberoende webbläsarbevis visade varför den förtjänade uppmärksamhet. Nästa trovärdiga påstående är inte att verktyget fungerade en gång, utan att korrigeringen klarar samma test.