Skip to main content

Votre équipe est-elle sur la liste des sages ou des vilains en matière de *sécurité* ?

Écrit par
feature snyk platform

20 décembre 2023

0 minutes de lecture

Enfants, nous étions nombreux à attendre les fêtes avec impatience, enthousiasme et peut-être même un peu d’appréhension. Avions-nous été assez sages pour recevoir la Gameboy, la maison de rêve de Barbie ou l’Etch A Sketch dont nous rêvions, ou allions-nous simplement recevoir un gros morceau de charbon ?

À l’approche des fêtes, c’est le moment idéal pour se poser la même question dans un autre contexte : cette année, les pratiques de votre organisation en matière d’IA, d’outils de sécurité des applications et d’autres aspects de la sécurité vous placent-elles sur la liste des sages ou des vilains ?

Poursuivez votre lecture pour le découvrir !

Vilain : déployer des mesures de sécurité au coup par coup, au gré des exigences de conformité ou de la direction

Si vous ne prenez pas le temps de répertorier tous les actifs existants de votre organisation, il y a de fortes chances que du code source, des dépendances tierces ou des points de terminaison passent entre les mailles du filet. À l’inverse, vous pourriez aussi, par inadvertance, déployer plusieurs fois des efforts de sécurité sur le même actif et gaspiller des ressources ainsi qu’un budget sécurité précieux !

Sage : réaliser une analyse des lacunes en sécurité des applications pour déterminer comment sécuriser votre environnement dans son ensemble

Une analyse des lacunes AppSec est un excellent point de départ pour sécuriser votre environnement dans son ensemble. Il est judicieux de répertorier vos actifs existants et de les classer selon leur importance pour l’entreprise.

Découvrez d’autres stratégies pour déployer un programme AppSec fondé sur les risques à grande échelle.

Vilain : penser que la sécurité ne fera que ralentir vos processus CI/CD et la reléguer au second plan

Bien mise en œuvre, la sécurité peut accélérer votre pipeline CI/CD au lieu de le ralentir. 2024 sera peut-être l’année où vous cesserez de reléguer la sécurité au second plan et découvrirez comment elle peut soutenir vos processus de développement !

Sage : considérer la sécurité comme un levier — et non un obstacle — pour vos processus existants

Intégrer la sécurité tout au long de votre pipeline CI/CD change la donne. Pensez aux vérifications instantanées du code lors des pull requests, à la modélisation automatisée des menaces et bien plus encore. Un pipeline CI/CD qui tient compte de la sécurité permet aux développeurs d’apprendre les pratiques de codage sécurisé, de créer des produits de meilleure qualité et de contribuer à la posture de sécurité globale de votre organisation.

Découvrez comment créer un pipeline CI/CD qui tient compte de la sécurité.

Vilain : croire que le code écrit par l’IA est bien écrit et sécurisé

L’IA a captivé l’imagination et suscité l’enthousiasme d’innombrables développeurs. Mais ne vous y trompez pas : les interfaces élégantes et les fonctionnalités impressionnantes des assistants de codage IA actuels ne produisent pas de code plus fiable. L’IA s’appuie sur des informations accessibles au public comme données d’entraînement : elle ingère donc du code trouvé partout sur le Web — le bon, le mauvais et le pire — pour apprendre à coder. Autrement dit, vous pouvez partir du principe que l’assistant de codage IA que vous utilisez a le même niveau en programmation qu’un développeur débutant.

Sage : vérifier le code généré par l’IA à l’aide d’analyses de sécurité

Les développeurs du monde entier adorent les outils d’IA et continueront à les utiliser grâce au gain de vitesse impressionnant qu’ils offrent. Cela dit, il est important de vérifier le code généré par l’IA comme vous le feriez pour du code source écrit par un humain, notamment en effectuant des analyses de sécurité en temps réel du code généré par l’IA.

Découvrez comment Snyk peut être le partenaire sécurité de votre code généré par l’IA.

Vilain : prioriser les correctifs de sécurité uniquement selon le score CVSS (critique, élevé, etc.)

Les vulnérabilités critiques font peur. Et cela fait bonne impression d’en corriger un grand nombre et de pouvoir annoncer fièrement : « J’ai corrigé X vulnérabilités critiques ! »

Mais est-il judicieux de commencer par toutes les vulnérabilités critiques et de continuer par ordre décroissant ? Et si une vulnérabilité critique se trouvait sur un site de test rempli de texte factice Lorem Ipsum ? Et si une vulnérabilité moyenne touchait l’une des applications les plus précieuses de votre organisation, utilisée par des milliers de personnes et contenant une grande quantité d’informations sensibles ?

Sage : prioriser les correctifs de sécurité en tenant compte des risques pour l’organisation dans leur ensemble

Le CVSS peut donner une indication du niveau de risque d’une vulnérabilité, mais ne suffit pas à en dresser un tableau complet. C’est pourquoi la gestion de la posture de sécurité des applications (ASPM) est un sujet si actuel. Elle vise à comprendre la posture de sécurité de l’ensemble de votre environnement afin de mieux prioriser les risques. Le contexte applicatif et métier joue alors un rôle plus important dans l’évaluation du risque que représente un problème donné : par exemple, les liens entre les données issues d’une analyse statique de la sécurité des applications (SAST) et les tests de sécurité à l’exécution, entre autres.

Découvrez-en plus sur l’ASPM et sur la façon dont elle fait évoluer notre approche de la sécurité des applications.

Vilain : utiliser des données sensibles dans les prompts d’IA

Comme nous l’avons déjà établi, l’IA ne peut pas être considérée comme fiable à elle seule. Cela vaut aussi pour la manière dont l’IA traite et stocke les données des prompts. Tous les LLM ne disposent pas de contrôles de chiffrement adéquats ni de politiques de sécurité formelles.

Sage : appliquer le principe du moindre privilège lors de l’utilisation des LLM

Vous pouvez fournir certaines données au LLM pour lui donner du contexte dans vos prompts, mais limitez-vous au strict minimum nécessaire pour accomplir la tâche. Il est également conseillé de consulter les politiques de sécurité de l’outil avant de l’utiliser.

Consultez 10 bonnes pratiques pour développer en toute sécurité avec l’IA.

Sage : offrir à vos développeurs le plus beau des cadeaux : les outils de sécurité Snyk, conçus pour les développeurs !

Enfin, selon nos critères, en tout cas. Découvrez dès aujourd’hui Snyk AppRisk pour l’ASPM et notre approche de la sécurité des applications.

Libérez tout le potentiel du DevSecOps avec Snyk

Surmontez la complexité des applications et les hallucinations de l’IA, tout en favorisant la collaboration entre les équipes de développement et de sécurité grâce aux analyses de Snyk et d’Accenture.