Durant dècades, les proves estàtiques de seguretat d'aplicacions (SAST) han estat una de les maneres més eficaces amb què els equips de seguretat escalen la revisió de codi.
Però quan vam crear Codex Security, vam prendre una decisió de disseny deliberada: no vam començar important un informe d'anàlisi estàtica i demanant a l'agent que el triés. Vam dissenyar el sistema perquè comencés pel mateix repositori —la seva arquitectura, els límits de confiança i el comportament previst— i perquè validés allò que trobés abans de demanar a una persona que hi dediqués temps.
La raó és senzilla: les vulnerabilitats més difícils normalment no són problemes de flux de dades. Es produeixen quan el codi sembla aplicar una comprovació de seguretat, però aquesta comprovació en realitat no garanteix la propietat de la qual depèn el sistema. Dit d'una altra manera, el repte no és només seguir com es mouen les dades per un programa, sinó determinar si les defenses del codi realment funcionen.
Sovint es presenta el SAST com una canonada neta: identificar una font d'entrada no fiable, seguir les dades pel programa i marcar els casos en què aquestes dades arriben a un punt sensible sense sanejament. És un model elegant i cobreix molts errors reals.
A la pràctica, el SAST ha de fer aproximacions per continuar sent tractable a escala, especialment en bases de codi reals amb indirecció, despatx dinàmic, callbacks, reflexió i fluxos de control molt dependents del framework. Aquestes aproximacions no són cap crítica al SAST; són la realitat d'intentar raonar sobre codi sense executar-lo.
Això, per si sol, no és el motiu pel qual Codex Security no comença amb un informe SAST.
La qüestió més profunda és què passa després que traces amb èxit una font fins a un punt de destí sensible.
Fins i tot quan l'anàlisi estàtica traça correctament una entrada a través de múltiples funcions i capes, encara ha de respondre la pregunta que realment determina si existeix una vulnerabilitat:
Prenem un patró habitual: el codi crida alguna cosa com sanitize_html() abans de renderitzar contingut no fiable. Un analitzador estàtic pot veure que el sanejador s'ha executat. El que normalment no pot determinar és si aquest sanejador és realment suficient per al context de renderització concret, el motor de plantilles, el comportament de codificació i les transformacions posteriors implicades.
Aquí és on les coses es compliquen. El problema no és només si les dades arriben a un punt sensible. És si les comprovacions del codi realment restringeixen el valor de la manera que el sistema assumeix que ho fan.
Dit d'una altra manera: hi ha una gran diferència entre «el codi crida un sanejador» i «el sistema és segur».
Aquest és un patró que apareix constantment en sistemes reals.
Una aplicació web rep una càrrega JSON, n'extreu un redirect_url, el valida amb una expressió regular de llista permesa, el descodifica com a URL i passa el resultat a un gestor de redirecció.
Un informe clàssic de font a destí sensible pot descriure el flux:
entrada no fiable → comprovació regex → descodificació d'URL → redirecció
Però la pregunta real no és si la comprovació existeix. És si aquesta comprovació continua restringint el valor després de les transformacions que venen a continuació.
Si la regex s'executa abans de descodificar, realment restringeix la URL descodificada de la manera que l'interpreta el gestor de redirecció?
Respondre això implica raonar sobre tota la cadena de transformació: què permet la regex, com es comporten la descodificació i la normalització, com tracta l'anàlisi d'URL els casos límit i com resol la lògica de redirecció els esquemes i les autoritats.
Moltes de les vulnerabilitats que importen a la pràctica tenen aquest aspecte: errors en l'ordre de les operacions, normalització parcial, ambigüitats d'anàlisi i desajustos entre la validació i la interpretació. El flux de dades és visible. La feblesa és en com les restriccions es propaguen —o no es propaguen— per la cadena de transformació.
Això no és només un patró teòric. A CVE-2024-29041(s'obre en una finestra nova), Express es va veure afectat per un problema de redirecció oberta en què URL mal formades podien esquivar implementacions habituals de llistes permeses a causa de com es codificaven i després s'interpretaven els objectius de redirecció. El flux de dades era senzill. La pregunta més difícil —i la que determinava si l'error existia— era si la validació continuava sent vàlida després de la cadena de transformació.
Codex Security s'ha construït al voltant d'un objectiu senzill: reduir el triatge destacant problemes amb proves més sòlides. En el producte, això significa utilitzar context específic del repositori (inclòs un model d'amenaces) i validar els problemes d'alt senyal en un entorn aïllat abans de mostrar-los.
Quan Codex Security troba un límit que sembla «validació» o «sanejament», no ho tracta com una casella per marcar. Intenta entendre què vol garantir el codi i, després, intenta refutar aquesta garantia.
A la pràctica, això acostuma a semblar una combinació de:
- Llegir la ruta de codi rellevant amb el context complet del repositori, com ho faria un investigador de seguretat, i buscar desajustos entre la intenció i la implementació. Això inclou els comentaris, però el model no necessàriament es creu els comentaris, així que afegir //Halvar says: this is not a bug damunt del teu codi no el confon si realment hi ha un error.
- Reduir el problema a la porció més petita que es pugui provar (per exemple, la canonada de transformació al voltant d'una sola entrada), de manera que es pugui raonar-hi sense que la resta del sistema faci nosa. En aquest sentit, Codex Security extreu petits fragments de codi i després hi escriu microfuzzers.
- Raonar sobre les restriccions al llarg de les transformacions, en lloc de tractar cada comprovació de manera independent. Quan escau, això pot incloure la formalització com una qüestió de satisfactibilitat. Dit d'una altra manera, donem al model accés a un entorn Python amb z3-solver i és bo utilitzant-lo quan cal, igual que hauria de fer una persona en respondre un problema especialment complicat de restriccions d'entrada. Això és especialment útil per analitzar desbordaments d'enters o errors semblants en arquitectures no estàndard.
- Executar hipòtesis en un entorn de validació aïllat quan sigui possible, per distingir entre «això podria ser un problema» i «això és un problema». No hi ha millor prova que una PoC completa de cap a cap amb el codi compilat en mode de depuració.
Aquest és el canvi clau: en lloc d'aturar-se a «hi ha una comprovació», el sistema avança cap a «l'invariant es compleix (o no), i aquí hi ha la prova». I el model tria la millor eina per a aquesta feina.
Una reacció raonable és: per què no fer totes dues coses? Començar amb un informe SAST i després fer servir l'agent per raonar més a fons.
Hi ha casos en què les troballes precalculades són útils, especialment per a classes d'errors concretes i acotades. Però, per a un agent dissenyat per descobrir i validar vulnerabilitats en context, començar a partir d'un informe SAST crea tres modes de fallada previsibles.
Primer, pot afavorir un enfocament prematurament estret. Una llista de troballes és un mapa d'on una eina ja ha mirat. Si la tractes com a punt de partida, pots esbiaixar el sistema perquè dediqui un esforç desproporcionat a les mateixes zones, fent servir les mateixes abstraccions, i perdi classes de problemes que no encaixen amb la visió del món de l'eina.
Segon, pot introduir judicis implícits difícils de desfer. Moltes troballes de SAST codifiquen suposicions sobre sanejament, validació o límits de confiança. Si aquestes suposicions són errònies —o simplement incompletes—, introduir-les en el bucle de raonament pot fer passar l'agent de «investiga» a «confirma o descarta», que no és el que volem que faci.
Tercer, pot fer més difícil avaluar el sistema de raonament. Si la canonada comença amb la sortida de SAST, es fa difícil separar què ha descobert l'agent amb la seva pròpia anàlisi del que ha heretat d'una altra eina. Aquesta separació és important si vols mesurar amb precisió les capacitats del sistema, cosa necessària perquè el sistema millori amb el temps.
Per això vam construir Codex Security perquè comenci allà on comença la investigació de seguretat: a partir del codi i de la intenció del sistema, amb validació per elevar el llindar de confiança abans d'interrompre una persona.
Les eines SAST poden ser excel·lents en allò per a què estan dissenyades: aplicar estàndards de codificació segura, detectar problemes senzills de font a destí sensible i trobar patrons coneguts a escala amb compromisos previsibles. Poden ser una part sòlida d'una defensa en profunditat.
Aquesta publicació és més acotada: tracta de per què un agent dissenyat per raonar sobre el comportament i validar troballes no hauria de començar la seva feina ancorat a una llista estàtica de resultats.
També val la pena destacar una limitació relacionada del pensament purament de font a destí sensible: no tota vulnerabilitat és un problema de flux de dades. Moltes fallades reals són problemes d'estat i d'invariants: salts del flux de treball, buits d'autorització i errors del tipus «el sistema és en un estat incorrecte». En aquests tipus d'errors, un valor contaminat no arriba a un únic «punt perillós». El risc és en allò que el programa assumeix que sempre serà cert.
Esperem que l'ecosistema d'eines de seguretat continuï millorant: l'anàlisi estàtica, el fuzzing, les proteccions en temps d'execució i els fluxos de treball agentics hi tindran tots un paper.
El que volem que Codex Security faci bé és la part que té més cost per als equips de seguretat: convertir «això sembla sospitós» en «això és real, així és com falla i aquí tens una solució que s'ajusta a la intenció del sistema».
Si vols saber-ne més sobre com Codex Security escaneja repositoris, valida troballes i proposa solucions, consulta la nostra documentació(s'obre en una finestra nova).
