Pourquoi le code généré par l’IA casse votre modèle de gestion des vulnérabilités

Les générateurs de code d’IA ont réalisé quelque chose que des années d’outils DevOps n’ont jamais tout à fait réussi à faire : ils ont rendu possible la livraison de fonctionnalités en quelques jours qui prenaient auparavant des semaines. Le problème est que la vitesse s’applique également aux vulnérabilités.

Au cours de mes années dans la cybersécurité, j’ai vu les organisations passer par le même schéma réactif : découvrir une vulnérabilité, se précipiter pour en comprendre l’étendue, se disputer pour savoir qui est responsable de la correction et la remédier des semaines ou des mois plus tard. L’IA n’a pas changé ce schéma. Elle l’a accéléré à un rythme où l’ancien modèle ne peut plus suivre. La moyenne de l’industrie pour la résolution des CVE critiques est supérieure à 60 jours. Le développement assisté par l’IA ne vous donne pas 60 jours. Il vous donne une nouvelle base de code à chaque sprint.

Le problème de dépendance est maintenant un problème d’IA

Quatre-vingt-seize pour cent des applications d’entreprise incluent des composants open source. La plupart n’ont jamais été rigoureusement vérifiés, ils ont simplement été extraits de registres publics parce qu’ils fonctionnaient et que quelqu’un en avait besoin cet après-midi-là. Les équipes de sécurité perdent du terrain sur ce point depuis des années, et les assistants de codage d’IA ont transformé une lente hémorragie en quelque chose de beaucoup plus difficile à contrôler.

Lorsqu’un développeur écrit du code manuellement, il prend des décisions délibérées concernant les dépendances. Lorsqu’un modèle d’IA génère du code, il extrait de ce avec quoi il a été formé. Cela signifie souvent des packages hallucinés, des versions obsolètes ou des composants avec des CVE connues que le modèle n’avait aucune raison d’éviter. Le code arrive en apparence propre. Le risque est intégré dans l’arbre des dépendances, plusieurs couches plus bas, invisible à quiconque ne cherche pas spécifiquement à le trouver.

J’ai participé à des revues de sécurité où les équipes étaient choquées de découvrir une CVE critique dans une dépendance transitive d’un package qu’elles avaient approuvé des mois plus tôt. Le package était correct. Ce qu’il a tiré était incorrect. Cette dynamique se produit maintenant à l’échelle de la machine, à travers des centaines de développeurs utilisant des outils d’IA qui n’ont aucun concept de la posture de sécurité de votre organisation.

La numérisation après coup n’est pas une stratégie

Le modèle prédominant pour la sécurité des logiciels open source est la numérisation et la correction : exécuter un scanner, trier les résultats, attribuer des tickets et attendre. Ce modèle a toujours été réactif, et dans un environnement de développement accéléré par l’IA, il est complètement dépassé.

Les scanners trouvent des problèmes après qu’ils soient déjà dans votre code. La fenêtre entre l’introduction et la découverte est où vit votre exposition. Lorsque l’IA génère du code à grande échelle, cette fenêtre s’élargit et le volume des résultats augmente plus vite que n’importe quelle équipe ne peut les corriger manuellement. Le résultat est un arriéré de CVE qui s’accroît indéfiniment, une priorisation qui devient une supposition et des développeurs qui passent 4 à 8 heures par vulnérabilité sur un travail qui ne produit aucune valeur commerciale.

Ajoutez les défaillances de gouvernance qui suivent et le tableau devient encore plus sombre. La propriété de la correction est souvent peu claire. La sécurité signale une CVE, l’ingénierie l’appelle une question de configuration et les opérations l’appellent un problème de code. J’ai vu ce schéma il y a 20 ans et il n’a pas disparu. L’IA rend les conséquences de cette ambiguïté significativement plus difficiles à absorber.

Le changement qui fonctionne vraiment : contrôler ce qui entre

Les organisations qui prennent les devants ont cessé d’essayer de numériser leur chemin vers la sécurité et ont commencé à contrôler ce que leurs développeurs et outils d’IA peuvent consommer en premier lieu. Le mécanisme est un catalogue de composants open source évalués, construit à partir de la source, surveillé en continu et servi comme un registre interne privé qui remplace les tirages directs à partir d’écosystèmes publics comme PyPI, npm ou Maven.

Cette approche déplace la sécurité vers la gauche dans le sens le plus littéral. Les vulnérabilités sont bloquées au point de consommation, avant qu’elles n’entrent jamais dans la pipeline de construction. Les développeurs utilisent les mêmes outils qu’ils ont toujours utilisés. Les assistants de codage d’IA résolvent les dépendances à partir de la même source gérée. L’équipe de sécurité définit une politique une fois, et cette politique s’applique partout, y compris au code qu’un modèle a généré à 2 heures du matin sans que personne ne l’ait examiné.

Ceci est à quoi cela ressemble dans la pratique

Pour les dirigeants de la sécurité qui travaillent sur cela, quelques choses sont plus importantes que tout le reste :

1. Définissez votre ensemble de composants approuvés avant de mettre à l’échelle l’adoption de l’IA. Si vos outils de codage d’IA résolvent les dépendances à partir de registres publics, votre processus d’approbation n’existe que sur papier. Établissez un registre interne géré, acheminez tout à travers celui-ci et exigez que les composants soient construits à partir de la source avec une provenance vérifiable.
2. Traitez la correction comme un processus géré, et non comme une file d’attente de tickets. Les organisations qui restent à la tête de la dette de CVE ne déplacent pas plus rapidement la correction manuelle. Ils ont supprimé la correction manuelle de l’équation. Lorsqu’un correctif approuvé par la communauté est disponible, il est reconstruit automatiquement dans le catalogue. Les développeurs reçoivent la mise à jour la prochaine fois qu’ils tirent. Personne n’attribue de ticket. Personne n’attend 60 jours.
3. Mappez votre chaîne d’outils d’IA à vos obligations de conformité avant d’y être forcé. J’ai vu des équipes construire sur des outils d’IA pendant des mois, seulement pour heurter un mur lorsque le client a exigé une alignement FedRAMP ou des preuves SOC 2. Votre catalogue évalué est également votre traçage d’audit de conformité. Les SBOM et les enregistrements de provenance doivent être livrés avec chaque composant, et non assemblés rétroactivement sous pression de délai.
4. Attribuez une propriété claire à la couche de gouvernance, et non à la couche de ticket. Les équipes qui déplacent le plus rapidement la correction sont celles où l’équipe de sécurité possède la politique, l’équipe de plateforme possède la livraison et où aucune des deux n’attend que l’autre agisse.

La sécurité qui permet plutôt que de bloquer

Il existe une croyance persistante selon laquelle la sécurité et la vitesse de développement sont en conflit fondamental. Je n’ai jamais trouvé cela être vrai lorsque la sécurité est conçue dans le processus plutôt que d’y être greffée. Les développeurs qui travaillent à partir d’un ensemble de composants évalués se déplacent réellement plus vite, car ils ne sont pas en train de douter des approbations, d’attendre les examens de sécurité ou de nettoyer les vulnérabilités qui auraient pu être bloquées en amont.

Les organisations qui navigueront le développement piloté par l’IA sans accumuler une dette de sécurité non viable ne sont pas celles qui exécutent le plus de scanners. Ce sont celles qui ont pris la décision délibérée de gouverner ce qui entre dans leur chaîne d’approvisionnement logicielle avant qu’il ne devienne un problème de réponse aux incidents. Cette décision appartient à la direction. Les outils pour l’exécuter existent aujourd’hui.