Codex Security au-delà de SAST, la thèse d’OpenAI expliquée aux entreprises

Il y a un moment dans presque toutes les équipes de sécurité où le travail cesse de ressembler à un exercice technique et devient un problème économique. Cela ne se produit pas lorsqu’une vulnérabilité critique apparaît. Cela arrive avant, lorsque l’équipe est inondée de rapports qui semblent plausibles, mais qui nécessitent des heures de lecture, de vérification et de contextualisation avant de comprendre s’ils sont réellement dangereux. C’est dans cette friction quotidienne qu’il faut lire le message d’OpenAI sur la sécurité du Codex : la cible n’est pas le SAST lui-même, mais l’idée que la sécurité du code ne peut partir que d’une liste statique de résultats.

La précision est importante, car le débat se prête facilement à une lecture caricaturale. OpenAI ne dit pas que SAST est inutile, ni que l’analyse statique devrait disparaître des pipelines. Il dit quelque chose de plus subtil : si l’objectif est de trouver des vulnérabilités complexes, de réduire le coût du tri et de proposer des correctifs plus crédibles, alors ancrer l’ensemble du processus dans un rapport SAST peut devenir une limitation.

En d’autres termes, il ne s’agit pas seulement d’identifier un flux suspect entre entrée et point sensible du code, mais de comprendre si le comportement du système respecte réellement l’invariant de sécurité que le logiciel semble vouloir garantir.

Qu’est-ce que SAST et pourquoi le sujet émerge-t-il maintenant

Il convient de préciser le terme qu’OpenAI met au centre de sa thèse. SAST signifie « static application security testing » : il s’agit de l’analyse du code sans exécuter l’application, réalisée pour identifier les modèles de risque, les flux de données suspects, l’utilisation inappropriée d’API sensibles et les violations des règles de codage sécurisées.

Il est devenu l’un des piliers de DevSecOps car il apporte un retour d’information très tôt dans le cycle de développement et s’intègre bien dans les pipelines CI/CD, où il est important de disposer de contrôles larges, reproductibles et automatisables.

Le sujet se pose maintenant car le contexte évolue. Les bases de code modernes comportent davantage de couches et dépendent de frameworks, de bibliothèques et de chaînes de transformation qui rendent moins immédiate la compréhension si un contrôle logique continue de s’appliquer après l’analyse, la normalisation et le décodage. Dans le même temps, les équipes de sécurité souffrent du coût du tri : recevoir de nombreuses alertes ne suffit pas s’il n’existe pas de contexte permettant de distinguer rapidement ce qui est réellement exploitable.

Avec l’arrivée d’agents capables de lire des référentiels, de générer des tests et de valider des hypothèses, le marché place la barre plus haut et demande non seulement des rapports, mais des preuves. C’est dans cette tension, plutôt que dans une simple dispute terminologique, qu’il convient de situer le blog OpenAI.

SAST : ce que dit OpenAI

Pour comprendre la portée de cette position, nous devons examiner comment OpenAI présente la sécurité du Codex. Le produit, annoncé en avant-première expérimentale le 6 mars 2026, est décrit comme un agent de sécurité des applications qui crée un contexte sur le référentiel, génère un modèle de menace spécifique, recherche les vulnérabilités, tente de les valider dans un environnement isolé et, en cas de succès, propose également un correctif conforme à l’intention du système.

Quelques jours plus tard, le 16 mars, OpenAI publiait le post «Pourquoi la sécurité du Codex n’inclut pas de rapport SAST» pour clarifier le choix de ne pas démarrer l’agent à partir d’un état statique préexistant.

Dans la documentation officielle, l’entreprise réitère deux aspects décisifs. La première est que Codex Security a été créé pour valider les signaux avant d’interrompre un humain, en joignant des preuves de reproduction, des journaux et des étapes de vérification lorsque cela est possible.

La seconde est que le produit ne remplace ni le SAST ni la révision manuelle : il les soutient par un raisonnement sémantique et une auto-validation. Ce point est très important, car il démystifie toute interprétation idéologique. OpenAI ne proclame pas la fin des outils statiques ; tente de redéfinir où s’arrêtent ces outils et où commence le travail d’un agent orienté comportement.

Parce que le SAST seul ne suffit plus

La thèse d’OpenAI s’articule autour d’un constat simple : de nombreuses vulnérabilités pertinentes ne proviennent pas du fait qu’une entrée non filtrée arrive à une fonction sensible, mais du fait qu’un contrôle apparemment correct ne garantit pas réellement la propriété de sécurité sur laquelle repose le système. C’est le passage de la logique du simple flux de données à la logique des invariants.

Le propos est moins abstrait qu’il n’y paraît. Un système peut valider une URL avec une regex, la décoder plus tard, puis l’utiliser dans une redirection. Dans ce cas, le contrôle des flux existe. Mais la question qui compte n’est pas de savoir si le contrôle a été appelé : c’est de savoir s’il continue à tenir après décodage, analyse, normalisation et interprétation par le framework.

Ce n’est pas une nuance académique. C’est exactement le genre de chaîne où émergent des contournements, des ambiguïtés d’analyse, des erreurs dans l’ordre des opérations et des différences entre l’intention du programmeur et le comportement réel du logiciel.

La référence d’OpenAI à CVE-2024-29041 dans Exprimer C’est exactement à ça que ça sert. Dans ce cas, le problème n’était pas l’absence d’un liste vertemais le fait que les URL mal formées pourraient contourner les implémentations courantes de liste verte en raison de la façon dont les cibles de réorienter ils ont été codifiés puis interprétés. Le flux de données était clair. La partie difficile consistait à déterminer si la validation continuait à lier les données après la transformation suivante.

Parce que la thèse d’OpenAI a un fondement

Sur ce terrain, la position d’OpenAI est difficile à liquider. L’OWASP a longtemps rappelé que les outils d’analyse de code ont des limites structurelles : ils couvrent bien certaines classes de défauts, mais sont moins efficaces sur des problèmes d’authentification, de contrôle d’accès, de configuration et, plus généralement, sur tout ce qui ne peut être bien décrit comme un simple flux de données.

Aussi le Guide de révision du code de l’OWASP lui-même observe que l’idéal d’un outil capable de trouver automatiquement des défauts avec peu de faux positifs est encore loin de l’état de l’art, et que ces outils fonctionnent souvent comme une aide à l’analyste plutôt que comme un substitut à son raisonnement.

C’est là que Codex Security tente de changer de perspective. Dans le post, OpenAI explique que lorsqu’il rencontre une étape qui ressemble à une validation ou à une désinfection, l’agent ne la traite pas comme une case à cocher. Déterminez quelle garantie le code essaie d’offrir, puis essayez de le simuler. En pratique, cela signifie lire le chemin du code avec le contexte complet du référentiel, isoler les parties testables minimales, utiliser micro-fuzzing ou même des outils formels si nécessaire, et exécutez des hypothèses en bac à sable pour faire la distinction entre « cela pourrait être un problème » et « ceci est un problème ».

Cette approche a également une valeur managériale, et pas seulement technique. OpenAI semble avoir réalisé que le plus gros coût en matière de sécurité logicielle n’est plus simplement la découverte d’éventuels bugs, mais la gestion de la masse de signaux faibles générés par les outils.

Dans de nombreuses organisations, le goulot d’étranglement n’est pas le manque de visibilité, mais plutôt le fait d’en voir trop et de ne pas accorder une priorité suffisante. Lu ainsi, le choix de partir du référentiel et non d’un rapport SAST est aussi un choix économique : réduire le travail de tri avant que le problème n’atteigne la table de l’équipe.

Où la position reste discutable

Ce serait cependant une erreur de transformer cette intuition en un déni définitif du SAST. La première raison est opérationnelle : les outils statiques restent le moyen le plus rapide, le plus reproductible et le plus déterministe d’appliquer des contrôles généralisés à grande échelle. La FAQ de Codex Security indique que le produit complète SAST et que les outils existants continuent d’offrir une couverture large et déterministe. Cette phrase vaut plus que de nombreuses lectures polarisées de blogs. Si OpenAI reconnaît également ce rôle, alors le problème n’est pas la substitution contre la continuité, mais bien la répartition intelligente des tâches.

La deuxième raison concerne l’évolutivité. SAST est né pour être industriel : il fonctionne très tôt, s’exécute souvent et peut être appliqué systématiquement sur de gros volumes de code, même en acceptant des simplifications. Un agent qui lit, raisonne, construit des modèles de menace, tente des validations et produit des preuves a inévitablement tendance à être plus cher. Sans surprise, la documentation de Codex Security indique que les analyses initiales peuvent prendre de plusieurs heures à plusieurs jours sur des référentiels plus importants.

Cela n’invalide pas le modèle, mais cela clarifie où se situe le compromis : plus de profondeur et moins de bruit, oui, mais pas au même coût d’exploitation que les contrôles statiques traditionnels.

La troisième raison est épistémologique. OpenAI critique à juste titre le biais que peut introduire un rapport SAST lorsqu’il devient la carte initiale de l’enquête. Mais un agent basé sur un modèle introduit à son tour d’autres biais : ceux de la formation, des heuristiques inférentielles, de la qualité du modèle de menace généré et de l’environnement de validation disponible.

Si le risque du SAST est de trop se focaliser sur ce qui est codifié dans les règles, le risque d’un agent est de construire des récits causals convaincants mais pas toujours complets. L’autovalidation place beaucoup la barre, mais n’élimine pas la question de la confiance : elle la déplace du moteur de règles vers le système qui décide où chercher, comment formuler l’hypothèse et quand la considérer comme suffisamment confirmée.

Enfin, il y a une question de gouvernance. Un outil statique traditionnel, aussi imparfait soit-il, est plus facile à intégrer dans des politiques, des listes de contrôle, des pistes d’audit et des processus réglementés : règles connues, résultats standard, intégrations matures. Un agent qui génère des modèles de menaces, effectue des validations adaptatives et propose des correctifs est potentiellement plus puissant, mais aussi plus difficile à intégrer dans les processus de contrôle.

Pour de nombreuses entreprises, la question n’est donc pas seulement « est-ce que ça marche mieux ?« , mais aussi « Comment le gouverner, comment le mesurer, comment le rendre vérifiable dans le temps ?».

Une évaluation globale

La lecture la plus équilibrée à mon avis est la suivante : OpenAI a raison de critiquer l’idée selon laquelle la sécurité du code peut se limiter à la logique d’un simple flux de données. Il a également raison de dire que de nombreuses vulnérabilités cruciales sont des problèmes de sémantique, d’état et d’invariants, et que les résoudre nécessite une analyse plus proche de celle d’une analyse plus approfondie. chercheurs en sécurité que celui d’un simple classificateur de modèles.

Mais cela n’aurait aucun sens de convertir cette intuition en une thèse absolue contre SAST, car SAST continue de bien faire ce pour quoi il est né : standardiser, couvrir, automatiser et sécuriser la base.

La vraie nouvelle, s’il y en a, est autre chose. Avec Codex Security, OpenAI tente de redéfinir la valeur de la sécurité des applications à l’ère des agents IA. Ne plus simplement voir plus de choses, mais mieux voir celles qui méritent attention. Il ne s’agit plus seulement de rapporter, mais de démontrer. Ne plus produire de listes de suspects, mais se rapprocher d’un résultat qui a déjà le format opérationnel d’une décision : ceci est réel, tel est le contexte, tel est la preuve, tel est la correction la plus cohérente.

SAST n’est pas mort

Si cette approche tient ses promesses, nous ne verrons pas la fin du SAST, mais son repositionnement au sein du processus. Des outils statiques superviseront une couverture continue et des contrôles reproductibles ; Les systèmes agentiques prendront en charge des cas ambigus, coûteux et à forte intensité contextuelle. Au milieu restera l’élément décisif : le jugement humain. Non pas parce que les outils manquent, mais parce que dans les vulnérabilités les plus graves, le problème n’est jamais simplement de trouver une mauvaise ligne de code.

Il s’agit de comprendre quelle propriété du système était censée être protégée, quand elle a cessé de l’être et quel correctif rétablit réellement cet équilibre.

Points à retenir

• Le blog OpenAI ne déclare pas SAST mort : il conteste SAST comme point de départ obligatoire pour un agent qui doit découvrir et valider des vulnérabilités complexes.
• Le point fort de la thèse est le passage du contrôle de flux au contrôle invariant : il ne suffit pas que la validation existe, il faut comprendre si elle résiste après analyse, décodage et transformations.
• Le point faible est opérationnel : plus de raisonnement et plus de validation signifient des délais, des coûts et des problèmes de gouvernance plus élevés par rapport aux contrôles statiques traditionnels.
• Le scénario le plus réaliste est hybride : SAST pour la couverture et la discipline de base, agents d’IA pour l’analyse sémantique, la priorisation et la confirmation des vulnérabilités à fort impact.