I flere tiår har statisk sikkerhetstesting av applikasjoner (SAST) vært en av de mest effektive måtene sikkerhetsteam kan skalere kodegjennomgang på.
Men da vi bygde Codex Security, tok vi et bevisst designvalg: vi startet ikke med å importere en statisk analyserapport og be agenten om å gjøre triage på den. Vi utviklet systemet slik at det starter med selve lageret – arkitekturen, tillitsgrenser og den tiltenkte oppførselen – og validerer funn før det ber et menneske om å bruke tid på det.
Grunnen er enkel: de vanskeligste sårbarhetene er vanligvis ikke dataflytproblemer. De oppstår når kode ser ut til å håndheve en sikkerhetssjekk, men den sjekken garanterer faktisk ikke egenskapen systemet er avhengig av. Utfordringen er med andre ord ikke bare å spore hvordan data beveger seg gjennom et program – det er å finne ut om forsvarsmekanismene i koden faktisk fungerer.
SAST er ofte fremstilt som en ren pipeline: identifiser en kilde til upålitelig inndata, spor data gjennom programmet og merk tilfeller der dataene når et sensitivt sluk uten rensing. Det er en elegant modell, og den dekker mange ekte feil.
I praksis må SAST gjøre tilnærminger for å holde seg håndterbar i stor skala – spesielt i virkelige kodebaser med indireksjon, dynamisk videresending, tilbakekallinger, refleksjon og rammeverkstung kontrollflyt. Disse tilnærmingene er ikke en kritikk av SAST, de er realiteten når man prøver å resonnere om kode uten å kjøre den.
Det er ikke den eneste grunnen til at Codex Security ikke starter med en SAST-rapport.
Det dypere problemet er hva som skjer etter at du har sporet en kilde til et sluk.
Selv når statisk analyse korrekt sporer inndata på tvers av flere funksjoner og lag, må den fortsatt svare på spørsmålet som faktisk avgjør om det finnes en sårbarhet:
Ta et vanlig mønster: koden kaller på noe som sanitize_html() før den gjengir upålitelig innhold. Et statisk analysator kan se at renseren ble kjørt. Det den vanligvis ikke kan avgjøre, er om denne renseren faktisk er tilstrekkelig for den spesifikke gjengivelseskonteksten, malmotoren, kodingsatferden og nedstrøms transformasjonene som er involvert.
Det er her det blir vanskelig. Problemet er ikke bare om data når frem til en sluk. Det er om hvorvidt kontrollene i koden faktisk begrenser verdien på den måten systemet antar at de gjør.
Sagt på en annen måte: det er stor forskjell på «koden kaller en renser» og «systemet er trygt.»
Her er et mønster som dukker opp i virkelige systemer hele tiden.
En nettapplikasjon mottar en JSON-nyttelast, trekker ut en redirect_url, validerer den mot en tillatelsesliste-regex, dekoder den og sender resultatet til en omdirigeringsbehandler.
En klassisk kilde til sluk-rapport kan beskrive flyten:
upålitelig inndata → regex-sjekk → URL-dekoding → omdirigering
Men det virkelige spørsmålet er ikke om kontrollen finnes. Det er om den kontrollen fortsatt begrenser verdien etter de påfølgende transformasjonene.
Hvis regexen kjører før dekoding, begrenser den faktisk den dekodede URL-en slik omdirigeringsbehandleren forstår den?
For å svare på det må man resonnere om hele transformasjonskjeden: hva regexen tillater, hvordan dekoding og normalisering fungerer, hvordan URL-parsing behandler grensetilfeller, og hvordan omdirigeringslogikken løser skjemaer og autoriteter.
Mange av sårbarhetene som er viktige i praksis ser slik ut: feil i rekkefølgen på operasjoner, delvis normalisering, tvetydig parsing og misforhold mellom validering og tolkning. Dataflyten er synlig. Svakheten ligger i hvordan begrensninger forplanter seg – eller ikke forplanter seg – gjennom transformasjonskjeden.
Dette er ikke bare et teoretisk mønster. I CVE-2024-29041(åpnes i et nytt vindu) ble Express påvirket av et åpent omdirigeringsproblem der feilformaterte URL-er kunne omgå vanlige implementasjoner av tillatelseslister på grunn av hvordan målene for viderekobling ble kodet og deretter tolket. Dataflyten var enkel. Det vanskeligere spørsmålet – og det som avgjorde om feilen eksisterte – var om valideringen fortsatt gjaldt etter transformasjonskjeden.
Codex Security er bygget rundt et enkelt mål: å redusere triagearbeidet ved å avdekke problemer med sterkere bevis. I produktet betyr det å bruke repo-spesifikk kontekst (inkludert en trusselmodell) og å validere problemer med høyt signalnivå i et isolert miljø før de hentes frem.
Når Codex Security støter på en grense som ser ut som «validering» eller «rensning», behandler det ikke det som en avkrysningsboks. Det forsøker å forstå hva koden prøver å garantere – og så prøver det å motbevise den garantien.
I praksis ser det ofte ut som en blanding av:
- Lese den relevante kodebanen med full lagerkontekst, slik en sikkerhetsforsker ville gjort, og se etter avvik mellom intensjon og implementering. Dette inkluderer kommentarer, men modellen tror ikke nødvendigvis på kommentarer, så det å legge til //Halvar sier: dette er ikke en feil over koden din forvirrer den ikke, hvis det faktisk er en feil.
- Redusere problemet til den minste testbare biten (for eksempel transformasjons-pipelinen rundt én enkelt inndata), slik at du kan resonnere om det uten at resten av systemet er i veien. I denne forstand henter Codex Security ut små kodebiter og skriver deretter mikrofuzzere for dem.
- Resonnering om begrensninger på tvers av transformasjoner, i stedet for å behandle hver enkelt kontroll uavhengig av hverandre. Der det er hensiktsmessig, kan dette omfatte å formulere det som et problem om oppfyllelse. Med andre ord gir vi modellen tilgang til et Python-miljø med z3-solver, og den er flink til å bruke det når det trengs, akkurat som et menneske ville ha måttet gjøre når det skal svare på et spesielt komplisert problem med inndatabegrensning. Dette er spesielt nyttig for å se på heltallsoverløp eller lignende feil på ikke-standard arkitekturer.
- Utføre hypoteser i et sandkassebasert valideringsmiljø når det er mulig, for å skille mellom «dette kan være et problem» og «dette er et problem». Det finnes ikke noe bedre bevis enn en fullstendig PoC fra start til slutt med koden kompilert i feilsøkingsmodus.
Dette er den avgjørende endringen: i stedet for å stoppe ved «det finnes en kontroll», går systemet mot «invarianten holder (eller ikke), og her er beviset». Og modellen velger det beste verktøyet til jobben.
En rimelig reaksjon er: hvorfor ikke gjøre begge deler? Start med en SAST-rapport, og bruk deretter agenten til dypere resonnering.
Det finnes tilfeller der forhåndsberegnede funn er nyttige – spesielt for smale, kjente feilklasser. Men for en agent som er utviklet for å oppdage og validere sårbarheter i kontekst, vil et utgangspunkt i en SAST-rapport skape tre forutsigbare feilmoduser.
For det første kan det oppmuntre til for tidlig innsnevring. En funnliste er et kart over hvor et verktøy allerede har søkt. Hvis du tar utgangspunkt i det, kan du påvirke systemet til å bruke uforholdsmessig mye innsats i de samme regionene, bruke de samme abstraksjonene og gå glipp av problemer som ikke passer inn i verktøyets verdensbilde.
For det andre kan det introdusere implisitte vurderinger som er vanskelige å få bukt med. Mange SAST-funn koder antakelser om rensing, validering eller tillitsgrenser. Hvis disse antakelsene er feil – eller bare ufullstendige – kan det å mate dem inn i resonneringsløkken føre til at agenten går fra å «undersøke» til «bekrefte eller avvise», som ikke er det vi vil at agenten skal gjøre.
For det tredje kan det gjøre det vanskeligere å evaluere resonneringssystemet. Hvis pipelinen starter med SAST-utdata, blir det vanskelig å skille det agenten oppdaget gjennom sin egen analyse fra det den har arvet fra et annet verktøy. Dette skillet er viktig hvis du vil måle systemets kapasitet nøyaktig, som er nødvendig for at systemet skal kunne forbedres over tid.
Så vi bygde Codex Security for å begynne der sikkerhetsforskning begynner: fra koden og systemets intensjon, med validering som brukes til å heve konfidensgrensen før vi avbryter et menneske.
SAST-verktøy kan være svært gode på det de er laget for: å håndheve standarder for sikker koding, fange opp enkle kilde til sluk-problemer og oppdage kjente mønstre i stor skala med forutsigbare avveininger. De kan være en viktig del av dybdeforsvaret.
Dette innlegget er smalere: det handler om hvorfor en agent som er utviklet for å resonnere over atferd og validere funn, ikke bør starte arbeidet sitt forankret i en statisk funnliste.
Det er også verdt å nevne en beslektet begrensning ved ren kilde til sluk-tenkning: ikke alle sårbarheter er et dataflytproblem. Mange ekte feil er problemer med tilstand og invariant – omgåelser av arbeidsflyten, autorisasjonsgap og «systemet er i feil tilstand»-feil. For denne typen feil når ikke en kontaminert verdi frem til en enkelt «farlig sluk». Risikoen ligger i det programmet antar alltid vil være sant.
Vi forventer at økosystemet for sikkerhetsverktøy vil bli stadig bedre: statisk analyse, fuzzing, kjøretidsbeskyttelse og agentiske arbeidsflyter vil alle ha en rolle å spille.
Det vi ønsker at Codex Security skal være god på, er den delen som koster sikkerhetsteam mest: å gjøre «dette ser mistenkelig ut» om til «dette er ekte, slik feiler det, og her er en løsning som samsvarer med systemets intensjon.»
Hvis du vil finne ut mer om hvordan Codex Security skanner lagre, validerer funn og foreslår rettelser, kan du se dokumentasjonen vår(åpnes i et nytt vindu).
