Corgea présente comment il a affiné son grand modèle de langage (LLM) pour améliorer la sécurité des applications d'entreprise. Le réglage fin ne consiste pas seulement à améliorer un modèle, mais permet une gestion des vulnérabilités plus rapide et plus précise. Selon les tests internes, Corgea serait aussi performant que les modèles d'OpenAI et offrirait un bon rapport coût-efficacité ainsi qu'un contrôle total des données pour une entreprise.Corgea, une plateforme pour la sécurité des données dans les applications, annonce que son équipe construit un ingénieur AppSec d'IA qui aidera les développeurs à trier et corriger automatiquement le code non sécurisé. Grâce à la détection des faux positifs, Corgea aiderait à réduire 30 % des résultats SAST et accélérerait la remédiation d'environ 80 %. Ahmad Sadeddin, le fondateur de Corgea, affirme que pour déployer un logiciel de manière sécurisée et privée, ils ont dû affiner leur grand modèle de langage (LLM).
Pourquoi ont-ils fait cela ? M. Ahmad répond : "Les entreprises, en particulier celles des secteurs réglementés, ont des exigences strictes en matière de résidence des données, de confidentialité et de sécurité. Ces organisations exigent souvent des déploiements de cloud privé et doivent éviter de dépendre de LLM tiers qui pourraient présenter des risques d'exposition des données."
Il ajoute : "Notre LLM finement ajusté répond à ces préoccupations en offrant une isolation complète des données et en évitant aux clients de signer des accords d'association commerciale (BAA) pour la conformité HIPAA. En outre, cette approche permet un modèle de déploiement à faible coût tout en surpassant des modèles encore plus grands comme celui d'OpenAI dans des tests de référence pertinents."
M. Ahmad partage comment Corgea a affiné son LLM pour améliorer la sécurité des applications d'entreprise :
Structure du modèle : Le cœur de notre solution
Au cœur de notre solution se trouve Llama 3.1 8B, un modèle central de 8 milliards de paramètres. Nous avons comparé tous les petits modèles populaires entre eux, y compris Mistral, Mixtral, Codestral mamba et Deepseek coder. Nous avons choisi Llama 3.1 8B en raison de sa taille, de sa facilité de réglage, de ses performances mesurables dans les domaines clés dont nous avons besoin et de sa nouveauté.
Le modèle est doté de plusieurs poids adaptés à des tâches spécifiques, notamment la détection des faux positifs, les correctifs automatisés et les contrôles de qualité. Cette approche modulaire nous permet d'utiliser le meilleur des poids pour une tâche particulière pendant l'inférence. L'aplatissement du modèle et la fusion des poids ont donné des résultats bien moins bons.
Vous vous demandez peut-être si vous déployez votre modèle cinq fois ? Non, nous déployons le modèle de base et acheminons la requête vers le poids actif dont nous avons besoin. Par exemple, si nous fixons, le modèle chargera les poids de fixation actifs, puis passera à une autre tâche si nécessaire. Cela nous permet de déployer Corgea sur un seul GPU A10 24GB et d'être performant avec une latence de commutation de ~10ms.
Pourquoi tout cela est-il important ? Pour éviter aux clients d'avoir à héberger un grand modèle dans leur cloud privé. Les grands modèles qui nécessitent plus de RAM et des GPU plus puissants sont coûteux. Cette solution est très rentable.
Le processus de réglage fin : De l'hypothèse au déploiement
Le réglage fin semblait être une tâche très importante. Comme on dit « garbage in, garbage out », il était essentiel pour nous de choisir les meilleurs correctifs parmi un ensemble varié de langages de programmation, de cadres et de vulnérabilités, avec le moins de faux positifs possible. En tant que startup, nous ne disposons pas d'une armée de personnes pour étiqueter les problèmes en tant que faux positifs et sélectionner les meilleurs correctifs à intégrer dans un modèle pour l'entraînement. Nous avons dû faire preuve d'innovation.
Quel est notre ensemble de données ?
Notre modèle est entraîné sur un ensemble de données diversifié comprenant des centaines de dépôts : des projets à code source fermé que nous possédons, des projets à code source ouvert vulnérables comme Juice Shop, et d'autres bases de code à code source ouvert. Il est important de noter qu'aucune donnée client n'est utilisée dans le processus de formation. L'ensemble de données couvre plusieurs langages de programmation, notamment Python, JavaScript, TypeScript, Java, Go, Ruby et C#, reflétant ainsi la diversité des écosystèmes dans lesquels opèrent nos clients. Nous avons également dû tenir compte d'un large éventail de cadres tels que Ruby-on-rails, Django, Flask, Kotlin, etc. car chaque cadre traite différemment les résultats de sécurité. Par exemple, il existe environ 30 façons différentes de corriger une vulnérabilité d'injection SQL, car cela dépend du langage de programmation, du cadre et de la base de données qu'une application particulière utilise.
Comment fonctionne la formation ?
En utilisant des techniques de formation non supervisées, notre fonction de détection des faux positifs et notre harnais de test, nous avons pu construire un système de réglage fin qui nous a permis de mettre à l'échelle la sélection des ensembles de données.
Le processus de mise au point commence par la formation d'une hypothèse basée sur un domaine spécifique que nous devons construire ou améliorer. Nous générons des milliers de vulnérabilités à partir de l'ensemble de données ci-dessus. Nous utilisons ensuite notre fonction automatisée de détection des faux positifs dans Corgea pour éliminer les mauvais résultats. C'est essentiel pour s'assurer que le modèle n'est pas entraîné sur des correctifs pour du code qui n'a jamais été vulnérable.
Nous extrayons ensuite automatiquement le contexte pertinent, en détectant par exemple le langage utilisé, les importations appelées, le bloc fonctionnel du code vulnérable, la vulnérabilité et d'autres métadonnées. Ces données sont ensuite introduites dans notre outil de correction afin de générer des correctifs à l'aide de modèles de frontière.
Nous avons mis au point une technique exclusive qui consiste à exécuter plusieurs cycles de correction et de validation par rapport à des modèles frontières afin de s'assurer que les meilleures réponses possibles sont sélectionnées avant le réglage final. Ce qui nous aurait demandé des semaines d'étiquetage des données peut désormais être réalisé en moins de 24 heures, sans intervention humaine. Ces données deviennent nos données d'entraînement, qui sont ensuite introduites dans notre processus de mise au point.
Une fois la mise au point terminée, le modèle est soumis à des tests approfondis à l'aide de notre harnais de test. Dans Test Harness, nous testons ce nouveau modèle sur un ensemble de données différent afin de valider ses performances et de le comparer à d'autres modèles frontières tels qu'OpenAI et Anthropic. Ce n'est que lorsqu'il répond à nos critères de réussite rigoureux que nous le déployons. Nous vérifions la couverture des corrections, le taux de faux positifs, les problèmes de syntaxe, les problèmes sémantiques, etc. L'ensemble du processus, de l'hypothèse au déploiement, peut être réalisé en seulement 2 ou 3 jours, ce qui nous permet de nous adapter rapidement au retour d'information et aux nouvelles technologies émergentes.
Au cœur de notre solution se trouve Llama 3.1 8B, un modèle central de 8 milliards de paramètres. Nous avons comparé tous les petits modèles populaires entre eux, y compris Mistral, Mixtral, Codestral mamba et Deepseek coder. Nous avons choisi Llama 3.1 8B en raison de sa taille, de sa facilité de réglage, de ses performances mesurables dans les domaines clés dont nous avons besoin et de sa nouveauté.
Le modèle est doté de plusieurs poids adaptés à des tâches spécifiques, notamment la détection des faux positifs, les correctifs automatisés et les contrôles de qualité. Cette approche modulaire nous permet d'utiliser le meilleur des poids pour une tâche particulière pendant l'inférence. L'aplatissement du modèle et la fusion des poids ont donné des résultats bien moins bons.
Vous vous demandez peut-être si vous déployez votre modèle cinq fois ? Non, nous déployons le modèle de base et acheminons la requête vers le poids actif dont nous avons besoin. Par exemple, si nous fixons, le modèle chargera les poids de fixation actifs, puis passera à une autre tâche si nécessaire. Cela nous permet de déployer Corgea sur un seul GPU A10 24GB et d'être performant avec une latence de commutation de ~10ms.
Pourquoi tout cela est-il important ? Pour éviter aux clients d'avoir à héberger un grand modèle dans leur cloud privé. Les grands modèles qui nécessitent plus de RAM et des GPU plus puissants sont coûteux. Cette solution est très rentable.
Le processus de réglage fin : De l'hypothèse au déploiement
Le réglage fin semblait être une tâche très importante. Comme on dit « garbage in, garbage out », il était essentiel pour nous de choisir les meilleurs correctifs parmi un ensemble varié de langages de programmation, de cadres et de vulnérabilités, avec le moins de faux positifs possible. En tant que startup, nous ne disposons pas d'une armée de personnes pour étiqueter les problèmes en tant que faux positifs et sélectionner les meilleurs correctifs à intégrer dans un modèle pour l'entraînement. Nous avons dû faire preuve d'innovation.
Quel est notre ensemble de données ?
Notre modèle est entraîné sur un ensemble de données diversifié comprenant des centaines de dépôts : des projets à code source fermé que nous possédons, des projets à code source ouvert vulnérables comme Juice Shop, et d'autres bases de code à code source ouvert. Il est important de noter qu'aucune donnée client n'est utilisée dans le processus de formation. L'ensemble de données couvre plusieurs langages de programmation, notamment Python, JavaScript, TypeScript, Java, Go, Ruby et C#, reflétant ainsi la diversité des écosystèmes dans lesquels opèrent nos clients. Nous avons également dû tenir compte d'un large éventail de cadres tels que Ruby-on-rails, Django, Flask, Kotlin, etc. car chaque cadre traite différemment les résultats de sécurité. Par exemple, il existe environ 30 façons différentes de corriger une vulnérabilité d'injection SQL, car cela dépend du langage de programmation, du cadre et de la base de données qu'une application particulière utilise.
Comment fonctionne la formation ?
En utilisant des techniques de formation non supervisées, notre fonction de détection des faux positifs et notre harnais de test, nous avons pu construire un système de réglage fin qui nous a permis de mettre à l'échelle la sélection des ensembles de données.
Le processus de mise au point commence par la formation d'une hypothèse basée sur un domaine spécifique que nous devons construire ou améliorer. Nous générons des milliers de vulnérabilités à partir de l'ensemble de données ci-dessus. Nous utilisons ensuite notre fonction automatisée de détection des faux positifs dans Corgea pour éliminer les mauvais résultats. C'est essentiel pour s'assurer que le modèle n'est pas entraîné sur des correctifs pour du code qui n'a jamais été vulnérable.
Nous extrayons ensuite automatiquement le contexte pertinent, en détectant par exemple le langage utilisé, les importations appelées, le bloc fonctionnel du code vulnérable, la vulnérabilité et d'autres métadonnées. Ces données sont ensuite introduites dans notre outil de correction afin de générer des correctifs à l'aide de modèles de frontière.
Nous avons mis au point une technique exclusive qui consiste à exécuter plusieurs cycles de correction et de validation par rapport à des modèles frontières afin de s'assurer que les meilleures réponses possibles sont sélectionnées avant le réglage final. Ce qui nous aurait demandé des semaines d'étiquetage des données peut désormais être réalisé en moins de 24 heures, sans intervention humaine. Ces données deviennent nos données d'entraînement, qui sont ensuite introduites dans notre processus de mise au point.
Une fois la mise au point terminée, le modèle est soumis à des tests approfondis à l'aide de notre harnais de test. Dans Test Harness, nous testons ce nouveau modèle sur un ensemble de données différent afin de valider ses performances et de le comparer à d'autres modèles frontières tels qu'OpenAI et Anthropic. Ce n'est que lorsqu'il répond à nos critères de réussite rigoureux que nous le déployons. Nous vérifions la couverture des corrections, le taux de faux positifs, les problèmes de syntaxe, les problèmes sémantiques, etc. L'ensemble du processus, de l'hypothèse au déploiement, peut être réalisé en seulement 2 ou 3 jours, ce qui nous permet de nous adapter rapidement au retour d'information et aux nouvelles technologies émergentes.
Les résultats : Performance et efficacité
Selon les tests de Corgea, son Security LLM surpasse les modèles d'OpenAI de 7% tout en étant environ 90 % plus petit. Presque toutes les classes de vulnérabilités ont été améliorées.
Par exemple, XSS et l'injection de code ont eu environ 30% et 77% de problèmes en moins dans toutes les langues respectivement. Ils ont également constaté que certaines classes de vulnérabilités se sont nettement améliorées grâce à ce réglage fin. Par exemple, la traversée de chemin (CWE-22) a 2,85 fois plus de corrections valides, et la complexité insuffisante des expressions régulières (CWE-1333) a 4 fois plus de corrections valides. La précision des correctifs dans certains langages s'est améliorée. Par exemple, les correctifs en Javascript sont 12% plus valides.
D'un point de vue plus tactique, les tests de Corgea ont également montré que le modèle s'améliorait même pour des choses simples comme ne pas changer inutilement les espaces blancs, modifier du code sans rapport, sur-fixer et halluciner. Les modèles plus petits sont aussi généralement moins obéissants aux instructions, et ils manquaient certaines instructions données, comme le respect du format de sortie. Un réglage précis a vraiment permis de réduire ces problèmes.
M. Ahmad Sadeddin commente ces résultats : "Ces gains de performance sont essentiels pour les entreprises qui ont besoin de résultats très précis sans avoir recours à des ressources informatiques massives. En outre, la taille réduite de notre modèle signifie qu'il peut être déployé de manière plus rentable, ce qui réduit encore le coût total de possession. En outre, le modèle est aussi performant qu'OpenAI pour la détection des faux positifs, l'explication des vulnérabilités et la génération d'un résumé des changements pour le diff."
Conclusion
Le LLM affiné de Corgea est conçu pour répondre aux besoins uniques des entreprises en fournissant une solution robuste, axée sur la protection de la vie privée, qui améliore la sécurité des applications. En tirant parti de son processus de réglage fin et d'un ensemble de données soigneusement sélectionnées, Corgea souhaite proposer un modèle qui offre des performances exceptionnelles et un bon rapport coût-efficacité.
Cette initiative de perfectionnement ne consiste pas seulement à améliorer un modèle, mais aussi à relever les défis spécifiques auxquels les entreprises sont confrontées en matière de sécurité des applications. L'objectif étant que les entreprises déploient en toute confiance la solution dans leurs clouds privés, en sachant que leurs données restent sécurisées tout en bénéficiant d'une gestion des vulnérabilités à la pointe de la technologie.
À propos de Corgea
Corgea est une nouvelle façon de sécuriser les applications qui met l'accent sur la rapidité de développement, la valeur ajoutée et la facilité d'utilisation. Corrigez les problèmes de sécurité du code avant qu'ils ne causent des incidents. Avec Corgea, les entreprises pourront s'attendre à une gestion des vulnérabilités plus rapide et plus précise, tout en conservant un contrôle total sur leurs données.
Source : Corgea
Et vous ?
Pensez-vous que cette solution est crédible ou pertinente ? Quel est votre avis sur le sujet ?Voir aussi :
Les défis croissants du code généré par l'IA : le code généré par l'IA pourrait augmenter la charge de travail des développeurs et accroître les risques, selon Harness Les développeurs utilisent l'IA pour déboguer leur code, des rapports de tests, et même créer des applications, mais ils sont confrontés a des biais et des erreurs, d'après Applause StarCoder 2 : un outil d'IA de génération code qui fonctionnerait sur la plupart des GPU grand public modernes. Il serait plus performant que Code Llama 33B de Meta et prétendument open source