La rapidité du développement déborde la sécurité et accroît les vulnérabilités critiques

Les données récentes d'OX Security, qui ont examiné 216 millions de constatations de sûreté dans 250 organisations sur un quart, constituent une réalité inquiétante pour les équipes de développement et de sécurité : le volume brut d'alertes s'est considérablement accru, mais le plus inquiétant est que le nombre de risques critiques prioritaires a augmenté beaucoup plus rapidement. Alors que les alertes totales ont augmenté d'environ 52 % par année, la partie des constatations qui représentent en fait un risque élevé pour l'entreprise a grimpé presque quatre fois, un écart qui nécessite de repenser la façon dont l'insécurité logicielle est priorisée et réparée.

L'ère de la vitesse apporte un nouveau type de problème. L'adoption accélérée d'outils d'aide au développement de l'IA accélère la création de codes et donc l'émergence de vulnérabilités plus complexes et dépendantes du contexte. OX Security note une relation claire entre l'utilisation d'assistants automatiques et l'augmentation des résultats critiques : la moyenne par organisation est passée d'un peu plus de 200 à près de 800. Cela ne signifie pas que l'IV est intrinsèquement précaire, mais augmente la vitesse et la densité du changement, et de nombreuses pratiques analytiques traditionnelles ne sont pas préparées pour ce taux.

Cet écart entre la vitesse de production et la capacité d'assainissement est ce que certains appellent déjà un « écart de vitesse ». Lorsque le rythme du changement dépasse la capacité des workflows de sécurité à détecter, à prioriser et à corriger, la proportion de problèmes réellement dangereux augmente plus rapidement que les outils qui les détectent. Par conséquent, la proportion de résultats critiques sur les alertes totales a presque triplé dans l'analyse des OX, passant d'une petite fraction à un chiffre nécessitant une attention opérationnelle.

Il importe moins le score technique et plus le contexte commercial. Traditionnellement, les organisations se sont appuyées sur des paramètres tels que le CVSS pour commander des risques, mais les conclusions récentes confirment quelque chose que de nombreux praticiens soupçonnaient déjà : la gravité technique à elle seule ne définit pas le risque pour l'entreprise. Des facteurs tels que la question de savoir si un composant traite des données personnelles sensibles ou s'il fait partie d'une application commerciale hautement prioritaire amènent les conclusions à une catégorie critique beaucoup plus souvent. Que la vulnérabilité existe dans un service que PII gère ou dans une partie du noyau bancaire change radicalement l'urgence de son atténuation. Cette approche de hiérarchisation des contextes est conforme aux recommandations des collectivités telles que le PSAO sur les approches opérationnelles à risque réel ( OWASP Méthode de cotation des risques).

L'attention portée aux données personnelles n'est pas occasionnelle : le traitement de l'IIP a été l'un des facteurs qui ont accru les constatations critiques. Du point de vue de la réglementation et de la réputation, la divulgation de renseignements personnels entraîne des répercussions directes et des sanctions, comme le rappellent les guides d'organismes comme le NIST sur le traitement des renseignements personnels identifiables ( NIST SP 800-122), la hiérarchisation en fonction de la sensibilité des données est désormais une pratique indispensable.

Les disparités sectorielles et le cas de la voiture. L'analyse OX montre également que le risque n'est pas réparti uniformément entre les secteurs. Les compagnies d'assurance ont présenté la plus forte densité de résultats critiques, probablement en raison de la convergence entre les systèmes existants qui traitent les données sensibles et les nouvelles plateformes numériques. Pour sa part, le secteur automobile a généré le plus grand volume brut d'alertes, ce qui est logique en considérant l'explosion de logiciels dans les véhicules modernes : les voitures deviennent des plates-formes logicielles et multiplient la surface d'attaque. Plusieurs analyses industrielles ont mis en évidence ce phénomène d'expansion rapide des logiciels dans la voiture et les implications pour la sécurité et la qualité ( McKinsey: véhicules définis par logiciel).

Tout cela mène à une conclusion pratique : la simple accumulation de scans et de règles ne suffit plus. Les outils de couplage et les scanners hérités restent utiles pour filtrer les problèmes évidents, mais la priorité doit être de comprendre le but du service, son exposition aux données sensibles et son activité critique. Ce regard contextuel exige l'intégration de signaux au-delà de la vulnérabilité technique, y compris la télémétrie de déploiement, la cartographie des unités et la classification des actifs en fonction de leur impact.

Que devrait changer l'équipement technique? Premièrement, les politiques prioritaires doivent évoluer : cesser de traiter toutes les vulnérabilités avec la même métrique et adopter des modèles qui pèsent l'emplacement de l'échec et la sensibilité de l'environnement. Deuxièmement, la sécurité doit entrer dans le cycle de développement plus tôt et accompagner l'accélération fournie par l'AI. L'intégration de contrôles de sécurité dans CI / CD, l'ajout d'analyse contextuelle et l'automatisation d'une partie du triage peuvent amortir l'écart de vitesse. Troisièmement, il ne suffit pas de détecter: il est crucial de fermer la boucle avec le remède et la vérification dans la production, et, le cas échéant, de déployer des mesures compensatoires axées sur les risques des entreprises.

Enfin, la communauté et l'industrie doivent continuer à étudier l'impact des outils d'IA sur la sécurité des logiciels. Les plateformes offrant des assistants de programmation ont commencé à publier des guides et des considérations de sécurité pour une utilisation responsable, et les équipes devraient combiner ces recommandations avec des contrôles internes rigoureux ( Guide de sécurité et de confidentialité de GitHub Copilot). En outre, les rapports de l'industrie sur l'état de la sécurité des applications, comme ceux des entreprises spécialisées dans l'analyse et les essais, peuvent servir de référence pour comprendre les tendances et adapter les pratiques.

L'analyse de OX Security, dont la version complète avec méthodologie et mesures sectorielles est disponible sur son site Internet ( Sécurité OX) est un rappel fort: la transformation du développement entraînée par l'IA et la complexité croissante du logiciel nécessitent un changement dans la façon dont nous valorisons, priorisons et fixons les vulnérabilités. L'objectif n'est plus seulement de réduire le nombre d'alertes, mais d'identifier et d'atténuer ce qui peut vraiment nuire à l'entreprise et aux personnes qu'elle sert.