Comment les CVE ralentissent la productivité des développeurs
La douleur des CVE
Aucun développeur de logiciels ou ingénieur en sécurité (sain d'esprit) ne se réveille enthousiaste à l'idée de s'occuper des CVE. Ils sont fastidieux, vous déconcentrent et peuvent vous donner l'impression de perdre votre temps. Mais la triste réalité est que, pour des raisons de conformité ou de sécurité, la réduction des vulnérabilités logicielles connues (ou CVE) fait désormais partie du travail quotidien des professionnels du logiciel. C'est pourquoi les développeurs et les équipes de sécurité sont de plus en plus frustrés par la quantité de temps et d'efforts consacrés à la gestion des CVE.
Mes propres recherches sur la gestion des CVE et les conteneurs révèlent à la fois un coût substantiel en termes de temps et des effets négatifs sur le moral du personnel. En substance, les entreprises qui construisent ou exploitent des conteneurs consacrent des milliers d'heures par an au triage des CVE, obligeant les développeurs compétents à chasser les faux positifs et à rassembler des informations confuses au lieu de construire la prochaine application qui fera fureur.
Problème 1 : perte de temps
Le nombre d'heures perdues pour la gestion des CVE est stupéfiant. Dans le rapport The True Cost of CVE Management in Containers de Chainguard, nous avons interrogé des entreprises qui estimaient entre des centaines et des milliers d'heures consacrées annuellement aux tâches liées à l'identification, au triage et à la correction des vulnérabilités. Une entreprise a même consacré l'équivalent de 10 employés à temps plein à ce travail chaque année.
Mais où va tout ce temps ? Le problème est multiple :
Les fausses alertes :
Les scanners de sécurité signalent souvent des vulnérabilités qui ne sont pas pertinentes pour votre conteneur spécifique, ce qui entraîne une perte de temps pour confirmer ou rejeter les alertes.
Informations confuses :
Passer au crible les descriptions des CVE, déchiffrer les niveaux de gravité et trouver des correctifs viables peut s'apparenter à une véritable chasse au trésor. De nombreux développeurs exaspérés finissent par ouvrir des dizaines d'onglets de navigateur pour comprendre une seule vulnérabilité.
Maux de tête liés aux tests et aux dépendances :
Même des mises à jour mineures pour corriger une CVE peuvent déclencher des tests de régression qui prennent beaucoup de temps. La crainte de casser l'application fait hésiter les développeurs, ce qui entraîne des délais encore plus longs.
Problème 2 : Au-delà du temps
Les frustrations liées à la gestion des CVE vont au-delà des heures passées à traquer les vulnérabilités. La lutte constante contre les incendies érode la productivité des développeurs, nuit à la collaboration au sein de l'équipe et augmente potentiellement le risque d'une attaque réussie.
Détérioration du moral :
Le flux constant de CVE - en particulier les faux positifs - est démoralisant. Dans notre rapport annuel
sur les tendances des RSSI et des développeurs en matière de sécurité de la chaîne d'approvisionnement des logiciels, un tiers des développeurs de logiciels interrogés se sont dits convaincus que les faux positifs des outils d'analyse de la composition des logiciels constituaient un obstacle majeur à l'amélioration de la sécurité de la chaîne d'approvisionnement des logiciels.
Déconnexion de la sécurité des conteneurs :
Le même rapport fait état d'un écart important entre les perceptions des développeurs et celles des RSSI. Seuls 43 % des développeurs pensent que les RSSI comprennent les risques liés aux images de conteneurs, tandis que seulement 50 % des RSSI considèrent que les développeurs sont "très sensibilisés à la sécurité" ce qui nuit à la collaboration et accroît les risques de vulnérabilité.
Le risque des chaînes d'exploitation :
Les attaquants ne se contentent pas d'exploiter les principales vulnérabilités. Ils peuvent enchaîner une série de vulnérabilités apparemment mineures pour compromettre une organisation. Cela signifie que même les vulnérabilités de faible gravité doivent faire l'objet d'une attention particulière, ce qui surcharge encore davantage les développeurs.
Les mises à jour bricolées du système d'exploitation peuvent-elles aider ?
Face au fardeau massif des CVE, il est logique de penser que le fait de maintenir vos images de conteneurs à jour avec les derniers paquets du système d'exploitation réduirait considérablement les risques. Après tout, ces mises à jour ne devraient-elles pas inclure des correctifs pour les vulnérabilités connues ? Malheureusement, comme l'a révélé la recherche de Chainguard dans le billet de blog du Zero CVE Challenge, la réalité est bien plus décevante.
Même après avoir mis à jour des images Docker Hub populaires, le nombre moyen de CVE a chuté de moins de six pour cent. Pourquoi ? Parce que même les derniers paquets OS officiels contiennent un grand nombre de CVE préexistantes. Cela oblige les équipes à entrer dans ce même cycle de chasse aux CVE, même après ce qui devrait, en théorie, être un simple correctif.
Des images de conteneurs préconstruites et renforcées sont préférables
La lutte contre les CVE met en évidence la nécessité d'une approche différente. Il est important de corriger continuellement les CVE au fur et à mesure de leur apparition, mais il existe un meilleur moyen d'alléger la charge dès le départ.
Les images Chainguard sont conçues pour avoir peu ou pas de CVE. Elles sont conçues pour être minimales : elles n'utilisent que ce qui est nécessaire à la construction ou à l'exécution d'une application. Ces images, lorsqu'une version d'un composant est disponible, sont mises à jour rapidement. Le résultat est que les développeurs peuvent commencer à travailler avec des conteneurs minimaux et renforcés dès le début de leur développement, ce qui réduit considérablement le nombre de vulnérabilités dès le premier jour. Cela se traduit par :
Du temps pour l'innovation :
Les développeurs consacrent plus de temps à l'élaboration de produits innovants qui génèrent des revenus et satisfont les clients et les utilisateurs, au lieu de courir après des faux positifs bruyants ou de naviguer dans des données CVE confuses.
Une posture de sécurité plus forte :
La minimisation des vulnérabilités réduit considérablement la surface d'attaque, améliorant ainsi la posture de sécurité globale d'une organisation.
Une meilleure collaboration entre les équipes de développement et de sécurité :
Moins de vulnérabilités peut signifier moins de frictions entre les équipes de sécurité et de développement, favorisant une meilleure collaboration sur le travail le plus important pour leur entreprise. Découvrez l'expérience de GitGuardian.
Construire plus vite, en toute sécurité : Découvrez Chainguard Images
Prêt à vous libérer de la perte de temps que représente le CVE ? Explorez Chainguard Images et découvrez comment arrêter de perdre du temps et commencer à construire des logiciels plus sûrs. Contactez notre équipe dès aujourd'hui pour commencer.
Share this article
Articles connexes
- security
Understanding NYDFS and why it matters
Sam Katzen, Staff Product Marketing Manager
- security
Applying SOC 2 with Chainguard: A practical guide for DevOps and engineering leaders
Sam Katzen, Staff Product Marketing Manager
- security
Building digital products for the Cyber Resilience Act
Sam Katzen, Staff Product Marketing Manager
- security
Adapting Essential Eight for modern cloud environments using Chainguard
Cameron Martin, Manager, Sales Engineering, and Scott Norris, Enterprise Sales Engineer
- security
Chainguard FIPS enters 2026 with OpenSSL 3.1.2 and better CMVP visibility
Dimitri John Ledkov, Senior Principal Software Engineer, Chris Herborth, Staff Software Engineer, and John Slack, Senior Product Manager
- security
Why startups need to be secure-by-default
Dan Lorenc, CEO and Co-Founder