Passer au contenu principal

La fenêtre d'action du défenseur se referme

Les défenseurs ont une longueur d’avance, mais nous devons agir

L'approche d'OpenAI

La Defense Factory

Bâtir une défense continue

Les défenses traditionnelles en cybersécurité ne suffisent plus à elles seules

Les agents peuvent désormais mener des cyberopérations prolongées en faisant un usage malveillant de modèles à poids ouverts de plus en plus accessibles. En réponse, chez OpenAI, nous construisons une Defense Factory. Une opération de défense automatisée visant à détecter, valider et corriger les vulnérabilités en continu.

Des équipes chez Cloudflare(ouverture dans une nouvelle fenêtre), Ramp(ouverture dans une nouvelle fenêtre) et Google(ouverture dans une nouvelle fenêtre) explorent également cette approche. Ici, nous partageons l'architecture et les processus de notre propre Defense Factory, ainsi que les enseignements tirés de sa création.

Les derniers modèles de pointe détectent des vulnérabilités déjà présentes en production

Lors d'un récent sprint de sécurité, nous avons utilisé nos derniers modèles de cybersécurité pour détecter, valider et corriger des vulnérabilités dans l'ensemble d'OpenAI. Nous avons mobilisé plus de 250 personnes et abordé ce travail avec l'urgence d'une réponse à un incident.

Cinq semaines complètes de rapports sélectionnés de constats de niveau Urgent et Élevé marqués comme Terminés ou Résolus, par rapport à la semaine de pic. L'achèvement enregistré ne constitue pas une preuve de remédiation déployée et vérifiée de manière indépendante.Remédiations P0/P1Remédiations P0/P154631491535Semaines

Les agents peuvent désormais enchaîner des exploits

Les agents conservent ce qu'ils apprennent d'une session à l'autre afin de développer une compréhension détaillée d'un système et d'établir des liens entre les faiblesses. Les attaques complexes qui étaient auparavant irréalisables peuvent désormais être menées de manière autonome.

Exemple de chaîne d’attaqueUn chemin relie des nœuds successifs à travers un labyrinthe. Chaque nœud atteint active le suivant, et les étapes précédentes restent connectées. Il s'agit d'une illustration conceptuelle, et non de la reconstitution d'un incident.

Les groupes d'agents démultiplient l'ampleur des attaques

Les agents qui fonctionnent pendant de longues périodes et sont déployés en flottes peuvent exploiter des faiblesses à plus grande échelle et bien avant qu'une réponse de sécurité avec intervention humaine ne puisse identifier ces mêmes vulnérabilités et appliquer les correctifs nécessaires.

Les modèles et les agents convergent vers la rapiditéLes modèles largement disponibles et les agents de longue durée sont connectés en haut. Deux traces descendent dans l'exploitation à vitesse machine, qui se remplit de haut en bas à mesure qu'elles arrivent. Les libellés restent visibles en permanence.

Les défenseurs ont une longueur d’avance, mais nous devons agir

Les défenseurs bénéficient de deux avantages structurels. Ils peuvent donner aux agents un accès direct à leur code et utiliser des modèles de pointe pour prendre une longueur d’avance sur les attaquants qui font un usage malveillant de modèles à poids ouverts largement accessibles.

Capacité cybernétique

Atteindre le niveau de pointe, puis suivre le rythmeLa capacité en cybersécurité augmente vers le haut  ; le temps progresse vers la droite. Les capacités des modèles de pointe et des modèles largement diffusés continuent de s'accélérer. La capacité défensive reste stable jusqu'à la mise en œuvre de la défense continue. Elle augmente ensuite selon une courbe en S : progression graduelle, amélioration rapide, puis jonction fluide avec les modèles de pointe. Les courbes de la défense et des modèles de pointe se rejoignent, puis suivent une même trajectoire ascendante. La zone bleue entre la défense déployée et la capacité largement diffusée correspond à la fenêtre des défenseurs. Suivre le rythme exige un travail continu. Il s'agit de trajectoires données à titre d'illustration, et non de résultats mesurés ni de prévisions.

Temps

  • De pointe
  • Capacité des défenseurs
  • Largement diffusé

Mettre en œuvre une défense continue

Fenêtre d’action du défenseur

Cette avance constitue la fenêtre d’action du défenseur.

L'usine de défense

Une Defense Factory est une opération continue axée sur les agents, destinée à détecter et corriger les vulnérabilités. Elle aide les défenseurs à suivre le rythme tandis que les attaquants font un usage malveillant de modèles à poids ouverts toujours plus performants pour accélérer leurs opérations. Les agents utilisent les outils de sécurité et d’ingénierie existants, les compétences réutilisables définissent les flux de travail qu’ils suivent et des espaces de travail informatiques isolés et reproductibles leur permettent d’examiner les constats et de préparer des correctifs testés en vue de leur examen. Les équipes automatisent progressivement une part croissante du processus, réduisant les transferts et raccourcissant le délai entre la découverte et la correction.

Sécurité traditionnelle

Vos outils existants, idéalement accessibles aux agents via des MCP, des CLI ou des API.

Contrôle du code source

GitHub · GitLab

Outils de sécurité

Snyk · Semgrep · Tenable

Problèmes & flux de travail

Jira · Linear · ServiceNow

Usine de défense

Le lien entre vos outils existants, permettant aux agents de détecter et de corriger les vulnérabilités de manière proactive dans un flux de travail continu.

Environnement de développement

Environnements isolés et reproductibles · Ona, Cloudflare, Modal

Agents
  • Codex Desktop
  • Codex CLI
  • Codex Security CLI
Compétences de sécurité

Analyse de sécurité · Trier les problèmes détectés · Corriger les problèmes détectés

Compétences personnalisées

Modèles à usage général

Astra · Sol · Terra · Luna

Modèles de sécurité

Daybreak Blue · Daybreak Red

L'architecture de la défense continue

Une Defense Factory doit reproduire les vulnérabilités et vérifier que les correctifs fonctionnent. Cela nécessite des environnements de développement reproductibles et isolés, avec le code, les dépendances et les services appropriés, le tout pris en charge par une orchestration et des contrôles d'accès permettant aux agents de travailler en toute sécurité à grande échelle.

Plan de contrôle

Met à l'échelle les environnements d'exécution et centralise les politiques et les secrets.

Plan de données

Environnements isolés et éphémères pour valider les constats.

Conteneurs

Systèmes pour développeurs

Fournissez aux agents les outils dont ils ont besoin pour fonctionner.

État et flux de travail

Suivez ce que vous protégez, ce que les agents détectent et ce qui doit être corrigé.

Sécurité et audit

Surveillez les agents qui exécutent des modèles de cybersécurité afin de contribuer à garantir une exécution sûre et un accès sécurisé au contexte sensible et aux données sensibles.

Dans le réseau privé, les systèmes des développeurs et les magasins d'état se trouvent aux côtés d'un plan de contrôle et d'un plan de données. Le plan de contrôle contient l'orchestration des charges de travail, l'application des politiques et un proxy d'identifiants. Le plan de données contient des environnements de développement avec des conteneurs de développement, des identités d'environnement et la surveillance des hôtes. Chaque conteneur de développement contient un harnais d'agent, des compétences et l'application. La sécurité et l'audit assurent une supervision à l'échelle du système grâce à l'activité des hôtes, à la sécurité de l'infrastructure et à l'audit des agents. Les encadrés indiquent les composants et les limites.

Comment Defense Factory renforce la sécurité traditionnelle

Faites défiler horizontalement pour voir ce qu'ajoute la Factory.

TravailObstacle courantCe que Defense Factory vous apporte
DécouverteLes constatations sont en attente d'investigation.
Les résultats déclenchent des investigations automatiques.
TriLes doublons brouillent les priorités.
Doublons fusionnés. Exploitabilité testée.
PropriétéLes constats sont en attente d'un propriétaire.
Chaque constat dispose d'un responsable vérifié.
RemédiationLes ingénieurs répètent les investigations.
Les correctifs testés parviennent aux relecteurs accompagnés de preuves.
VérificationLes correctifs fusionnés restent non vérifiés.
Les correctifs déployés sont testés à nouveau de manière indépendante.

Comment un sprint de sécurité à l'échelle d'OpenAI s'est transformé en usine de défense

À mesure que les nouvelles capacités des modèles nous ont permis d'examiner nos systèmes plus en profondeur, nous avons accéléré le rythme et accru l'ampleur de nos travaux de sécurité. Nous avons déclenché une alerte rouge interne et réuni les équipes Security, Applied et Research dans le cadre d'un sprint coordonné couvrant des centaines de systèmes.

personnes mobilisées
250+
Zones desservies
100+

« Nous renforçons nos défenses avec l'urgence d'un incident. C'est un effort collectif qui prime sur tout, à l'exception des activités opérationnelles critiques. Nous maintiendrons ce même sentiment d'urgence au-delà du sprint, tout en continuant à tester et à renforcer nos défenses. »

— Thibault Sottiaux, responsable des produits Core et de la plateforme, OpenAI

Le sprint a été le point de départ de notre Usine de défense. Nous œuvrons à la mise en place d'une boucle défensive continue afin de cartographier nos systèmes, détecter et valider les vulnérabilités, attribuer des responsables, vérifier les correctifs et améliorer le système à chaque exécution.

La boucle défensive

  1. 01

    Inventaire

    Cartographier, lier, mettre à jour

  2. 02

    Découverte

    Scanner, analyser, importer

  3. 03

    Validation dynamique

    Reproduire, tester, confirmer

  4. 04

    Attribution d'un responsable

    Identifier, orienter, assurer le suivi

  5. 05

    Correction vérifiée

    corriger, déployer, vérifier

Apprendre, s’adapter et gagner en autonomie

SECURITY.mdContexte partagé

SECURITY.md représente un contexte système partagé, et non une autre étape de la boucle. L'inventaire, la découverte, la validation dynamique, l'attribution des responsabilités et la remédiation vérifiée exploitent chacune le contexte existant et y ajoutent ce qu'elles apprennent. Chaque itération réutilise la cartographie du système, l'attribution des responsabilités, les éléments probants issus de l'investigation et les vérifications déjà établis, afin que les itérations suivantes puissent se concentrer sur les changements et les risques non résolus au lieu de repartir de zéro. Des personnes examinent les changements importants et vérifient de manière indépendante les correctifs déployés. La pulsation illustre une contribution contextuelle, et non une progression mesurée ou des économies mesurées.

Ce que nous avons appris en construisant la boucle défensive

Les boucles défensives nécessitent les bons environnements de développement

Les environnements de développement reproductibles sont le fondement d'une boucle défensive autonome. Les agents ont besoin d'environnements isolés pouvant être provisionnés automatiquement à grande échelle, avec les services, les dépendances et la configuration nécessaires pour reproduire les vulnérabilités et tester les correctifs. Ces environnements doivent être éphémères, nouvellement créés pour chaque exécution et supprimés ensuite avec leur état, afin qu'une exécution ne contamine pas la suivante.

L'autonomie doit être construite progressivement à partir d'étapes manuelles

Nous avons commencé par de petits lots et une validation humaine, puis nous avons supprimé les étapes manuelles répétitives à mesure que les résultats inspiraient confiance. Nous avons augmenté la quantité de travail que les agents pouvaient accomplir, indépendamment de ce qu’ils étaient autorisés à modifier. Les personnes se sont davantage concentrées sur la définition de limites, la gestion des exceptions et la vérification des résultats, à mesure que les agents prenaient en charge une plus grande part des tâches routinières.

  • Systèmes inventoriés au lancement des correctifs

    Nous avons commencé par cartographier nos systèmes. Codex a aidé à constituer l'inventaire pendant que nous regroupions les constats existants dans un backlog partagé. L'identification initiale de l'équipe responsable dépendait encore de la capacité des personnes à trouver la bonne équipe. Nous avons transformé les informations sur les services et les responsabilités en données d'entrée réutilisables afin que les agents puissent étiqueter et acheminer des lots de problèmes, les cas ambigus étant traités par des personnes. Cela a fait passer notre taux d'affectations de responsabilité acceptées à 90,6 %. Dans En parallèle, les équipes se sont attaquées aux problèmes urgents avant même que l'inventaire et le modèle d'attribution des responsabilités ne soient finalisés. Nous avons résolu 53 problèmes urgents ou de priorité élevée dans l'ensemble de nos systèmes dès le premier jour.

    Attributions acceptées après routage
    90,6 %

  • Triage d'agent conçu et affiné

    Codex a évalué des lots de constats à l'aune d'une grille de gravité et a ajouté le contexte relatif au service et au responsable. Les libellés de gravité initiaux étaient trop généraux, et les classifications variaient en fonction des consignes reçues par les agents. Nous avons versionné la grille d'évaluation et les prompts, ajouté des évaluations reproductibles et consigné les priorités et le raisonnement attendus des évaluateurs. Humain Des contrôles ponctuels ont permis d'affiner les priorités et de détecter les signalements insuffisants ou en double. Nous avons également suspendu le routage jusqu'à ce que la déduplication s'améliore, en passant d'un petit lot examiné à des exécutions répétées et en identifiant 37 % des constats comme des problèmes en double.

    de constats identifiés comme doublons
    37 %

  • Rendre la validation à l'exécution répétable

    La création d'environnements isolés permettant aux agents d'exécuter du code, d'évaluer la gravité et de filtrer les faux positifs a constitué une étape clé pour distinguer le signal du bruit. Mais la configuration de l'environnement est devenue une contrainte pour la validation ; nous avons donc commencé par certains services sélectionnés que nous pouvions exécuter de manière répétée. Nous avons traité les dépendances manquantes et les écarts de configuration afin de pouvoir distinguer un constat non reproductible d'un test qui ne pouvait pas s'exécuter correctement. Grâce à ces améliorations, 19,5 % des constats ont été reproduits à l'exécution, et le taux de faux positifs après validation dynamique était de 0,81 %.

    taux de faux positifs après validation dynamique
    0,81 %

  • Mise en place de l'automatisation des correctifs et création de flux de travail réutilisables

    La remédiation était basée à 100 % sur Codex, avec des agents qui généraient des correctifs pendant que nous améliorions le routage et les priorités. Nous avons fourni aux agents des environnements de développement reproductibles pour reproduire les problèmes et tester les correctifs proposés sur des services en cours d'exécution, en vérifiant à la fois le correctif de sécurité et ses effets sur le comportement normal. Nous avons consigné les enseignements dans des fichiers SECURITY.md et des compétences réutilisables, et avons étendu l'analyse et le triage effectués par des agents ainsi que les vérifications automatisées des correctifs. Suivi les contrôles ont mis en évidence un écart entre les patchs fusionnés et les correctifs déployés sur l'ensemble du parc. Après un essai pilote limité, nous avons étendu la vérification et ajouté des commentaires sur les corrections confirmées, tout en laissant la réouverture automatique désactivée le temps de déterminer comment tenir compte des délais de déploiement.

    taux de correctifs annulés
    0,53 %

Article de blog technique à venir

L'approche d'OpenAI en matière de compétences et de workflows de sécurité

Inventaire

Les agents rapprochent les enregistrements cloud, la configuration de déploiement et les données de propriété des services pour constituer un inventaire des actifs. Ils associent les points de terminaison exposés au code et aux responsables, tout en conservant les preuves et les lacunes afin que la découverte commence avec un périmètre plus clair.

Faites défiler horizontalement pour explorer le diagramme.

Les enregistrements cloud et d'actifs, la configuration source et de déploiement, ainsi que les données de service et de propriétaire sont réunis dans l'environnement de développement reproductible. Codex utilise une compétence proposée « Créer et mettre à jour l'inventaire » et la référence d'attribution de service existante pour produire un inventaire des actifs. Le même inventaire constitue la première entrée de Discovery. Les écritures d'inventaire et la planification des actualisations doivent être configurées par le workflow appelant.

Entrées

Flux de travail agentique

Environnement de développement reproductible

Sorties

  • Plateformes tierces
  • Artefacts
  • Produits OpenAI
  • Skills / plugins
  • Environnements

Faites de la défense continue une priorité

Faites un briefing à votre équipe, commencez par un flux de travail, puis progressez par étapes vers une usine de défense. Nous continuerons à publier ce que nous apprenons chez OpenAI, ainsi que des flux de travail pratiques, des outils et des recommandations.

  1. Informez votre équipe

    Utilisez le support de présentation pour justifier la mise en place d'une Defense Factory, définir l'orientation et convenir d'un premier flux de travail.

    Obtenir la présentation de briefing(ouverture dans une nouvelle fenêtre)

  2. Demander l'accès aux modèles cyber via Daybreak

    Faites une demande auprès de Daybreak pour accéder aux modèles cyber avancés d'OpenAI dans le cadre de travaux défensifs autorisés.

    Demander l'accès à Daybreak(ouverture dans une nouvelle fenêtre)

  3. Exécuter un workflow

    Utilisez les compétences du plugin Codex Security pour rechercher des vulnérabilités, valider les résultats et préparer des correctifs.

    Essayer Codex Security(ouverture dans une nouvelle fenêtre)

Vous êtes déjà client d'OpenAI ? Discutez de votre architecture avec l'équipe en charge de votre compte.

Pour aller plus loin

L'incident Hugging Face

La conférence Black Hat à l'origine de la reconstitution de l'incident de Hugging Face.

(ouverture dans une nouvelle fenêtre)
  1. Analyse d'incidentIntrusion de l'agent : la chronologie techniqueLe compte rendu d'analyse forensique de Hugging Face sur l'intrusion, incluant le chemin d'attaque, l'enquête et les changements apportés aux mesures de défense.(ouverture dans une nouvelle fenêtre)
  2. Divulgation d'incidentIncident de sécurité lié à l'évaluation de modèles Hugging FaceCompte rendu par OpenAI de l’incident survenu lors de l’évaluation de modèles, de sa réponse avec Hugging Face et des modifications apportées aux mesures de protection des évaluations.(ouverture dans une nouvelle fenêtre)
  3. Point de vueFenêtre d’action du défenseurPourquoi les défenseurs disposent d'une fenêtre d'action limitée, et comment les organisations peuvent utiliser l'IA pour renforcer leurs cyberdéfenses.(ouverture dans une nouvelle fenêtre)
  4. Mise à jour du programmeÉtendre Daybreak alors que la fenêtre de cyberdéfense se réduitComment Daybreak élargit l'accès aux modèles cyber avancés et aide les défenseurs à les mettre en œuvre avec des garde-fous appropriés.(ouverture dans une nouvelle fenêtre)
  5. DocumentationChatGPT LearnPlugin Codex SecurityUn guide pour installer le plugin Codex Security, analyser un dépôt et examiner les résultats de sécurité.(ouverture dans une nouvelle fenêtre)