Renforcer les capacités des équipes de cyberdéfense avec Daybreak

Lorsque vous traitez une liste de problèmes de sécurité en attente, détecter un nouveau problème potentiel n’est qu’un début. Il faut encore déterminer s’il touche votre logiciel, réunir des éléments probants et intégrer un correctif sûr. La tâche se complique à mesure que le code, les alertes et les rapports de vulnérabilité continuent d’affluer.

Nous avons récemment ajouté de nouvelles façons de mener ce travail avec ChatGPT, Codex Security et la CLI Codex Security open source. Vous pouvez examiner une pull request avant sa fusion, analyser un dépôt ou une liste de vulnérabilités en attente, et ajouter des contrôles récurrents à la CI. Ces capacités font partie d’OpenAI Daybreak, qui réunit des modèles, des outils de sécurité, un accès responsable et l’écosystème de la sécurité au service des équipes de défense approuvées.

D’après les résultats publiés précédemment, Codex Security dans le cloud avait analysé plus de 30 millions de commits dans plus de 30 000 bases de code. Je souhaite ici expliquer à quels besoins répondent les workflows disponibles et comment je choisirais un point de départ. L’objectif reste le même tout au long du processus : étayer les problèmes détectés et produire des correctifs revus, tout en délimitant les accès et en laissant aux personnes la responsabilité des décisions lourdes de conséquences.

Ces workflows sont des suggestions de points de départ, pas un schéma de déploiement universel. Les développeurs doivent les adapter à leur organisation, à leur cas d’usage, à leur profil de risque et à leurs pratiques de traitement des données, puis déterminer la configuration, les mesures de protection et le déploiement adaptés à leur environnement.

Commencez par une investigation dans ChatGPT

Si vous disposez déjà d’un extrait de journal, d’un avis de sécurité ou de la chronologie d’un incident, ChatGPT est un bon point de départ pour en commencer l’analyse. Voici quelques pistes à essayer :

• Examinez un extrait de journal suspect et identifiez les éléments probants qui manquent encore.
• Résumez un avis de vulnérabilité et déterminez ses effets probables sur vos systèmes.
• Reconstituez la chronologie d’un incident ou rédigez une règle de détection.
• Préparez un modèle de menace pour une nouvelle fonctionnalité et comparez les solutions de correction.
• Transformez un constat technique en recommandations pour les équipes d’ingénierie ou la direction.

Vous devrez toujours vérifier les éléments sur lesquels repose l’analyse, respecter les politiques de traitement des données de votre organisation et décider des mesures à prendre. Lorsque la question suivante nécessite d’examiner un dépôt, une pull request, une liste de problèmes de sécurité en attente ou un correctif proposé, c’est le bon moment pour passer à un workflow Codex Security.

Examinez les problèmes de sécurité avant la fusion du code

Codex Security Review intègre une analyse de sécurité ciblée aux pull requests GitHub. C’est donc un point de départ naturel si vous y examinez déjà une modification. Dès que votre espace de travail dispose d’un accès à la préversion de recherche et d’un dépôt connecté, vous pouvez demander une révision en ajoutant ce commentaire :

@codex security review

Si cela correspond au workflow de votre équipe, configurez des révisions automatiques à l’ouverture d’une pull request, après chaque push ou à chaque exécution d’une revue de code Codex déjà en place. Un modèle de menace du dépôt ou d’autres consignes de sécurité fournissent ici un contexte utile : ils aident la révision à tenir compte des actifs de votre application, de ses frontières de confiance et de ses hypothèses.

Codex examine le diff de la pull request ainsi que le contexte pertinent du dépôt. Les problèmes signalés dans la pull request constituent un point de départ ; le rapport de sécurité de la tâche Codex associée indique leur gravité, les éléments probants, les chemins d’attaque, les détails de validation et les recommandations de correction. Prêtez attention au seuil de signalement : les problèmes publiés sur GitHub héritent de la visibilité de la pull request.

Codex Security Review est disponible en préversion de recherche pour les espaces de travail ChatGPT Enterprise, Business, Edu et Pro éligibles disposant d’un dépôt GitHub connecté.

Analysez un dépôt avec Codex Security

Lorsque la question dépasse le cadre d’une seule pull request, le plugin Codex Security peut évaluer un dépôt entier, un composant, une branche, un commit ou des modifications locales. Pour une première évaluation ou une révision de routine, je commencerais par une analyse standard. Une analyse approfondie convient davantage à un système critique ou à un répertoire ciblé, lorsque des analyses plus larges et répétées justifient d’y consacrer davantage de temps et de ressources de calcul.

L’atelier de sécurité réunit les analyses, les problèmes détectés et les dépôts dans l’interface de bureau de Codex. Avant d’accepter un problème signalé, examinez les éléments sources qui l’étayent, sa gravité, le niveau de confiance, les chemins d’attaque et la couverture. Vous pouvez aussi comparer les problèmes détectés d’une exécution à l’autre et passer d’un problème accepté à une proposition de correctif.

Les récentes mises à jour de l’atelier facilitent la partie la moins passionnante d’une longue investigation : suivre ce qui se passe. Vous pouvez consulter en direct les phases de l’analyse, les fichiers examinés, les workers actifs, le temps écoulé et la consommation mesurée de tokens. Les analyses approfondies interrompues peuvent reprendre sans répéter le travail terminé, et les résumés réutilisables réduisent les traitements superflus.

Examinez en continu les dépôts importants

Si un dépôt nécessite une attention continue, vous pouvez configurer Codex Security dans le cloud pour analyser en continu un dépôt GitHub connecté. Vous choisissez le dépôt, la branche, l’environnement et la période de l’historique à examiner. Codex élabore ensuite un modèle de menace propre au dépôt, examine les commits pertinents et présente les problèmes détectés par ordre de priorité pour investigation.

Lorsque c’est réalisable, les problèmes probables sont validés dans un environnement isolé. Les extraits de code, les chemins d’appel, les résultats de reproduction et les recommandations de correction vous donnent des éléments concrets à examiner. Pensez à tenir le modèle de menace à jour à mesure que votre architecture et vos priorités évoluent. Examinez également tout correctif proposé avant d’ouvrir une pull request.

Codex Security dans le cloud est disponible en préversion de recherche. Une première analyse peut prendre plusieurs heures pour un dépôt volumineux ; les analyses suivantes se concentrent sur les commits et les modifications devenus pertinents depuis.

Transformez les alertes existantes en une liste de problèmes à traiter

Vous avez peut-être déjà de nombreux problèmes à examiner. Si votre équipe dispose de résultats d’analyse statique, d’alertes sur les dépendances, de rapports de bug bounty, d’avis de sécurité ou de tickets, vous pouvez trier ces éléments en attente en les confrontant à l’état actuel du dépôt, sans lancer une nouvelle analyse.

Codex Security peut exploiter des rapports SARIF, des problèmes signalés par l’analyse de code GitHub et Dependabot, des avis de sécurité, des tickets Jira ou Linear et d’autres rapports de vulnérabilité. Il examine chaque signalement, suit les entrées et les chemins de code pertinents, vérifie les contrôles existants et explique si les éléments probants justifient une action, suggèrent que le problème ne s’applique pas ou nécessitent un examen complémentaire.

Ces éléments vous aident à vous concentrer sur les problèmes qui touchent les logiciels que vous exécutez réellement. Je conserverais les outils d’analyse déjà en place : Codex Security complète l’analyse déterministe par une investigation propre au dépôt et, lorsque c’est pertinent, une validation supplémentaire.

Passez d’un signalement crédible à un correctif vérifié

Lorsqu’un problème signalé semble crédible, la question suivante est de savoir si vous pouvez le corriger en toute sécurité. Pour un problème accepté, demandez à Codex Security de préparer un correctif. Lorsque c’est réalisable en toute sécurité, il peut reproduire le problème, générer un correctif ciblé et fournir des éléments démontrant que la modification résout le problème initial.

Lorsque c’est possible, le workflow ajoute un test de non-régression qui échoue avant le correctif et réussit après son application. C’est un élément probant utile à joindre au correctif. S’il est impossible de créer un test fiable en toute sécurité, le workflow consigne ce qui reste à démontrer au lieu d’exagérer la portée des vérifications effectuées.

La décision d’appliquer la modification revient toujours à un ingénieur. Examinez le problème signalé et le diff proposé, décidez de l’appliquer ou non, puis vérifiez le résultat. Vous pouvez aussi exporter les problèmes détectés et les rapports ou les transmettre aux workflows existants de gestion des problèmes, avec une approbation explicite.

Intégrez des contrôles de sécurité aux outils existants

Si vous préférez travailler depuis un terminal, un pipeline de CI ou un outil interne, la CLI Codex Security et le SDK TypeScript open source prennent en charge ces workflows. Le package @openai/codex-security est public, mais l’exécution d’analyses nécessite un accès à Codex Security.

Pour une première exécution, respectez les prérequis de la CLI et suivez les étapes de connexion, puis lancez une analyse depuis un dépôt qui vous appartient ou que vous êtes autorisé à évaluer :

npx @openai/codex-security login
npx @openai/codex-security scan .

Avant de lancer une analyse, examinez les autorisations des analyses locales. Les analyses locales utilisent vos autorisations du système d’exploitation et ne s’interrompent pas pour demander une approbation. Retirez de l’environnement les identifiants d’accès sans rapport avec la tâche et conservez les résultats dans un emplacement privé : les rapports peuvent contenir des extraits de code source et des détails sur les vulnérabilités.

Une fois que le workflow local vous est utile, vous pouvez le rendre reproductible avec des contrôles GitHub Actions ou GitLab CI/CD. Vous pouvez examiner des pull requests ou des merge requests, exporter au format SARIF, conserver les éléments probants de sécurité et, si vous le souhaitez, faire échouer un contrôle lorsque les problèmes détectés atteignent un seuil de gravité choisi. Si vous développez votre propre application, le SDK TypeScript fournit des fonctions d’analyse, de suivi de la progression, d’annulation et de contrôle des coûts.

Analysez plusieurs dépôts et de grandes bases de code

Lorsqu’une même révision doit couvrir un ensemble de dépôts, le workflow d’analyse en masse de la CLI constitue une suite utile. Vous pouvez découvrir les dépôts depuis un compte ou une organisation GitHub autorisés, ou préparer un inventaire CSV avec les URL des dépôts ou leurs chemins locaux, des révisions épinglées, des périmètres facultatifs et un mode d’analyse standard ou approfondie pour chaque cible.

Après avoir préparé l’inventaire, lancez une campagne avec un répertoire de sortie privé situé en dehors des dépôts :

npx @openai/codex-security bulk-scan repositories.csv \
  --output-dir /path/outside/repositories/security-portfolio \
  --workers 4 --max-attempts 3

Les campagnes conservent séparément la progression et les résultats de chaque dépôt. Vous pouvez reprendre un travail interrompu, ajuster le parallélisme et les nouvelles tentatives, fournir des documents d’architecture ou des politiques de sécurité partagés, et conserver les problèmes détectés, la couverture et les résultats portables au format SARIF. Les modèles pris en charge, l’effort de raisonnement, la profondeur d’analyse et les limites de coût estimé vous permettent de choisir le niveau d’analyse que justifie chaque cible. Considérez les limites de coût estimé comme des estimations, et non comme des plafonds de dépenses stricts.

Pour un grand monorepo, je limiterais la première analyse à un service ou à un package dont votre équipe est responsable, ou à un autre périmètre de sécurité pertinent. Commencez par une analyse standard, puis appliquez des analyses approfondies de manière sélective aux services sensibles ou aux composants complexes. Pour les dépôts GitHub connectés, Codex Security dans le cloud peut examiner une période choisie de l’historique des commits, puis continuer à examiner les nouveaux commits.

La campagne initiale vous donne une base de référence. En mettant à jour les modèles de menace, en suivant les problèmes détectés dans vos systèmes existants et en vérifiant les correctifs revus, vous transformez ce premier passage en un programme de sécurité reproductible.

Travaillez avec l’écosystème de sécurité que vous utilisez déjà

Vous n’avez pas besoin de commencer par remplacer les systèmes que votre équipe utilise déjà. Codex Security est conçu pour fonctionner aux côtés des outils d’analyse, des systèmes de gestion des vulnérabilités, des outils de suivi des problèmes, des prestataires de services et des projets open source existants. Vous pouvez importer des problèmes déjà détectés, exporter des résultats portables et réintégrer les problèmes examinés dans ces workflows.

Dans le cadre d’OpenAI Daybreak, nous travaillons aussi avec des organisations de sécurité, des chercheurs, des responsables de la maintenance de projets open source et des partenaires pour rendre la défense assistée par des modèles accessible dans davantage d’outils et de services. L’accès aux capacités avancées de cybersécurité est limité aux utilisateurs approuvés menant des travaux autorisés, avec des mesures de protection adaptées à l’activité.

Adaptez les accès et les mesures de protection au travail à réaliser

La plupart des travaux défensifs peuvent commencer avec des modèles généralistes et Codex Security. Pour les équipes de défense approuvées, Daybreak Blue prend en charge des travaux autorisés tels que le tri des vulnérabilités, l’analyse de logiciels malveillants, l’ingénierie de détection, les investigations de sécurité et la validation des correctifs. Daybreak Red est destiné à un ensemble plus restreint d’activités spécialisées et autorisées, notamment la recherche avancée de vulnérabilités, la validation contrôlée d’exploits et le red teaming. Il nécessite une approbation et des mesures de protection distinctes.

Consultez les consignes actuelles sur les modèles et Trusted Access pour choisir l’offre adaptée et confirmer que votre identité, votre espace de travail ou votre organisation API, votre modèle et l’interface produit sont approuvés. L’approbation de l’accès ne configure pas votre environnement à votre place. Définissez les systèmes et les actions compris dans le périmètre, appliquez le principe du moindre privilège aux autorisations, utilisez une exécution isolée lorsque c’est approprié et maintenez un examen humain pour les décisions lourdes de conséquences.

Choisissez un point de départ

Si vous cherchez quoi essayer en premier, je commencerais là où votre équipe a déjà du travail à faire :

• Ouvrez ChatGPT pour une première investigation.
• Installez le plugin Codex Security pour évaluer un dépôt ou trier les problèmes en attente.
• Configurez la révision de Codex Security pour vérifier les pull requests avant leur fusion.
• Connectez un dépôt à Codex Security dans le cloud pour une analyse continue.
• Explorez la CLI et le SDK TypeScript pour ajouter des vérifications aux outils existants.
• Consultez Trusted Access for Cyber et OpenAI Daybreak pour des travaux avancés et autorisés.

Vous n’avez pas à adopter tous les workflows à la fois. Quel que soit celui que vous essayez, la démarche reste la même : déterminez si le risque est réel, examinez les éléments de preuve, passez en revue la modification proposée et vérifiez le correctif.