Linus Torvalds, le cr\u00e9ateur de Linux et de Git, a sa propre loi en mati\u00e8re de d\u00e9veloppement logiciel, et \u00e7a se passe comme \u00e7a : “\u00e9tant donn\u00e9 suffisamment de globes oculaires, tous les bogues sont superficiels<\/em>. ” Cette phrase met le doigt sur le principe m\u00eame de l’open source\u00a0: plus on en a, mieux c’est – si le code est facilement accessible \u00e0 tous pour corriger les bogues, c’est assez s\u00fbr. Mais est-ce le cas\u00a0? Ou est-ce que le dicton “tous les bogues sont peu profonds” seulement vrai pour peu profond<\/em> des bugs et non ceux qui sont plus profonds\u00a0? Il s’av\u00e8re que les failles de s\u00e9curit\u00e9 dans l’open source peuvent \u00eatre plus difficiles \u00e0 trouver que nous ne le pensions. Emil W\u00e5reus, responsable R&D chez D\u00e9briqu\u00e9<\/a>, a pris sur lui d’approfondir les performances de la communaut\u00e9. En tant que data scientist qu’il est, il a bien s\u00fbr demand\u00e9 aux donn\u00e9es\u00a0: dans quelle mesure la communaut\u00e9 open source est-elle capable de trouver des vuln\u00e9rabilit\u00e9s en temps opportun\u00a0?<\/em>?<\/p>\n La recherche de vuln\u00e9rabilit\u00e9s open source est g\u00e9n\u00e9ralement effectu\u00e9e par les responsables du projet open source, les utilisateurs, les auditeurs ou les chercheurs externes en s\u00e9curit\u00e9. Mais malgr\u00e9 ces grands arch\u00e9ologues du code qui aident \u00e0 s\u00e9curiser notre monde, la communaut\u00e9 a toujours du mal \u00e0 trouver des failles de s\u00e9curit\u00e9. <\/p>\n En moyenne, il faut plus de 800 jours<\/em> pour d\u00e9couvrir une faille de s\u00e9curit\u00e9 dans les projets open source. Par exemple, la fameuse vuln\u00e9rabilit\u00e9 Log4shell (CVE-2021-44228) n’a pas \u00e9t\u00e9 d\u00e9couverte pendant 2649 jours. <\/p>\n L’analyse montre que 74% des failles de s\u00e9curit\u00e9 sont en fait non d\u00e9couvertes pendant au moins un an ! Java et Ruby semblent avoir le plus de d\u00e9fis ici, car il faut plus de 1000 jours \u00e0 la communaut\u00e9 pour trouver et divulguer les vuln\u00e9rabilit\u00e9s. Notre [white] Chapeau \u00e0 la communaut\u00e9 PHP\/Composer, qui surpasse l\u00e9g\u00e8rement les autres. <\/p>\n D’autres facteurs int\u00e9ressants sont que certains des diff\u00e9rents types de faiblesses (CWE) semblent \u00eatre plus difficiles \u00e0 trouver et \u00e0 divulguer, ce qui contredit en fait la loi de Linus. Les types de faiblesses CWE-400 (consommation de ressources non contr\u00f4l\u00e9es) et CWE-502 (d\u00e9s\u00e9rialisation de donn\u00e9es non approuv\u00e9es) ne sont g\u00e9n\u00e9ralement pas localis\u00e9s dans une seule fonction ou peuvent appara\u00eetre comme la logique pr\u00e9vue dans l’application. En d’autres termes, cela ne peut pas \u00eatre consid\u00e9r\u00e9 comme “un bogue superficiel”. <\/p>\n Il semble \u00e9galement que la communaut\u00e9 des d\u00e9veloppeurs soit un peu meilleure pour trouver CWE-20 (Improper Input Validation), o\u00f9 la faille la plupart du temps n’est que quelques lignes de code dans une seule fonction. <\/p>\n Pourquoi est-ce important ? En tant que consommateurs d’open source, et c’est \u00e0 peu pr\u00e8s toutes les entreprises du monde entier, le probl\u00e8me des vuln\u00e9rabilit\u00e9s de l’open source est important. Les donn\u00e9es nous indiquent que nous ne pouvons pas enti\u00e8rement faire confiance \u00e0 la loi de Linus – non pas parce que l’open source est moins s\u00e9curis\u00e9 que d’autres logiciels, mais parce que tous les bugs ne sont pas superficiels<\/strong>.<\/p>\n Heureusement, il existe des outils puissants pour effectuer une analyse \u00e0 grande \u00e9chelle de nombreux projets open source \u00e0 la fois. Il y a eu [white knight hackers disclose 1000’s<\/a>] des vuln\u00e9rabilit\u00e9s \u00e0 la fois en utilisant ces m\u00e9thodes. Il serait na\u00eff de ne pas supposer que les organisations et les individus mal intentionn\u00e9s font de m\u00eame. En tant qu’\u00e9cosyst\u00e8me qui jette les bases de notre monde centr\u00e9 sur les logiciels, la communaut\u00e9 doit am\u00e9liorer consid\u00e9rablement sa capacit\u00e9 \u00e0 trouver, divulguer et corriger les failles de s\u00e9curit\u00e9 dans l’open source. <\/p>\n L’ann\u00e9e derni\u00e8re, Google a engag\u00e9 10 milliards de dollars<\/a> \u00e0 un fonds open source pour aider \u00e0 s\u00e9curiser l’open source avec un r\u00f4le de conservateur sp\u00e9cifique pour travailler aux c\u00f4t\u00e9s des mainteneurs avec des efforts de s\u00e9curit\u00e9 sp\u00e9cifiques. <\/p>\n De plus, Debricked aide les entreprises \u00e0 rendre ces vuln\u00e9rabilit\u00e9s exploitables en analysant tous vos logiciels, chaque branche, chaque push et chaque commit, \u00e0 la recherche de nouvelles vuln\u00e9rabilit\u00e9s (open source). Debricked analyse m\u00eame en continu tous vos anciens commits pour chaque nouvelle vuln\u00e9rabilit\u00e9, afin de s’assurer qu’ils apportent des informations \u00e0 jour, pr\u00e9cises et exploitables sur l’open source que vous consommez. Debricked aide m\u00eame les d\u00e9veloppeurs \u00e0 corriger vos failles de s\u00e9curit\u00e9 avec des demandes d’extraction automatis\u00e9es qui ne causeront pas d’enfer de d\u00e9pendance ; g\u00e9nial! <\/p>\n Alors, sachant tout cela, quelle est la meilleure fa\u00e7on de prot\u00e9ger votre projet ou votre entreprise contre les vuln\u00e9rabilit\u00e9s open source ? Comme nous l’avons vu dans le cas de Log4j et Spring4shell ainsi que les chiffres, nous ne pouvons jamais vraiment croire que la communaut\u00e9 trouvera et corrigera tous les risques. Il y a de fortes chances qu’il y ait beaucoup de vuln\u00e9rabilit\u00e9s non d\u00e9couvertes et non divulgu\u00e9es dans votre code aujourd’hui, et vous ne pouvez pas y faire grand-chose. <\/p>\n Selon Debricked, la meilleure fa\u00e7on d’att\u00e9nuer ce probl\u00e8me consiste \u00e0 mettre en \u0153uvre une analyse continue des vuln\u00e9rabilit\u00e9s sur votre SDLC. En analysant automatiquement \u00e0 chaque pouss\u00e9e de code, en combinaison avec l’apprentissage automatique base de donn\u00e9es des vuln\u00e9rabilit\u00e9s<\/a>. Cela garantit que vous \u00eates mis \u00e0 jour en temps r\u00e9el, vous serez au courant des nouvelles vuln\u00e9rabilit\u00e9s avant tout le monde. D\u00e8s qu’il y a un correctif, vous pouvez g\u00e9n\u00e9rer un Correction de la demande d’extraction<\/a> automatiquement ou r\u00e9solvez-le manuellement avec l’aide de Debricked. Actuellement, Debricked propose une correction pour JavaScript et Go, avec plus de prise en charge linguistique \u00e0 venir sous peu. <\/em><\/p>\n <\/p>\n<\/div>\nLe frisson de la (vuln\u00e9rabilit\u00e9) chasse<\/strong><\/h2>\n
![\"Vuln\u00e9rabilit\u00e9s](\"https:\/\/teknomers.com\/fr\/wp-content\/uploads\/2022\/11\/1667313151_987_Open-Source-de-lannee-derniere-Vulnerabilites-de-demain.jpg\" "\\"Vuln\u00e9rabilit\u00e9s")
<\/div>\nL’aiguille dans une pile technologique<\/strong><\/h2>\n
![\"Vuln\u00e9rabilit\u00e9s](\"https:\/\/thehackernews.com\/new-images\/img\/b\/R29vZ2xl\/AVvXsEjMcHcgVAMCZdOLqkgBI2vwxfxloDUpyM00TN6hWNXm2XuP6xMEA6rxvm6SSzpLbxnWheflWn2NzzpG28KssHYhTkxqvgPCreYfJUptqQ466Jvgjav1oC_3pRbCDqLGVNtbUmUGhmdO_mv8yRBolaXWeQr91wJXBpvD3XjYa4h945ZbgYI8puChOJYh\/s728-e1000\/bugs.jpg\" "\\"Vuln\u00e9rabilit\u00e9s")
<\/div>\nR\u00e9solvez les vuln\u00e9rabilit\u00e9s avec une correction puissante <\/strong><\/h2>\n
La v\u00e9rit\u00e9 r\u00e9side dans les donn\u00e9es<\/h2>\n