Skip to main content

Pourquoi la « gestion des vulnérabilités » ne suffit pas à la sécurité applicative moderne

Écrit par
feature snyk apprisk globe

13 juin 2024

0 minutes de lecture

Face à la complexité croissante des environnements de développement logiciel, à l’intensification des cybermenaces et à l’évolution des exigences réglementaires, les équipes AppSec doivent relever un ensemble de défis particulièrement complexes.

L’émergence et l’adoption des méthodologies « shift left » ont marqué une avancée importante et nécessaire. Il est toutefois désormais évident que cette approche doit s’accompagner d’un changement de mentalité. Même avec le « shift left », les programmes AppSec présentent encore trop d’angles morts pour permettre aux équipes de sécurité et de développement de collaborer efficacement à la réduction des risques applicatifs.

Évaluer la réussite du programme AppSec, aider les développeurs à hiérarchiser les corrections et repérer les applications non sécurisées : autant de défis qui ouvrent la voie à de nouvelles approches AppSec.

Appliquer la « gestion des vulnérabilités » à l’AppSec

L’une de ces approches s’inspire largement de la gestion des vulnérabilités, une méthodologie et une catégorie de solutions de cybersécurité éprouvées et plus vastes, axées sur l’identification, l’évaluation, la documentation, le suivi et la résolution des problèmes de sécurité dans différents domaines d’une entreprise, notamment les terminaux, les réseaux, les systèmes et, bien sûr, les applications.

Au fil du temps, la terminologie désignant cette nouvelle approche a évolué, passant de l’orchestration et de la corrélation de la sécurité applicative (ASOC) à la gestion de la posture de sécurité applicative (ASPM), afin de suivre les tendances du marché. Ses principes fondamentaux, eux, restent les mêmes.

Soutenue par un nombre croissant de fournisseurs, cette approche vise à offrir une « vue unifiée » qui regroupe et met en corrélation les problèmes de sécurité au sein d’un programme AppSec. Elle s’intègre à différentes sources pour donner aux équipes AppSec une vision globale de la posture de sécurité de leurs applications. En s’intégrant également aux outils de gestion et de réponse aux incidents, elle est censée faciliter l’automatisation et la mise en œuvre opérationnelle des processus de priorisation et de correction.

Les limites de la « gestion des vulnérabilités » appliquée à l’AppSec

Une approche de l’AppSec fondée sur la gestion des vulnérabilités présente des avantages et peut répondre aux besoins spécifiques de certains rôles au sein d’une organisation. Une équipe SecOps, par exemple, peut bénéficier d’une vue simplifiée des problèmes de sécurité et de processus automatisés de gestion des réponses. Toutefois, son efficacité pour gérer et déployer la sécurité applicative moderne à grande échelle est discutable, car elle présente deux lacunes majeures.

1. Un manque de contexte applicatif

Comme indiqué précédemment, les approches de l’AppSec fondées sur la gestion des vulnérabilités cherchent à fournir une vue unifiée de tous les problèmes de sécurité détectés par les outils de test de sécurité applicative (AST) utilisés dans le programme, tels que les outils SAST, SCA, DAST, IaC, etc.

Le problème majeur (sans mauvais jeu de mots !) est que cette vue unifiée dépend des données agrégées, principalement issues des nombreux outils AST tiers intégrés. Ces données, obtenues via les API publiques fournies par les éditeurs, varient en format et en structure d’une source à l’autre. Elles nécessitent donc un travail manuel de normalisation et de standardisation coûteux en ressources avant de pouvoir être mises en corrélation. Cela pose un problème crucial : la vue obtenue manque souvent de contexte sur l’application — son importance pour l’entreprise, son architecture, ses actifs et son comportement à l’exécution. Les équipes AppSec ont alors du mal à évaluer efficacement les risques et à collaborer avec les développeurs pour concentrer les efforts de correction là où ils sont réellement nécessaires.

La dépendance excessive aux données de tiers donne une vision fragmentée ou incomplète de la posture de sécurité de l’application, ce qui empêche l’équipe AppSec de prendre des décisions éclairées et d’orienter les développeurs vers des corrections ciblées. Ainsi, malgré les avantages annoncés d’une centralisation de la visibilité sur les problèmes de sécurité, les limites inhérentes à une approche fondée sur la gestion des vulnérabilités constituent un obstacle majeur à une sécurité applicative robuste.

2. Une expérience développeur dégradée

Pour que les équipes AppSec et de développement puissent obtenir des informations sur les risques applicatifs, les développeurs doivent utiliser activement les outils AST mis à leur disposition. De plus, une fois les problèmes détectés, évalués et hiérarchisés, ils doivent rapidement apporter les corrections nécessaires dans leur base de code. Si les développeurs n’adoptent pas leurs outils de sécurité, cette boucle reste incomplète. C’est un résultat probable lorsque ces outils, au lieu d’intégrer harmonieusement les processus de sécurité au workflow de développement, créent des obstacles et des frictions.

Les solutions de sécurité applicative fondées sur les principes de la gestion des vulnérabilités adoptent généralement une approche indépendante des outils. Elles se concentrent avant tout sur le regroupement des problèmes provenant de différents outils AST dans une vue unifiée et fonctionnent souvent sans tenir compte des workflows des développeurs. Il en résulte des processus de priorisation et de correction décousus et inefficaces, qui dégradent l’expérience développeur et fragilisent encore davantage la collaboration déjà tendue entre les équipes AppSec et de développement. Sans participation active des développeurs ni adhésion de leur part, tout programme AppSec est voué à rencontrer des difficultés : la fonction AppSec risque alors d’être perçue comme un adversaire plutôt que comme un allié.

Comment Snyk AppRisk vous aide

Snyk a été un pionnier des outils AST conçus pour les développeurs, afin d’intégrer la sécurité applicative dès les premières étapes du SDLC. Depuis sa création, l’entreprise a déployé à grande échelle la sécurité applicative axée sur les développeurs dans de grandes organisations du monde entier. Conscient des défis qui persistent pour gérer et déployer avec succès à grande échelle une approche moderne de la sécurité applicative « shift left », Snyk a lancé Snyk AppRisk comme couche supplémentaire de sa plateforme de sécurité pour les développeurs. La solution offre aux équipes AppSec des fonctionnalités de découverte et de visibilité des applications, de gestion de la couverture et de priorisation fondée sur les risques.

Snyk AppRisk réoriente les programmes AppSec : au lieu de gérer les problèmes de sécurité un par un, ils peuvent prendre en compte les risques applicatifs dans leur ensemble. Cette approche centrée sur les applications ne se limite pas aux vulnérabilités et aux failles de sécurité. Elle tient également compte de l’architecture, des actifs et du comportement de l’application à l’exécution, afin de fournir une compréhension aussi complète que possible de ses risques de sécurité. Les organisations peuvent ainsi hiérarchiser les mesures de sécurité en fonction de l’importance de l’application pour l’entreprise et de son impact potentiel sur les utilisateurs et les données.

Snyk AppRisk constitue une couche de visibilité, de gouvernance et de priorisation AppSec qui s’ajoute aux produits AST de Snyk conçus pour les développeurs : Snyk Code, Snyk Open Source, Snyk Container et Snyk IaC. Cette intégration et cette interopérabilité transparentes garantissent deux résultats essentiels. Premièrement, les risques applicatifs sont détectés et prévenus dès les premières étapes du cycle de développement, et des analyses de sécurité précises et opportunes sont transmises à Snyk AppRisk. Deuxièmement, les nouveaux risques sont efficacement hiérarchisés et corrigés par les développeurs grâce à des conseils de sécurité et à des corrections concrètes, uniquement lorsque cela est nécessaire.

Pour en savoir plus sur Snyk AppRisk, consultez notre site web ou lisez notre documentation produit.

Lire la suite

Blog

Les modèles de pointe ont trouvé les vulnérabilités. Seul l’attaquant a trouvé les chaînes d’exploitation.

L’analyse statique a détecté les failles, mais seuls des tests d’attaque en conditions réelles ont prouvé comment elles pouvaient être enchaînées pour provoquer des compromissions. Comparaison d’Evo COS, de Claude Security et de Claude Code Security.

feature insights context
Blog

Les attaques autonomes sont déjà là. La défense doit suivre leur rythme.

Les attaquants autonomes réduisent la fenêtre de défense. Découvrez comment la découverte, la correction, la validation et la prévention continues peuvent aider les équipes de sécurité à suivre le rythme.

Blog

Pourquoi les agents de codage IA créent-ils sans cesse des failles de contrôle d’accès ?

Les agents de codage IA peuvent générer une logique d’autorisation qui compile et passe la revue, tout en exposant les données d’un tenant à un autre. Découvrez pourquoi les failles de contrôle d’accès sont difficiles à détecter et comment les prévenir.