{"id":20461,"date":"2023-04-20T09:35:43","date_gmt":"2023-04-20T07:35:43","guid":{"rendered":"https:\/\/www.kaspersky.fr\/blog\/?p=20461"},"modified":"2023-04-20T09:35:43","modified_gmt":"2023-04-20T07:35:43","slug":"open-source-top-10-risks","status":"publish","type":"post","link":"https:\/\/www.kaspersky.fr\/blog\/open-source-top-10-risks\/20461\/","title":{"rendered":"Open source : le top 10 des risques pour les entreprises"},"content":{"rendered":"

Les entreprises informatiques ont \u00e9t\u00e9 les premi\u00e8res \u00e0 utiliser l\u2019open source, puis d\u2019autres grandes entreprises ont suivi. Apr\u00e8s tout, la possibilit\u00e9 de r\u00e9utiliser, modifier ind\u00e9pendamment un code et corriger des bugs a encourag\u00e9 une innovation rapide et une r\u00e9duction des co\u00fbts<\/a>.<\/p>\n

L\u2019open source a tout de m\u00eame quelques caract\u00e9ristiques n\u00e9gatives inh\u00e9rentes, \u00e0 cause du manque de clart\u00e9 quant aux responsabilit\u00e9s en termes de cr\u00e9ation et de maintien du code. Endor Labs, avec l\u2019aide de 20 CISO et CTO de grandes entreprises informatiques, a r\u00e9alis\u00e9 une analyse syst\u00e9matique pour \u00e9laborer ce top 10 des risques<\/a>.<\/p>\n

Les vuln\u00e9rabilit\u00e9s connues<\/h2>\n

Le risque identifi\u00e9 comme \u00e9tant le plus important est la pr\u00e9sence de vuln\u00e9rabilit\u00e9s dans le projet open source lui-m\u00eame et dans ses d\u00e9pendances, c\u2019est-\u00e0-dire dans les composants open source externes utilis\u00e9s pour le projet. Les vuln\u00e9rabilit\u00e9s des d\u00e9pendances peuvent provoquer de graves probl\u00e8mes pour des dizaines de grands ensembles de programmes commerciaux, comme \u00e7a a \u00e9t\u00e9 le cas avec la biblioth\u00e8que Log4j d\u2019Apache (CVE-2021-44228<\/a>).<\/p>\n

Pr\u00e9cautions\u00a0:<\/strong> Analysez r\u00e9guli\u00e8rement les applications pour rechercher les vuln\u00e9rabilit\u00e9s connues, qu\u2019elles soient dans les d\u00e9pendances directes ou indirectes. Installez les corrections disponibles d\u00e8s que possible. Pour optimiser les ressources de votre entreprise, vous pouvez classer les patchs par ordre de priorit\u00e9 selon la s\u00e9v\u00e9rit\u00e9 de la vuln\u00e9rabilit\u00e9 et la probabilit\u00e9 qu\u2019elle soit exploit\u00e9e dans le programme que vous utilisez.<\/p>\n

Les packages l\u00e9gitimes compromis<\/h2>\n

\u00c9tant donn\u00e9 que pr\u00e8s de 80 % du code d\u2019un projet open source provient d\u2019autres projets sous la forme de d\u00e9pendances, il est toujours possible que certains des composants tiers que votre application utilise aient \u00e9t\u00e9 infect\u00e9s par un cheval de Troie. Cela peut arriver lorsque le d\u00e9veloppeur des composants est pirat\u00e9, ou lorsque le syst\u00e8me de distribution des composants (autrement dit, le gestionnaire de package) contient une vuln\u00e9rabilit\u00e9 qui permet le spoofing du paquet. Dans ce cas, un code malveillant tiers appara\u00eet soudainement au sein de l\u2019application qui, en pratique, est souvent utilis\u00e9 pour voler des informations<\/a> ou pour r\u00e9aliser diverses activit\u00e9s illicites d\u2019enrichissement (spam, arnaques avec un adware ou encore minage<\/a>).<\/p>\n

Pr\u00e9cautions :<\/strong> Il n\u2019existe actuellement aucune m\u00e9thodologie m\u00e2ture qui permet de se prot\u00e9ger contre ces menaces. Vous devez utiliser plusieurs mesures \u00e0 la fois\u00a0: des syst\u00e8mes automatiques et manuels qui analysent le code source et surveillent les r\u00e9pertoires<\/a>, le stockage local des versions fiables des composants, et l\u2019utilisation de la Threat Intelligence<\/a> pour d\u00e9tecter ces attaques \u00e0 un stade pr\u00e9coce (avant qu\u2019elles n\u2019aient le temps de nuire aux packages utilis\u00e9s par les applications open source de votre entreprise).<\/p>\n

L\u2019attaque des \u00ab\u00a0homonymes\u00a0\u00bb<\/h2>\n

Les cybercriminels cr\u00e9ent des packages qui ont un nom similaire aux paquets l\u00e9gitimes, ou copient les noms de paquets l\u00e9gitimes \u00e9crits dans un autre langage de programmation ou partag\u00e9s sur d\u2019autres plateformes de distribution. Les d\u00e9veloppeurs de votre application open source risquent d\u2019int\u00e9grer un package malveillant \u00ab\u00a0homonyme\u00a0\u00bb au lieu de l\u2019authentique.<\/p>\n

Pr\u00e9cautions\u00a0:<\/strong> Apprenez \u00e0 vos d\u00e9veloppeurs \u00e0 faire attention. Selon la proc\u00e9dure normale, les d\u00e9veloppeurs doivent v\u00e9rifier le code source des packages avant de l\u2019utiliser et contr\u00f4ler qu\u2019il n\u2019y a rien de bizarre, comme des fragments chiffr\u00e9s dans le code, des fonctions pirat\u00e9es ou autre. Il est \u00e9galement conseill\u00e9 de v\u00e9rifier les signatures \u00e9lectroniques des paquets (le cas \u00e9ch\u00e9ant).<\/p>\n

Le code est incompatible<\/h2>\n

Les d\u00e9veloppeurs de composants, packages et applications open source peuvent interrompre l\u2019assistance \u00e0 tout moment et pour toute raison. Cela arrive souvent avec les petits packages d\u00e9velopp\u00e9s par 1 ou 2 personnes. Si vous \u00eates dans cette situation, personne ne peut mettre \u00e0 jour le paquet pour qu\u2019il soit compatible avec les nouvelles technologies et personne ne peut supprimer les risques de s\u00e9curit\u00e9 informatique.<\/p>\n

Pr\u00e9cautions\u00a0:<\/strong> \u00c9valuez la maturit\u00e9 du projet et les perspectives de d\u00e9veloppement et d\u2019assistance avant de l\u2019int\u00e9grer dans les processus de votre entreprise et dans votre code. Faites attention au nombre de d\u00e9veloppeurs qui permettent le maintien du projet et \u00e0 la fr\u00e9quence de sortie des mises \u00e0 jour. V\u00e9rifiez les versions de support \u00e0 long terme et leur sortie. Pourtant, s\u2019il s\u2019agit d\u2019un projet assez stable, il est normal que les mises \u00e0 jour soient occasionnelles et destin\u00e9es \u00e0 corriger des bugs.<\/p>\n

Le programme est obsol\u00e8te<\/h2>\n

L\u2019utilisation de vieilles versions des composants pour les projets rend l\u2019installation des correctifs plus difficile. Ce probl\u00e8me est particuli\u00e8rement important lorsque le risque le plus grave se pr\u00e9sente\u00a0: les composants sont vuln\u00e9rables. De fa\u00e7on g\u00e9n\u00e9rale, le probl\u00e8me des d\u00e9pendances obsol\u00e8tes appara\u00eet lorsque la nouvelle version d\u2019un composant diff\u00e8re sensiblement de celles des it\u00e9rations pr\u00e9c\u00e9dentes en termes de syntaxe ou de s\u00e9mantique. Dans ce cas, une version obsol\u00e8te peut \u00eatre utilis\u00e9e pendant des ann\u00e9es sans mise \u00e0 jour de s\u00e9curit\u00e9.<\/p>\n

Pr\u00e9cautions\u00a0:<\/strong> Laissez aux d\u00e9veloppeurs le temps de travailler avec les d\u00e9pendances, et notamment de retravailler votre code pour installer les derni\u00e8res versions des composants utilis\u00e9s.<\/p>\n

Les d\u00e9pendances ne sont pas suivies<\/h2>\n

\u00c9tant donn\u00e9 que presque toutes les applications utilisent des composants tiers qui, \u00e0 leur tour, utilisent d\u2019autres composants tiers, il arrive que les d\u00e9veloppeurs de l\u2019application principale ne sachent pas que leur code utilise un composant en particulier. Dans ce cas, ils ne le v\u00e9rifient pas et tous les risques pr\u00e9c\u00e9dents ne sont pas contr\u00f4l\u00e9s.<\/p>\n

Pr\u00e9cautions\u00a0:<\/strong> \u00c9tablissez une nomenclature logistique des programmes (SBOM) d\u00e9taill\u00e9e et utilisez des outils d\u2019analyse capables de d\u00e9tecter les d\u00e9pendances utilis\u00e9es sans gestionnaire de package.<\/p>\n

Les risques r\u00e9glementaires et de licence<\/h2>\n

M\u00eame si c\u2019est open source, chaque application et package open source a sa propre licence d\u2019utilisation. Les risques apparaissent lorsque la licence est incompatible avec l\u2019utilisation de l\u2019application aux fins propos\u00e9es, ou que les licences de certains composants de l\u2019application sont incompatibles. Il se peut aussi qu\u2019un ou plusieurs composants de d\u00e9pendance enfreignent certaines lois ou exigences r\u00e9glementaires en vigueur et impos\u00e9es par l\u2019entreprise.<\/p>\n

Pr\u00e9cautions\u00a0:<\/strong> Le BOM mentionn\u00e9 ci-dessus et les outils d\u2019analyse du code doivent \u00eatre utilis\u00e9s pour contr\u00f4ler les licences et les exigences relatives aux licences qui concernent les applications et les composants open source utilis\u00e9s au sein de l\u2019entreprise. Il convient de travailler avec votre service juridique pour d\u00e9velopper une liste des licences standard applicables \u00e0 l\u2019entreprise et pour d\u00e9tailler leur compatibilit\u00e9 avec le but du programme utilis\u00e9. Les programmes sans licence, ou dont la licence est incompatible, doivent \u00eatre imm\u00e9diatement supprim\u00e9s.<\/p>\n

Le programme est immature<\/h2>\n

L\u2019utilisation de composants d\u00e9velopp\u00e9s par une \u00e9quipe qui manque de maturit\u00e9 implique un certain nombre de d\u00e9sagr\u00e9ments et de risques. Voici certains des probl\u00e8mes associ\u00e9s \u00e0 l\u2019immaturit\u00e9 d\u2019un programme\u00a0: documentation insuffisante ou inexacte du code, instabilit\u00e9, op\u00e9rations sujettes \u00e0 erreur et absence d\u2019un ensemble de tests pour les tests de r\u00e9gression. De plus, le code immature est plus susceptible de contenir des vuln\u00e9rabilit\u00e9s critiques. C\u2019est pour toutes ces raisons que le programme immature n\u2019est pas pratique \u00e0 utiliser et qu\u2019il augmente les co\u00fbts impliqu\u00e9s et les risques d\u2019\u00e9v\u00e9nements critiques ou de temps d\u2019arr\u00eat.<\/p>\n

Pr\u00e9cautions\u00a0:<\/strong> Avant de d\u00e9ployer une application ou un composant, v\u00e9rifiez que les d\u00e9veloppeurs utilisent les meilleures pratiques actuelles. Certains indicateurs sont la possession d\u2019une documentation compl\u00e8te et mise \u00e0 jour, l\u2019existence de pipelines d\u2019int\u00e9gration et de distribution continues (CI\/CD) pour les tests de r\u00e9gression ainsi que la mise \u00e0 disposition d\u2019informations d\u00e9taill\u00e9es sur la couverture des tests et m\u00eame sur le nombre de packages qui utilisent d\u00e9j\u00e0 le composant en question.<\/p>\n

Les modifications ne sont pas approuv\u00e9es<\/h2>\n

Les composants utilis\u00e9s par une application peuvent changer sans que les d\u00e9veloppeurs ne le remarquent. Cette situation peut se produire si les composants sont t\u00e9l\u00e9charg\u00e9s \u00e0 partir d\u2019un serveur sans contr\u00f4le strict de la version et\/ou \u00e0 partir de canaux de communication non chiffr\u00e9s, et ne sont pas v\u00e9rifi\u00e9s \u00e0 l\u2019aide du hachage ou de la signature \u00e9lectronique. Dans ce cas, l\u2019assemblage de l\u2019application peut th\u00e9oriquement avoir un r\u00e9sultat diff\u00e9rent \u00e0 chaque fois.<\/p>\n

Pr\u00e9cautions\u00a0:<\/strong> Soyez strict lorsqu\u2019il s\u2019agit d\u2019appliquer des pratiques de d\u00e9veloppement s\u00fbres. Lors du d\u00e9veloppement, utilisez des identifiants de ressources qui indiquent clairement la version du composant. Ensuite, v\u00e9rifiez les composants t\u00e9l\u00e9charg\u00e9s \u00e0 l\u2019aide des signatures \u00e9lectroniques. Enfin, utilisez toujours des protocoles de communication s\u00e9curis\u00e9s.<\/p>\n

Les d\u00e9pendances sont trop grandes ou trop petites<\/h2>\n

De nos jours, les d\u00e9veloppeurs peuvent int\u00e9grer un composant avec seulement trois lignes de code. D\u2019autre part, la situation est tout aussi mauvaise lorsque le composant entier ne contient que quatre lignes de code (ce qui est tr\u00e8s petit) ou que vous essayez d\u2019utiliser le code pour une seule fonctionnalit\u00e9 parmi les milliers du composant\u00a0; l\u2019application de l\u2019entreprise n\u2019utilise pas les autres. Dans ce cas, les d\u00e9veloppeurs sont charg\u00e9s du maintien d\u2019une multitude de d\u00e9pendances alors qu\u2019il s\u2019agit d\u2019une fonctionnalit\u00e9 tr\u00e8s r\u00e9duite.<\/p>\n

Pr\u00e9cautions\u00a0:<\/strong> \u00c9vitez les d\u00e9pendances avec peu de fonctionnalit\u00e9s. D\u00e9veloppez la fonctionnalit\u00e9 en question au sein de l\u2019application principale<\/p>\n","protected":false},"excerpt":{"rendered":"

Les applications open source exigent une mise en place et une maintenance ad\u00e9quates sinon l\u2019entreprise pourrait rencontrer diverses menaces. Nous mettons l\u2019accent sur les risques principaux.<\/p>\n","protected":false},"author":2722,"featured_media":20462,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[2112,3150],"tags":[379,1983,1246,4369,914],"class_list":{"0":"post-20461","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-business","8":"category-enterprise","9":"tag-applications","10":"tag-business","11":"tag-developpement","12":"tag-open-source","13":"tag-risques"},"hreflang":[{"hreflang":"fr","url":"https:\/\/www.kaspersky.fr\/blog\/open-source-top-10-risks\/20461\/"},{"hreflang":"en-in","url":"https:\/\/www.kaspersky.co.in\/blog\/open-source-top-10-risks\/25497\/"},{"hreflang":"en-ae","url":"https:\/\/me-en.kaspersky.com\/blog\/open-source-top-10-risks\/20930\/"},{"hreflang":"en-us","url":"https:\/\/usa.kaspersky.com\/blog\/open-source-top-10-risks\/28106\/"},{"hreflang":"en-gb","url":"https:\/\/www.kaspersky.co.uk\/blog\/open-source-top-10-risks\/25804\/"},{"hreflang":"es-mx","url":"https:\/\/latam.kaspersky.com\/blog\/open-source-top-10-risks\/26221\/"},{"hreflang":"es","url":"https:\/\/www.kaspersky.es\/blog\/open-source-top-10-risks\/28706\/"},{"hreflang":"ru","url":"https:\/\/www.kaspersky.ru\/blog\/open-source-top-10-risks\/35092\/"},{"hreflang":"x-default","url":"https:\/\/www.kaspersky.com\/blog\/open-source-top-10-risks\/47875\/"},{"hreflang":"pt-br","url":"https:\/\/www.kaspersky.com.br\/blog\/open-source-top-10-risks\/21153\/"},{"hreflang":"de","url":"https:\/\/www.kaspersky.de\/blog\/open-source-top-10-risks\/30029\/"},{"hreflang":"ru-kz","url":"https:\/\/blog.kaspersky.kz\/open-source-top-10-risks\/26124\/"},{"hreflang":"en-au","url":"https:\/\/www.kaspersky.com.au\/blog\/open-source-top-10-risks\/31809\/"},{"hreflang":"en-za","url":"https:\/\/www.kaspersky.co.za\/blog\/open-source-top-10-risks\/31496\/"}],"acf":[],"banners":"","maintag":{"url":"https:\/\/www.kaspersky.fr\/blog\/tag\/open-source\/","name":"open source"},"_links":{"self":[{"href":"https:\/\/www.kaspersky.fr\/blog\/wp-json\/wp\/v2\/posts\/20461","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=20461"}],"version-history":[{"count":3,"href":"https:\/\/www.kaspersky.fr\/blog\/wp-json\/wp\/v2\/posts\/20461\/revisions"}],"predecessor-version":[{"id":20465,"href":"https:\/\/www.kaspersky.fr\/blog\/wp-json\/wp\/v2\/posts\/20461\/revisions\/20465"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.kaspersky.fr\/blog\/wp-json\/wp\/v2\/media\/20462"}],"wp:attachment":[{"href":"https:\/\/www.kaspersky.fr\/blog\/wp-json\/wp\/v2\/media?parent=20461"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.kaspersky.fr\/blog\/wp-json\/wp\/v2\/categories?post=20461"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.kaspersky.fr\/blog\/wp-json\/wp\/v2\/tags?post=20461"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}