{"id":23828,"date":"2026-04-21T10:17:03","date_gmt":"2026-04-21T08:17:03","guid":{"rendered":"https:\/\/www.kaspersky.fr\/blog\/?p=23828"},"modified":"2026-04-21T12:00:18","modified_gmt":"2026-04-21T10:00:18","slug":"managing-open-source-vulnerabilities","status":"publish","type":"post","link":"https:\/\/www.kaspersky.fr\/blog\/managing-open-source-vulnerabilities\/23828\/","title":{"rendered":"Architecture open source de gestion des vuln\u00e9rabilit\u00e9s"},"content":{"rendered":"<p>Comme nous l\u2019avons d\u00e9j\u00e0 \u00e9voqu\u00e9 <a href=\"https:\/\/www.kaspersky.fr\/blog\/open-source-vulnerabilities-in-ai-era\/23821\/\" target=\"_blank\" rel=\"noopener\">dans un article pr\u00e9c\u00e9dent<\/a>, le d\u00e9veloppement logiciel moderne est pratiquement inconcevable sans le recours \u00e0 des composants open source. Cependant, ces derni\u00e8res ann\u00e9es, les risques associ\u00e9s sont devenus de plus en plus vari\u00e9s, complexes et nombreux. Premi\u00e8rement, lorsque les vuln\u00e9rabilit\u00e9s touchent l\u2019infrastructure et le code d\u2019une entreprise plus rapidement qu\u2019elles ne sont corrig\u00e9es, deuxi\u00e8mement, lorsque les donn\u00e9es sont peu fiables et incompl\u00e8tes, et troisi\u00e8mement, lorsque des programmes malveillants peuvent se cacher dans des composants courants, il ne suffit pas de se contenter de v\u00e9rifier les num\u00e9ros de version et d\u2019envoyer des requ\u00eates de d\u00e9pannage \u00e0 l\u2019\u00e9quipe informatique. La gestion des vuln\u00e9rabilit\u00e9s doit \u00eatre \u00e9tendue afin de couvrir les strat\u00e9gies de t\u00e9l\u00e9chargement de logiciels, les mesures de s\u00e9curit\u00e9 pour les assistants d\u2019IA et l\u2019ensemble du processus de d\u00e9veloppement logiciel.<\/p>\n<h1>Une s\u00e9lection fiable de composants open source<\/h1>\n<p>L\u2019essentiel de la solution consiste \u00e0 emp\u00eacher l\u2019utilisation de code vuln\u00e9rable et malveillant. Les mesures suivantes devraient \u00eatre mises en \u0153uvre\u00a0:<\/p>\n<ul>\n<li>Disposer d\u2019un r\u00e9pertoire interne d\u2019artefacts. La seule source de composants pour le d\u00e9veloppement interne doit \u00eatre un d\u00e9p\u00f4t unifi\u00e9 dans lequel les composants ne sont int\u00e9gr\u00e9s qu\u2019apr\u00e8s une s\u00e9rie de v\u00e9rifications.<\/li>\n<li>Proc\u00e9der \u00e0 un contr\u00f4le rigoureux des composants. Ces v\u00e9rifications portent notamment sur : les versions connues du composant, les versions connues pour \u00eatre vuln\u00e9rables ou malveillantes, la date de publication, l\u2019historique d\u2019activit\u00e9, ainsi que la r\u00e9putation du paquet et de ses auteurs. Il est imp\u00e9ratif d\u2019analyser l\u2019int\u00e9gralit\u00e9 du contenu du paquet, y compris les instructions de compilation, les cas de test et les autres donn\u00e9es auxiliaires. Pour filtrer le registre lors de l\u2019ingestion, utilisez des scanners open source sp\u00e9cialis\u00e9s ou une <a href=\"https:\/\/www.kaspersky.fr\/enterprise-security\/cloud-workload-security?icid=fr_kdailyplacehold_acq_ona_smm__onl_b2b_kdaily_wpplaceholder_sm-team_______72b910b5700f7fc8\" target=\"_blank\" rel=\"noopener\">solution compl\u00e8te de s\u00e9curit\u00e9 des charges de travail dans le cloud<\/a>.<\/li>\n<li>Appliquer l\u2019\u00e9pinglage de d\u00e9pendances. Les processus de compilation, les outils d\u2019IA et les d\u00e9veloppeurs ne doivent pas recourir \u00e0 des versions non fig\u00e9es (telles que \u00a0\u00bb\u00a0latest\u00a0\u00ab\u00a0). Les compilations de projets doivent s\u2019appuyer sur des versions v\u00e9rifi\u00e9es. Par ailleurs, les d\u00e9pendances \u00e9pingl\u00e9es doivent \u00eatre r\u00e9guli\u00e8rement mises \u00e0 jour vers les derni\u00e8res versions v\u00e9rifi\u00e9es, qui garantissent la compatibilit\u00e9 et ne pr\u00e9sentent aucune vuln\u00e9rabilit\u00e9 connue. Cela r\u00e9duit consid\u00e9rablement le risque d\u2019<a href=\"https:\/\/www.kaspersky.com\/blog\/npm-packages-trojanized\/54280\/\" target=\"_blank\" rel=\"noopener nofollow\">attaques contre la cha\u00eene d\u2019approvisionnement li\u00e9es \u00e0 la compromission d\u2019un paquet connu<\/a>.<\/li>\n<\/ul>\n<h1>Am\u00e9lioration des donn\u00e9es de vuln\u00e9rabilit\u00e9<\/h1>\n<p>Pour identifier plus efficacement les vuln\u00e9rabilit\u00e9s et les <a href=\"https:\/\/www.kaspersky.fr\/blog\/cvss-rbvm-vulnerability-management\/22997\/\" target=\"_blank\" rel=\"noopener\">hi\u00e9rarchiser<\/a> correctement, une organisation doit mettre en place plusieurs processus informatiques et de s\u00e9curit\u00e9\u00a0:<\/p>\n<ul>\n<li>Enrichissement des donn\u00e9es relatives aux vuln\u00e9rabilit\u00e9s. Selon les besoins de l\u2019organisation, cette \u00e9tape est n\u00e9cessaire soit pour enrichir les informations en combinant les donn\u00e9es provenant du NVD, de l\u2019EUVD, du BDU, de la base de donn\u00e9es d\u2019alertes GitHub et d\u2019osv.dev, soit pour acheter un flux commercial de renseignements sur les vuln\u00e9rabilit\u00e9s dans lequel les donn\u00e9es sont d\u00e9j\u00e0 agr\u00e9g\u00e9es et enrichies. Dans tous les cas, il est utile de suivre \u00e9galement les flux d\u2019informations sur les menaces afin de rep\u00e9rer les tendances d\u2019exploitation r\u00e9elles et de mieux cerner le profil des pirates qui ciblent des vuln\u00e9rabilit\u00e9s sp\u00e9cifiques. Kaspersky propose un <a href=\"https:\/\/www.kaspersky.com\/open-source-feed?icid=fr_kdailyplacehold_acq_ona_smm__onl_b2b_blo_wpplaceholder________dd0f74eb94b1411c\" target=\"_blank\" rel=\"noopener nofollow\">flux de donn\u00e9es d\u00e9di\u00e9 sp\u00e9cifiquement aux composants open source<\/a>.<\/li>\n<li>Analyse approfondie de la composition des logiciels. Des outils sp\u00e9cialis\u00e9s d\u2019analyse de la composition des logiciels (SCA) permettent de parcourir la cha\u00eene de d\u00e9pendances du code open source afin de recenser l\u2019ensemble des biblioth\u00e8ques utilis\u00e9es et d\u2019identifier les composants obsol\u00e8tes ou non pris en charge. Les donn\u00e9es relatives aux composants sains sont \u00e9galement utiles pour enrichir le registre d\u2019artefacts.<\/li>\n<li>Identification des abandonwares. M\u00eame si un composant n\u2019est pas officiellement consid\u00e9r\u00e9 comme vuln\u00e9rable et n\u2019a pas \u00e9t\u00e9 officiellement d\u00e9clar\u00e9 comme n\u2019\u00e9tant plus pris en charge, le processus d\u2019analyse doit signaler les composants qui n\u2019ont pas re\u00e7u de mises \u00e0 jour depuis plus d\u2019un an. Ceux-ci justifient une analyse distincte et un remplacement \u00e9ventuel, tout comme les composants en fin de vie.<\/li>\n<\/ul>\n<h1>S\u00e9curisation du code et des agents d\u2019IA<\/h1>\n<p>Les activit\u00e9s des syst\u00e8mes d\u2019IA utilis\u00e9s dans le codage doivent s\u2019accompagner d\u2019un ensemble complet de mesures de s\u00e9curit\u00e9, allant du filtrage des donn\u00e9es entrantes \u00e0 la formation des utilisateurs\u00a0:<\/p>\n<ul>\n<li>Restrictions sur les recommandations de d\u00e9pendance. Assurez-vous que l\u2019environnement de d\u00e9veloppement soit configur\u00e9 de mani\u00e8re \u00e0 ce que les agents assistants d\u2019IA ne puissent acc\u00e9der qu\u2019aux composants et biblioth\u00e8ques provenant du registre d\u2019artefacts de confiance. Si ceux-ci ne contiennent pas les bons outils, le mod\u00e8le devrait d\u00e9clencher une requ\u00eate pour inclure la d\u00e9pendance dans le registre, plut\u00f4t que de r\u00e9cup\u00e9rer sur PyPI un \u00e9l\u00e9ment qui correspond simplement \u00e0 la description.<\/li>\n<li>Filtrage des r\u00e9sultats du mod\u00e8le. Malgr\u00e9 ces restrictions, tout ce qui est g\u00e9n\u00e9r\u00e9 par le mod\u00e8le doit \u00e9galement \u00eatre v\u00e9rifi\u00e9 afin de s\u2019assurer que le code g\u00e9n\u00e9r\u00e9 par l\u2019IA ne contient pas de d\u00e9pendances obsol\u00e8tes, non prises en charge, vuln\u00e9rables ou fictives. Cette v\u00e9rification doit \u00eatre int\u00e9gr\u00e9e directement au processus de validation du code ou \u00e0 la phase de pr\u00e9paration de la compilation. Elle ne remplace pas le processus d\u2019analyse statique traditionnel\u00a0: les outils SAST doivent toujours \u00eatre int\u00e9gr\u00e9s au pipeline CI\/CD.<\/li>\n<li>Formation des d\u00e9veloppeurs. Les \u00e9quipes informatiques et de s\u00e9curit\u00e9 doivent bien conna\u00eetre les caract\u00e9ristiques des syst\u00e8mes d\u2019IA, leurs principes de fonctionnement et les erreurs courantes. Pour ce faire, les employ\u00e9s doivent suivre une <a href=\"https:\/\/xtraining.kaspersky.com\/?icid=gl_kdailyplacehold_acq_ona_smm__onl_b2b_kasperskydaily_wpplaceholder____\" target=\"_blank\" rel=\"noopener\">formation sp\u00e9cialis\u00e9e<\/a> adapt\u00e9e \u00e0 leurs postes.<\/li>\n<\/ul>\n<h1>Suppression syst\u00e9matique des composants EOL<\/h1>\n<p>Si les syst\u00e8mes d\u2019une entreprise utilisent des composants open source obsol\u00e8tes, il convient d\u2019adopter une approche syst\u00e9matique et coh\u00e9rente pour rem\u00e9dier \u00e0 leurs vuln\u00e9rabilit\u00e9s. Pour ce faire, il existe trois m\u00e9thodes principales\u00a0:<\/p>\n<ul>\n<li>Migration. Il s\u2019agit de la m\u00e9thode la plus complexe sur le plan organisationnel et la plus co\u00fbteuse, car elle implique le remplacement complet d\u2019un composant, suivi de l\u2019adaptation, de la r\u00e9\u00e9criture ou du remplacement des applications bas\u00e9es sur celui-ci. La d\u00e9cision de proc\u00e9der \u00e0 une migration est particuli\u00e8rement intimidante lorsqu\u2019elle n\u00e9cessite une refonte compl\u00e8te de l\u2019ensemble du code interne. Cela touche souvent les composants essentiels\u00a0: il est en effet impossible de migrer facilement \u00e0 partir de Node.js 14 ou de Python\u00a02.<\/li>\n<li>Assistance \u00e0 long terme (LTS). Il existe un march\u00e9 d\u00e9di\u00e9 aux services d\u2019assistance pour les projets h\u00e9rit\u00e9s de grande envergure. Cela implique parfois la cr\u00e9ation d\u2019une version d\u00e9riv\u00e9e du syst\u00e8me existant, g\u00e9r\u00e9e par des d\u00e9veloppeurs tiers. Dans d\u2019autres cas, des \u00e9quipes sp\u00e9cialis\u00e9es adaptent des correctifs destin\u00e9s \u00e0 corriger des vuln\u00e9rabilit\u00e9s sp\u00e9cifiques \u00e0 des versions plus anciennes qui ne sont plus prises en charge. Le passage \u00e0 une version avec support \u00e0 long terme (LTS) implique g\u00e9n\u00e9ralement des frais de maintenance, mais, dans de nombreux cas, cette solution peut n\u00e9anmoins s\u2019av\u00e9rer plus \u00e9conomique qu\u2019une migration compl\u00e8te.<\/li>\n<li>Mesures compensatoires. Gr\u00e2ce aux r\u00e9sultats d\u2019une analyse approfondie, il est possible de mettre en place <a href=\"https:\/\/www.kaspersky.com\/blog\/legacy-it-update-troubles-and-mitigations\/48692\/\" target=\"_blank\" rel=\"noopener nofollow\">un ensemble de mesures de s\u00e9curit\u00e9 globales visant \u00e0 r\u00e9duire le risque d\u2019exploitation des vuln\u00e9rabilit\u00e9s pr\u00e9sentes dans le produit existant<\/a>. L\u2019efficacit\u00e9 et la viabilit\u00e9 \u00e9conomique de cette approche d\u00e9pendent toutes deux du r\u00f4le que joue le logiciel au sein de l\u2019organisation.<\/li>\n<\/ul>\n<p>Les services de s\u00e9curit\u00e9, informatiques et op\u00e9rationnels doivent collaborer afin de choisir l\u2019une de ces trois options pour chaque composant d\u00e9clar\u00e9 obsol\u00e8te ou abandonn\u00e9, et consigner ce choix dans les registres d\u2019actifs et les SBOM de l\u2019entreprise.<\/p>\n<h1>Gestion des vuln\u00e9rabilit\u00e9s open source bas\u00e9e sur les risques<\/h1>\n<p>Toutes les mesures \u00e9num\u00e9r\u00e9es ci-dessus permettent de r\u00e9duire le nombre de logiciels et de composants vuln\u00e9rables qui s\u2019introduisent dans l\u2019organisation, et facilitent la d\u00e9tection et la correction des failles. N\u00e9anmoins, il est impossible d\u2019\u00e9liminer tous les probl\u00e8mes\u00a0: le nombre d\u2019applications et de composants augmente tout simplement trop rapidement.<\/p>\n<p>Il est donc essentiel de <a href=\"https:\/\/www.kaspersky.fr\/blog\/cvss-rbvm-vulnerability-management\/22997\/\" target=\"_blank\" rel=\"noopener\">hi\u00e9rarchiser les vuln\u00e9rabilit\u00e9s en fonction des risques r\u00e9els<\/a>. Le mod\u00e8le d\u2019\u00e9valuation des risques doit \u00eatre \u00e9largi afin de tenir compte des particularit\u00e9s des logiciels open source, en apportant des r\u00e9ponses aux questions suivantes\u00a0:<\/p>\n<ul>\n<li>La branche de code vuln\u00e9rable est-elle r\u00e9ellement ex\u00e9cut\u00e9e dans l\u2019environnement de l\u2019organisation\u00a0? Il convient de r\u00e9aliser une analyse de l\u2019accessibilit\u00e9 des vuln\u00e9rabilit\u00e9s d\u00e9tect\u00e9es. De nombreux extraits de code d\u00e9fectueux ne sont en r\u00e9alit\u00e9 jamais ex\u00e9cut\u00e9s dans le cadre de la mise en \u0153uvre de l\u2019organisation, ce qui rend la vuln\u00e9rabilit\u00e9 impossible \u00e0 exploiter. Certaines solutions SCA permettent d\u2019effectuer cette analyse. Ce m\u00eame processus permet d\u2019\u00e9valuer un autre sc\u00e9nario\u00a0: que se passerait-il si les proc\u00e9dures ou composants vuln\u00e9rables \u00e9taient enti\u00e8rement supprim\u00e9s du projet\u00a0? Parfois, cette m\u00e9thode de rem\u00e9diation s\u2019av\u00e8re \u00e9tonnamment simple.<\/li>\n<li>Cette vuln\u00e9rabilit\u00e9 est-elle exploit\u00e9e dans le cadre d\u2019attaques r\u00e9elles\u00a0? Une preuve de concept est-elle disponible\u00a0? Les r\u00e9ponses \u00e0 ces questions s\u2019inscrivent dans le cadre de m\u00e9thodes standard de hi\u00e9rarchisation telles que l\u2019EPSS, mais le suivi doit s\u2019appuyer sur un ensemble beaucoup plus large de sources de renseignements.<\/li>\n<li>Une activit\u00e9 cybercriminelle a-t-elle \u00e9t\u00e9 signal\u00e9e dans ce registre de d\u00e9pendances ou dans des composants connexes et similaires\u00a0? Il s\u2019agit l\u00e0 de facteurs suppl\u00e9mentaires \u00e0 prendre en compte pour \u00e9tablir les priorit\u00e9s.<\/li>\n<\/ul>\n<p>En tenant compte de ces facteurs, l\u2019\u00e9quipe est en mesure d\u2019allouer efficacement ses ressources et de corriger en priorit\u00e9 les probl\u00e8mes les plus graves.<\/p>\n<h1>La transparence est la nouvelle tendance<\/h1>\n<p>Le niveau d\u2019exigence en mati\u00e8re de s\u00e9curit\u00e9 pour les logiciels open source ne fera que continuer \u00e0 augmenter. Les entreprises qui d\u00e9veloppent des applications (m\u00eame pour un usage interne) seront confront\u00e9es \u00e0 des exigences r\u00e9glementaires imposant une cybers\u00e9curit\u00e9 document\u00e9e et v\u00e9rifiable au sein de leurs syst\u00e8mes. Selon les <a href=\"https:\/\/www.sonatype.com\/state-of-the-software-supply-chain\/introduction\" target=\"_blank\" rel=\"noopener nofollow\">estimations des experts de Sonatype<\/a>, 90 % des entreprises \u00e0 l\u2019\u00e9chelle mondiale sont d\u00e9j\u00e0 soumises \u00e0 une ou plusieurs exigences les obligeant \u00e0 fournir des preuves de la fiabilit\u00e9 des logiciels qu\u2019elles utilisent. C\u2019est pourquoi ces experts consid\u00e8rent la transparence comme \u00ab\u00a0la monnaie d\u2019\u00e9change de la s\u00e9curit\u00e9 de la cha\u00eene d\u2019approvisionnement logicielle\u00a0\u00bb.<\/p>\n<p>En contr\u00f4lant l\u2019utilisation des composants et applications open source, en enrichissant les donn\u00e9es de Threat Intelligence et en surveillant de pr\u00e8s les syst\u00e8mes de d\u00e9veloppement bas\u00e9s sur l\u2019IA, les entreprises peuvent apporter les innovations dont elles ont besoin, tout en r\u00e9pondant aux exigences \u00e9lev\u00e9es impos\u00e9es tant par les r\u00e9gulateurs que par les clients.<\/p>\n<input type=\"hidden\" class=\"category_for_banner\" value=\"mdr\"><input type=\"hidden\" class=\"placeholder_for_banner\" data-cat_id=\"mdr\" value=\"21073\">\n","protected":false},"excerpt":{"rendered":"<p>Comment g\u00e9rer les vuln\u00e9rabilit\u00e9s lors du d\u00e9veloppement ou de l&rsquo;utilisation de logiciels open source.<\/p>\n","protected":false},"author":2722,"featured_media":23830,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[2112,3150],"tags":[4598,4407,4544,3383,4369,4201,322],"class_list":{"0":"post-23828","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-business","8":"category-enterprise","9":"tag-agents","10":"tag-correctifs","11":"tag-cvss","12":"tag-ia","13":"tag-open-source","14":"tag-strategie","15":"tag-vulnerabilites"},"hreflang":[{"hreflang":"fr","url":"https:\/\/www.kaspersky.fr\/blog\/managing-open-source-vulnerabilities\/23828\/"},{"hreflang":"en-in","url":"https:\/\/www.kaspersky.co.in\/blog\/managing-open-source-vulnerabilities\/30368\/"},{"hreflang":"en-ae","url":"https:\/\/me-en.kaspersky.com\/blog\/managing-open-source-vulnerabilities\/25418\/"},{"hreflang":"en-gb","url":"https:\/\/www.kaspersky.co.uk\/blog\/managing-open-source-vulnerabilities\/30215\/"},{"hreflang":"es","url":"https:\/\/www.kaspersky.es\/blog\/managing-open-source-vulnerabilities\/32024\/"},{"hreflang":"it","url":"https:\/\/www.kaspersky.it\/blog\/managing-open-source-vulnerabilities\/30614\/"},{"hreflang":"ru","url":"https:\/\/www.kaspersky.ru\/blog\/managing-open-source-vulnerabilities\/41643\/"},{"hreflang":"tr","url":"https:\/\/www.kaspersky.com.tr\/blog\/managing-open-source-vulnerabilities\/14472\/"},{"hreflang":"x-default","url":"https:\/\/www.kaspersky.com\/blog\/managing-open-source-vulnerabilities\/55554\/"},{"hreflang":"pt-br","url":"https:\/\/www.kaspersky.com.br\/blog\/managing-open-source-vulnerabilities\/24913\/"},{"hreflang":"de","url":"https:\/\/www.kaspersky.de\/blog\/managing-open-source-vulnerabilities\/33403\/"},{"hreflang":"ru-kz","url":"https:\/\/blog.kaspersky.kz\/managing-open-source-vulnerabilities\/30484\/"},{"hreflang":"en-au","url":"https:\/\/www.kaspersky.com.au\/blog\/managing-open-source-vulnerabilities\/36103\/"},{"hreflang":"en-za","url":"https:\/\/www.kaspersky.co.za\/blog\/managing-open-source-vulnerabilities\/35755\/"}],"acf":[],"banners":"","maintag":{"url":"https:\/\/www.kaspersky.fr\/blog\/tag\/vulnerabilites\/","name":"Vuln\u00e9rabilit\u00e9s"},"_links":{"self":[{"href":"https:\/\/www.kaspersky.fr\/blog\/wp-json\/wp\/v2\/posts\/23828","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.kaspersky.fr\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.kaspersky.fr\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.kaspersky.fr\/blog\/wp-json\/wp\/v2\/users\/2722"}],"replies":[{"embeddable":true,"href":"https:\/\/www.kaspersky.fr\/blog\/wp-json\/wp\/v2\/comments?post=23828"}],"version-history":[{"count":5,"href":"https:\/\/www.kaspersky.fr\/blog\/wp-json\/wp\/v2\/posts\/23828\/revisions"}],"predecessor-version":[{"id":23835,"href":"https:\/\/www.kaspersky.fr\/blog\/wp-json\/wp\/v2\/posts\/23828\/revisions\/23835"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.kaspersky.fr\/blog\/wp-json\/wp\/v2\/media\/23830"}],"wp:attachment":[{"href":"https:\/\/www.kaspersky.fr\/blog\/wp-json\/wp\/v2\/media?parent=23828"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.kaspersky.fr\/blog\/wp-json\/wp\/v2\/categories?post=23828"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.kaspersky.fr\/blog\/wp-json\/wp\/v2\/tags?post=23828"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}