L’exploitabilité ne fait pas tout. Ce qui compte, c’est le risque de rupture.

Le paradoxe de la sécurité applicative : pourquoi ne corrige-t-on pas davantage de vulnérabilités ?

Pourquoi les développeurs ne corrigent-ils pas chaque vulnérabilité de sécurité applicative, dès qu’elle est détectée ? La réponse la plus courante ? Le temps. Les outils de sécurité modernes peuvent détecter des milliers de vulnérabilités dans une base de code. Les corriger toutes mobiliserait toute la capacité d’une équipe de développement, souvent au détriment du développement de fonctionnalités et d’autres priorités.

Mais le temps nécessaire pour corriger les vulnérabilités a changé ces dernières années. Auparavant, examiner une alerte, comprendre comment la corriger et modifier le code manuellement pouvait prendre une journée entière. Aujourd’hui, l’automatisation et les outils assistés par l’IA prennent en charge une grande partie du travail et préparent des modifications de code prêtes à intégrer en le temps de préparer un café. Pour les vulnérabilités SCA en particulier, il suffit souvent de mettre à jour les packages vulnérables vers des versions plus récentes qui corrigent les CVE.

Alors, si le temps n’est plus le principal obstacle, quel est-il ? La confiance. Les développeurs ne négligent pas les correctifs parce qu’ils refusent de traiter les problèmes de sécurité. Le plus souvent, ils hésitent par crainte de casser leur code.

Découvrez Breakability : le maillon manquant de la priorisation

Pour aider les équipes à établir leurs priorités avec plus d’assurance, nous lançons une nouvelle fonctionnalité pour Snyk Open Source : Breakability Risk.

La première phase de Breakability s’est attachée à répondre à la question que les développeurs se posent chaque jour : Si j’applique le correctif recommandé par Snyk, est-ce que cela va casser mon application ? Toute mise à jour de dépendance comporte un certain niveau de risque. Une simple mise à jour de référence de package peut introduire des changements d’API qui empêchent votre code de compiler. Pire encore, les signatures des méthodes de l’API peuvent rester inchangées, tandis que des modifications subtiles de comportement font que votre code compile, mais échoue à l’exécution.

Il arrive souvent que deux dépendances directes ou plus partagent une dépendance transitive. Lorsque plusieurs dépendances directes reposent sur le même package sous-jacent, la mise à jour d’un élément de votre graphe de dépendances pour corriger une CVE peut créer un nouveau problème d’incompatibilité avec d’autres dépendances. C’est le redoutable problème de « l’enfer des dépendances ».

Breakability Risk identifie les mises à jour que vous pouvez appliquer sans attendre et celles qui nécessitent une analyse plus approfondie.

La confiance est le moteur de la sécurité

Nous avons mené des expérimentations sur l’analyse du risque de rupture, et les résultats sont constants. Lorsque les développeurs savent que le risque de casser leurs applications est faible, ils sont beaucoup plus susceptibles d’intégrer un correctif. Dans nos expérimentations, les mises à jour présentant un faible risque de rupture ont été intégrées à un rythme quatre fois supérieur à celui des changements plus risqués.

Notre analyse montre qu’environ un tiers de tous les correctifs présentent un faible risque de rupture. Pour un client Snyk moyen, donner la priorité à ces mises à jour moins risquées pourrait permettre de corriger des milliers de vulnérabilités supplémentaires chaque année.

Breakability en pratique : risque faible ou élevé

Snyk affiche désormais directement dans vos pull requests un indicateur du risque lié à l’intégration, afin de vous aider à établir vos priorités et à accélérer les corrections. Snyk Open Source fournit des informations détaillées, une évaluation contextuelle du risque et des ressources pédagogiques sur Snyk Learn pour aider les développeurs à monter en compétences.

Scénario 1 : « Une victoire facile »

Dans ce scénario, Snyk Open Source a créé une pull request pour qu’une équipe passe à une version plus récente de [libxmljs2] afin de corriger plusieurs vulnérabilités par déni de service liées aux expressions régulières (ReDoS).

• Analyse : La mise à niveau abandonne principalement la prise en charge des versions de Node.js en fin de vie

• Breakability Risk : Snyk indique que le risque lié à l’intégration est faible, car aucun changement de comportement important n’est à prévoir

• Verdict : Cliquez sur le bouton. Sécurisez le code. Et passez à la suite.

Scénario 2 : « À utiliser avec prudence »

Ici, une mise à jour de [i18n] corrige une pollution de prototype, mais introduit un changement d’architecture : on passe d’un singleton global à une configuration basée sur des instances.

• Analyse : Le mode d’utilisation fondamental de la bibliothèque a changé.

• Breakability Risk : Snyk indique un risque élevé lié à l’intégration en raison de changements architecturaux incompatibles dans la bibliothèque.

• Verdict : N’intégrez pas la mise à jour avant d’avoir examiné votre code et apporté les modifications nécessaires.

Une nouvelle hiérarchie des corrections

Selon nous, la première question à se poser dans tout processus de correction est simple : Puis-je résoudre ce problème avec un minimum d’efforts et de risques ?

Si la réponse est oui, corrigez le problème. Breakability permet aux équipes de traiter en priorité les mises à jour à faible risque, et ainsi de corriger en un clic un tiers, voire jusqu’à la moitié, de leur backlog de CVE. En dissipant la crainte de « tout casser », les équipes peuvent résorber en toute confiance une part importante de leur backlog, réduire la dette de sécurité qui pèse sur les équipes de développement depuis des années et diminuer les risques de sécurité sans alourdir la charge de travail des ingénieurs.

Snyk ne délaisse ni Reachability ni Risk Score.

Aussi utile soit l’analyse de la possibilité d’atteindre une vulnérabilité pour établir les priorités, il y a une grande différence entre affirmer « Il est absolument certain que cette vulnérabilité ne peut pas être atteinte » et « Aucun chemin permettant d’atteindre cette vulnérabilité n’a été trouvé ». Ce deuxième cas est bien plus fréquent que le premier. Vous ne pouvez tout simplement pas supposer qu’« aucun chemin d’accès n’a été trouvé » signifie qu’il n’existe aucun chemin d’accès, en particulier aujourd’hui, alors que les attaquants utilisent des outils de piratage basés sur l’IA pour repérer les faiblesses et les exploiter plus rapidement que jamais. Plutôt que d’accepter le risque lié à des packages présentant des vulnérabilités potentiellement inexploitables, nous vous permettons simplement de les corriger plus facilement, sans risque d’effets secondaires indésirables.

Breakability et l’AI Security Fabric de Snyk

Ce nouveau paradigme de correction est essentiel pour déployer l’AI Security Fabric. Comme l’explique Prescriptive Path to Operationalizing AI Security, Breakability vous aide à optimiser la réduction des risques en renforçant la confiance dans les correctifs proposés, en allant au-delà des seuls critères de priorisation et en créant un processus prévisible, fondé sur la confiance. Les équipes peuvent ainsi intégrer davantage de correctifs plus rapidement, avec moins de crainte de provoquer une rupture.

Démarrer avec Breakability

La première phase de Breakability est disponible dès maintenant en tant que fonctionnalité Snyk Preview pour tous les clients de Snyk Open Source. Activez-la pour commencer dès aujourd’hui à voir les évaluations du risque de rupture dans les pull requests générées par Snyk. Nous vous invitons à l’essayer et à nous faire part de vos impressions !

Vous souhaitez repenser la manière de prioriser et de corriger les vulnérabilités en toute confiance ? Découvrez comment les informations basées sur l’IA aident les équipes à dépasser la détection pour réduire les risques de façon prévisible et à grande échelle. Téléchargez dès aujourd’hui notre eBook From Shift Left to Secure at Inception.