![\"\"](\"https:\/\/media.jfrog.com\/wp-content\/uploads\/2022\/09\/01175034\/863x300.png\")
<\/p>\n<\/p>\n
Le code cr\u00e9\u00e9 par les d\u00e9veloppeurs d'une organisation ne constitue que le commencement du d\u00e9veloppement d'un logiciel moderne. En fait, la premi\u00e8re partie du code est susceptible de n'\u00eatre qu'une portion succincte d'une application\u00a0; parfois, elle ne constitue que 10\u00a0% de l'\u00e9cosyst\u00e8me de l'artefact de l'application<\/a>.<\/p>\n La cha\u00eene d'approvisionnement de logiciels d'une entreprise comporte plusieurs \u00e9l\u00e9ments, puis\u00e9s dans de nombreuses ressources\u00a0: packages open source, logiciels commerciaux, fichiers infrastructure-as-code (IaC), conteneurs et images SE, entre autres. Cette diversit\u00e9 signifie que la cha\u00eene d'approvisionnement que vous devez s\u00e9curiser comptabilise de nombreuses situations \u00e0 risque<\/em> et menaces en mati\u00e8re de s\u00e9curit\u00e9 en raison d'erreurs, de supervision, de mauvaise qualit\u00e9 ou d'attaque malveillante.<\/p>\n Il est important de comprendre o\u00f9 se trouvent ces situations \u00e0 risque vuln\u00e9rables<\/em> pour s\u00e9curiser votre cha\u00eene d'approvisionnement de logiciels. Mais les r\u00e9soudre une par une avec des solutions uniques revient \u00e0 jouer au jeu du chat et de la souris\u00a0; une menace \u00e9radiqu\u00e9e peut tout simplement r\u00e9appara\u00eetre dans un autre endroit auquel vous n'auriez pas pens\u00e9.<\/p>\n La protection compl\u00e8te de votre cha\u00eene d'approvisionnement de logiciels contre les menaces requiert une vigilance de bout en bout. Cela commence m\u00eame avant que le d\u00e9veloppeur n'appelle un package externe\u00a0; cette protection est n\u00e9cessaire dans le d\u00e9veloppement du code propri\u00e9taire, la compilation du code, les versions pr\u00e9liminaires, le pipeline, la publication, la distribution, la production, voire m\u00eame apr\u00e8s le d\u00e9ploiement. En plus de r\u00e9v\u00e9ler simplement les vuln\u00e9rabilit\u00e9s et d'autres probl\u00e8mes de s\u00e9curit\u00e9, vous devrez \u00e9galement conna\u00eetre leur contexte afin de pouvoir \u00e9valuer le v\u00e9ritable risque.<\/p>\n Les menaces de la cha\u00eene d'approvisionnement de logiciels peuvent \u00eatre (approximativement) divis\u00e9es en deux chemins principaux.<\/p>\n Le premier utilise la cha\u00eene d'approvisionnement \u00ab\u00a0nature ouverte\u00a0\u00bb pour obtenir des informations sur le logiciel<\/em> que l'attaquant entend cibler. Un exemple courant serait une tentative d'un adversaire de mapper un service Web \u00e0 distance ou de d\u00e9poser un logiciel pour des appareils IdO afin de se familiariser avec les packages open source qu'il utilise. Il peut ensuite facilement trouver des informations sur des CVE associ\u00e9s \u00e0 de tels packages, en apprendre davantage sur les configurations de s\u00e9curit\u00e9 des packages, voire m\u00eame tenter de trouver des vuln\u00e9rabilit\u00e9s inconnues (appel\u00e9es \u00ab\u00a0zero day\u00a0\u00bb). Lorsqu'il a suffisamment de connaissances sur les chemins d'exploitation, l'attaquant peut ensuite passer \u00e0 la seconde phase.<\/p>\n Cette phase consiste \u00e0 utiliser la cha\u00eene d'approvisionnement pour injecter du code et des packages malveillants<\/em> dans des d\u00e9p\u00f4ts publics ou priv\u00e9s, ou modifier du code existant et y int\u00e9grer des \u00e9l\u00e9ments malveillants.<\/p>\n Attaques de la cha\u00eene d\u2019approvisionnement de logiciels\u00a0: Deux chemins principaux<\/em><\/p>\n Examinons quatre risques majeurs qui menacent la cha\u00eene d'approvisionnement de logiciels et peuvent la rendre vuln\u00e9rable aux attaques\u00a0:<\/p>\n Les composants de tiers, comme un logiciel commercial et open source, peuvent comprendre des vuln\u00e9rabilit\u00e9s involontaires qui sont g\u00e9n\u00e9ralement connues et publiquement suivies dans la liste Common Vulnerabilities and Exposure<\/a> (CVE, exposition et vuln\u00e9rabilit\u00e9s courantes).<\/p>\n Vous pouvez r\u00e9v\u00e9ler de tels risques avec une solution Software Component Analysis (SCA, analyse des composants du logiciel)<\/a> qui identifie le SBOM d'un code donn\u00e9 ou artefact et l'associe avec des CVE connues, g\u00e9n\u00e9ralement en croisant les m\u00e9tadonn\u00e9es du logiciel identifi\u00e9 avec les bases de donn\u00e9es CVE publiques.<\/p>\n Mais vous devrez \u00e9galement avoir suffisamment d'informations pour pouvoir prendre des d\u00e9cisions bas\u00e9es sur les risques et les automatiser<\/a>. Une base de donn\u00e9es externe est un atout\u00a0; elle doit traquer non seulement plus de risques, mais inclure \u00e9galement une recherche de s\u00e9curit\u00e9<\/a> approfondie pouvant vous aider \u00e0 comprendre toutes les options afin d'att\u00e9nuer ces risques et vous permettre de choisir la m\u00e9thode la plus pratique et la plus rentable.<\/p>\n Une analyse contextuelle<\/a> qui identifie la probabilit\u00e9 qu'une vuln\u00e9rabilit\u00e9 soit exploit\u00e9e est tout aussi importante. Par exemple, la fonction vuln\u00e9rable dans un composant ne peut pas \u00eatre utilis\u00e9e par l'application ou un processus vuln\u00e9rable n'est jamais ex\u00e9cut\u00e9 dans une version de production, ou une configuration sp\u00e9cifique rend une CVE donn\u00e9e inutile.<\/p>\n Vous pouvez \u00e9galement reconna\u00eetre des risques op\u00e9rationnels<\/a> \u00e9ventuels de composants qui semblent \u00eatre s\u00fbrs. Par exemple, un package open source qui n'a pas \u00e9t\u00e9 g\u00e9r\u00e9 pendant un temps peut ne pas avoir \u00e9t\u00e9 suffisamment surveill\u00e9 pour rep\u00e9rer des probl\u00e8mes de s\u00e9curit\u00e9. Dans ces cas, les vuln\u00e9rabilit\u00e9s sont incertaines, mais une menace potentielle peut \u00eatre anticip\u00e9e.<\/p>\n Ces risques anticip\u00e9s et connus peuvent et devraient \u00eatre rep\u00e9r\u00e9s aux niveaux suivants\u00a0:<\/p>\n Les erreurs constituent une part quotidienne du codage. Les failles de logique, un mauvais chiffrement et des corruptions de m\u00e9moire potentielles rendent involontairement les applications vuln\u00e9rables aux attaques malveillantes comme une ex\u00e9cution de code \u00e0 distance (RCE) et une attaque par d\u00e9ni de service (DoS). Ces erreurs peuvent \u00eatre non d\u00e9tect\u00e9es dans le code principal ou tiers, parfois pendant des ann\u00e9es<\/a>.<\/p>\n Ces erreurs sont appel\u00e9es des probl\u00e8mes \u00ab\u00a0zero day\u00a0\u00bb, en partie pour la p\u00e9riode durant laquelle elles sont connues, mais aussi parce que leur urgence signifie que les \u00e9quipes n'ont pas le temps de les corriger dans le logiciel d\u00e9j\u00e0 d\u00e9ploy\u00e9.<\/p>\n Pour cerner et \u00e9viter les probl\u00e8mes \u00ab\u00a0zero day\u00a0\u00bb potentiels, vous devez tester chaque composant et\/ou application, en prenant en compte le flux entre les diff\u00e9rents fichiers binaires, processus et services. Les outils d'analyse de code statique (pour examiner la source du code) et d'examen dynamique du code (pour tester le code ex\u00e9cut\u00e9) peuvent habituellement identifier environ 85\u00a0% des failles, mais ils peuvent g\u00e9n\u00e9rer des milliers d'entr\u00e9es par version. Un savoir-faire est donc requis pour interpr\u00e9ter les r\u00e9sultats et les prioriser. Tout comme avec les probl\u00e8mes connus, une vuln\u00e9rabilit\u00e9 peut exister, mais cela ne signifie pas qu'elle est n\u00e9cessairement exploitable.<\/p>\n Des technologies plus avanc\u00e9es qui combinent une ex\u00e9cution symbolique, une analyse du flux de donn\u00e9es et un test \u00e0 donn\u00e9es al\u00e9atoires automatis\u00e9 peuvent r\u00e9duire consid\u00e9rablement le taux de faux positif et identifier les vuln\u00e9rabilit\u00e9s qui ne peuvent pas \u00eatre rep\u00e9r\u00e9es par un SAST\/DAST typique. La combinaison de l'analyse des fichiers binaires et source peut \u00e9galement produire de meilleurs r\u00e9sultats et permettre aux d\u00e9veloppeurs, \u00e9quipes de s\u00e9curit\u00e9 et gestionnaires de production de se focaliser sur les corrections qui importent.<\/p>\n En d\u00e9pit de tous les efforts, de nouvelles vuln\u00e9rabilit\u00e9s peuvent toujours \u00eatre potentiellement d\u00e9couvertes et impacter le logiciel d\u00e9ploy\u00e9. Un scan SCA continu peut permettre de garantir une notification rapide des derni\u00e8res CVE qui affectent le logiciel de production. Des m\u00e9tadonn\u00e9es de logiciels de nomenclature<\/a> riches vous permettent de conna\u00eetre rapidement l'impact d'une vuln\u00e9rabilit\u00e9 dans votre organisation et d'att\u00e9nuer ou de r\u00e9soudre le probl\u00e8me dans tout l'inventaire d'applications<\/a>. Une int\u00e9gration correcte avec les d\u00e9p\u00f4ts d'artefact et de code permet de prendre des mesures rapidement dans votre organisation et d'att\u00e9nuer la menace identifi\u00e9e.<\/p>\n Toutes les vuln\u00e9rabilit\u00e9s ne concernent pas le code\u00a0; elles peuvent appara\u00eetre dans les fichiers binaires comme les EPM, les conteneurs de fichiers JAR, les micrologiciels et les artefacts de soutien comme les fichiers de configuration ou les fichiers IaC. Des mauvaises configurations, un mauvais chiffrement, une exposition des secrets et cl\u00e9s priv\u00e9es ou des probl\u00e8mes de syst\u00e8me d'exploitation peuvent ouvrir une surface d'attaque.<\/p>\n Ces sous-produits de l'erreur humaine sont g\u00e9n\u00e9ralement dus \u00e0 un manque d'attention plut\u00f4t qu'\u00e0 une malveillance et sont g\u00e9n\u00e9ralement introduits en dehors du d\u00e9veloppement majeur. Les configurations constitu\u00e9es pour le test peuvent \u00eatre inconsid\u00e9r\u00e9ment envoy\u00e9es en production. Ces risques sont souvent faciles \u00e0 r\u00e9soudre, mais difficiles \u00e0 rep\u00e9rer et encore plus \u00e0 r\u00e9parer.<\/p>\n M\u00eame une bonne intention peut avoir des cons\u00e9quences malveillantes. La plus c\u00e9l\u00e8bre est la violation SolarWinds<\/a> qui a commenc\u00e9 avec un mot de passe expos\u00e9 sur un serveur public GitHub<\/a>, permettant l'injection d'un code malveillant qui a fini par d\u00e9voiler des donn\u00e9es gouvernementales sensibles. Une confusion de d\u00e9pendance<\/a> entre des packages ayant des noms similaires peut \u00e9galement se produire sans malveillance, notamment lorsque la r\u00e9solution de d\u00e9p\u00f4t de package<\/a> est mal configur\u00e9e.<\/p>\n Il est capital de rep\u00e9rer rapidement ces probl\u00e8mes avant qu'ils ne progressent dans la production. Vous devrez prendre ces risques potentiels au s\u00e9rieux, autant que les vuln\u00e9rabilit\u00e9s dans votre code, et int\u00e9grer cette vigilance dans la posture de s\u00e9curit\u00e9 de bout en bout de vos pipelines.<\/p>\n Les menaces intentionnelles, qu'elles soient dues \u00e0 des attaques d'injection externes ou \u00e0 des initi\u00e9s malveillants, peuvent \u00eatre les plus difficiles \u00e0 trouver, car elles sont souvent masqu\u00e9es afin d'appara\u00eetre comme un composant d\u00e9j\u00e0 valid\u00e9. Les chevaux de Troie, les bots, les ran\u00e7ongiciels, les cryptominers et les logiciels espions sont souvent d\u00e9livr\u00e9s comme des charges utiles via les types de vuln\u00e9rabilit\u00e9s introduits avec une bonne volont\u00e9, comme vu ci-dessus. L'amor\u00e7age de d\u00e9p\u00f4ts populaires avec des packages nuisibles, le piratage de comptes de maintenance pour modifier des packages existants ou l'injection de code dans des d\u00e9p\u00f4ts source compromis sont des m\u00e9thodes fr\u00e9quemment utilis\u00e9es qui permettent l'acc\u00e8s d\u00e9rob\u00e9 pour une attaque.<\/p>\n Il est g\u00e9n\u00e9ralement trop tard lorsque l'on trouve ces attaques apr\u00e8s le d\u00e9ploiement\u00a0; les dommages ont \u00e9t\u00e9 caus\u00e9s et ils peuvent \u00eatre vraiment on\u00e9reux. C'est pourquoi vous devriez vous prot\u00e9ger dans tout votre pipeline\u00a0:<\/p>\n Bien que certaines de ces tendances de risques puissent \u00eatre g\u00e9r\u00e9es une \u00e0 la fois, les solutions sont simplement des syst\u00e8mes d'alarme et uniquement utiles l\u00e0 o\u00f9 vous pensez \u00e0 les placer.<\/p>\n Pour la m\u00eame raison, des solutions de s\u00e9curit\u00e9 s\u00e9par\u00e9es ont une utilit\u00e9 limit\u00e9e car leur port\u00e9e r\u00e9duite ne peut pas vous permettre d'analyser et d'\u00e9valuer le contexte global d'un risque dans toute la cha\u00eene d'approvisionnement de logiciels. Lorsque vous \u00eates d\u00e9connect\u00e9 des d\u00e9p\u00f4ts et des solutions de gestion de logiciels, m\u00eame si les solutions de s\u00e9curit\u00e9 sont tr\u00e8s pr\u00e9cises, il serait extr\u00eamement difficile de prendre des mesures efficaces pour r\u00e9soudre et att\u00e9nuer le probl\u00e8me identifi\u00e9.<\/p>\n Une posture de s\u00e9curit\u00e9 exhaustive ne peut pas simplement se focaliser sur des points isol\u00e9s de votre pipeline\u00a0; elle doit vous permettre d'\u00e9tablir un lien entre les diff\u00e9rents probl\u00e8mes et les constatations en mati\u00e8re de s\u00e9curit\u00e9\u00a0; chose que les solutions de niche s\u00e9par\u00e9es ne peuvent pas faire.<\/p>\n La s\u00e9curit\u00e9 des logiciels requiert une vigilance int\u00e9grale, des IDE des d\u00e9veloppeurs \u00e0 la production, imposant une surveillance des risques constante et permettant la mitigation des environnements de d\u00e9veloppement et de production. Vos solutions de s\u00e9curit\u00e9 doivent agir globalement sur votre cha\u00eene d'approvisionnement de logiciels et vous permettre de prendre des mesures \u00e0 grande \u00e9chelle. Afin de s\u00e9curiser de mani\u00e8re coh\u00e9rente votre organisation, elles doivent agir contre une source d'informations unique pour tous vos fichiers binaires<\/a> et \u00eatre bien int\u00e9gr\u00e9es avec des outils DevOps.<\/p>\nLes quatre tendances en mati\u00e8re de risque concernant la cha\u00eene d'approvisionnement de logiciels<\/h2>\n
![\"Software](\"https:\/\/media.jfrog.com\/wp-content\/uploads\/2022\/09\/22202257\/Software-supply-chain-attacks-Two-main-paths.png\")
<\/p>\n1. Vuln\u00e9rabilit\u00e9s connues<\/h3>\n
\n
2. Vuln\u00e9rabilit\u00e9s inconnues (\u00ab\u00a0zero days\u00a0\u00bb)<\/h3>\n
3. Probl\u00e8mes ne concernant pas le code<\/h3>\n
4. Code Malveillant<\/h3>\n
\n
Une vigilance int\u00e9grale pour la gestion des risques de la cha\u00eene d'approvisionnement de logiciels<\/h2>\n