Aller au-delà du « shift left » pour étendre l’AppSec dans toutes les directions

Une semaine avant la RSA Conference 2024, Forrester a prédit les sujets et les thèmes qui seraient au cœur de la conférence. Selon Forrester, l’accent serait mis sur la sécurité proactive, définie comme « une approche stratégique visant à maîtriser la posture de sécurité et à réduire les violations grâce à une visibilité, une priorisation et une remédiation efficaces ». 

Je suis arrivé à la conférence en gardant cette prédiction à l’esprit. Pourtant, ce que j’y ai découvert m’a surpris. J’ai malheureusement constaté que de nombreux fournisseurs mettaient encore fortement l’accent sur la seule visibilité des vulnérabilités, sans aborder les autres aspects de la sécurité proactive mentionnés dans la définition ci-dessus. 

Pourtant, les équipes de sécurité et de développement d’aujourd’hui ont besoin d’une approche proactive de la sécurité. Beaucoup se sentent déjà dépassées par la réactivité des processus en place et doivent composer avec des angles morts à chaque étape du SDLC.  Les équipes de sécurité finissent par se concentrer sur les mauvais problèmes et par passer à côté des plus critiques. Elles risquent aussi de ralentir le développement tout en laissant des failles exposées à des risques inconnus. Une approche réactive oblige également les développeurs à gérer de longues listes d’alertes non hiérarchisées et des mesures de sécurité trop rigides. L’attention croissante portée aux applications et l’utilisation accrue de l’IA ne feront qu’aggraver tous ces problèmes. 

Les équipes d’aujourd’hui ont besoin d’une sécurité proactive efficace, fondée sur une priorisation et une remédiation rigoureuses plutôt que sur la seule visibilité. De plus, la visibilité doit porter sur le bon niveau : celui des actifs, comme les applications, et pas seulement sur une vue agrégée des vulnérabilités.

Mais comment, en tant que secteur, dépasser cette approche axée uniquement sur la visibilité ? Il faudrait peut-être repenser ce que signifie le shift left. Il ne s’agit pas seulement d’intervenir plus tôt dans le cycle de développement logiciel, conçu comme un continuum à deux dimensions, mais d’adopter une approche multidirectionnelle de la sécurité. À la RSA Conference, j’ai commencé à envisager ce concept à l’aide d’une boussole métaphorique. Et si, au lieu de nous concentrer sur un mouvement vers la gauche, nous cherchions à étendre la sécurité dans toutes les directions : nord, sud, est et ouest ? 

La sécurité des applications dans toutes les directions

En étendant la sécurité des applications à toutes ces directions métaphoriques, nous pouvons mieux voir et comprendre tout ce qui se passe tout au long du SDLC. Voici comment cette approche pourrait fonctionner :

Nord

Dans le cadre de leur programme AppSec, les équipes de sécurité utilisent plusieurs outils de test de sécurité des applications (AST), tels que le test statique de sécurité des applications (SAST) et l’analyse de la composition logicielle (SCA). Elles s’appuient généralement sur une solution tierce pour agréger et analyser les données de vulnérabilité provenant de ces différents outils et évaluer les résultats de leur programme. 

Cependant, de nombreux outils d’agrégation se concentrent uniquement sur le nombre de vulnérabilités et ignorent ainsi des informations contextuelles essentielles, comme le contexte global de l’application et de l’entreprise. Pour évaluer dans le temps les résultats de leurs programmes de sécurité des applications, les équipes doivent aller au-delà des indicateurs habituels, comme le nombre de vulnérabilités et le délai de résolution. Elles doivent plutôt examiner des données analytiques précieuses concernant les problèmes, la couverture et les actifs propres à l’entreprise. Aller vers le nord, c’est prendre de la hauteur pour voir l’application dans son ensemble et son contexte, plutôt que de considérer chaque vulnérabilité comme un problème isolé.

Sud 

Les équipes de développement et de sécurité ont également besoin d’un meilleur contexte pour chaque alerte. C’est la direction « sud » de notre approche multidirectionnelle : elle consiste à approfondir le contexte de sécurité à chaque étape du développement. Les évaluations traditionnelles des risques, comme le système commun de notation des vulnérabilités (CVSS), ne tiennent pas compte de toutes les données nécessaires pour comprendre le niveau de risque réel d’une vulnérabilité pour l’organisation et déterminer qui doit corriger les problèmes les plus urgents. 

Pour chaque alerte, les équipes doivent plutôt comprendre les facteurs suivants :

• Quelle est la criticité de l’application concernée pour l’entreprise ?

• D’autres facteurs influent-ils sur la criticité des vulnérabilités (par exemple, la sécurité de l’infrastructure cloud, qui offre une protection supplémentaire au code concerné) ?

• Qui a généré le code concerné et est le mieux placé pour corriger les erreurs ?

• Quel type d’actif contient la vulnérabilité ? Cette information peut aider les équipes de développement à déterminer la meilleure façon de résoudre le problème.

Est

Pour mieux évaluer les risques, les entreprises doivent également s’intéresser à la sécurité en exécution : la direction « est » de notre approche. Ce contexte aide les équipes de sécurité à comprendre quel code l’application utilise à l’exécution et quels actifs présentent peu ou pas de risque parce qu’ils ne sont pas utilisés lorsque l’application est exécutée. Il leur permet d’affiner encore la liste des vulnérabilités en écartant les faux positifs liés à des vulnérabilités qui ne menacent pas l’application en cours d’exécution. 

Ouest (c’est-à-dire la gauche)

Le secteur parle depuis déjà quelque temps de l’approche shift left en matière de sécurité. Toutefois, cet engagement à corriger les problèmes dès les premières étapes du cycle de développement doit évoluer au rythme des changements des processus de développement. La définition de la « gauche » continuera d’évoluer, et les équipes de sécurité devront adapter leurs outils et leurs processus à ceux utilisés par les équipes de développement.

Par exemple, les équipes de sécurité constatent aujourd’hui qu’elles doivent accélérer le rythme, car les développeurs utilisent des assistants de codage basés sur l’IA pour générer du code à une vitesse sans précédent. Pour appliquer le shift left en tenant compte de ces changements dans le développement, de nombreuses équipes de sécurité utilisent des outils de sécurité basés sur l’IA afin de sécuriser cette explosion rapide du volume de code sans freiner l’innovation des développeurs.

L’approche multidirectionnelle de Snyk en matière de sécurité

Chez Snyk, nous avons créé une approche de la sécurité des applications qui couvre les quatre directions. Cette stratégie multidirectionnelle a notamment permis à nos clients d’améliorer la productivité des développeurs et de réduire les risques globaux.

Notre dernière solution de gestion de la posture de sécurité des applications (ASPM), Snyk AppRisk Pro, améliore la détection et la priorisation des risques grâce à une meilleure intelligence de l’exécution, à des intégrations supplémentaires avec les plateformes de développement, à une nouvelle compatibilité avec les outils de détection des secrets et à des capacités complètes d’analyse des données. 

Découvrez dès aujourd’hui Snyk AppRisk Pro.