Linus Torvalds, le créateur de Linux et de Git, a sa propre loi en matière de développement logiciel, et ça se passe comme ça : « étant donné suffisamment de globes oculaires, tous les bogues sont superficiels.  » Cette phrase met le doigt sur le principe même de l’open source : plus on en a, mieux c’est – si le code est facilement accessible à tous pour corriger les bogues, c’est assez sûr. Mais est-ce le cas ? Ou est-ce que le dicton « tous les bogues sont peu profonds » seulement vrai pour peu profond des bugs et non ceux qui sont plus profonds ? Il s’avère que les failles de sécurité dans l’open source peuvent être plus difficiles à trouver que nous ne le pensions. Emil Wåreus, responsable R&D chez Débriqué, a pris sur lui d’approfondir les performances de la communauté. En tant que data scientist qu’il est, il a bien sûr demandé aux données : dans quelle mesure la communauté open source est-elle capable de trouver des vulnérabilités en temps opportun ??

Le frisson de la (vulnérabilité) chasse

La recherche de vulnérabilités open source est généralement effectuée par les responsables du projet open source, les utilisateurs, les auditeurs ou les chercheurs externes en sécurité. Mais malgré ces grands archéologues du code qui aident à sécuriser notre monde, la communauté a toujours du mal à trouver des failles de sécurité.

En moyenne, il faut plus de 800 jours pour découvrir une faille de sécurité dans les projets open source. Par exemple, la fameuse vulnérabilité Log4shell (CVE-2021-44228) n’a pas été découverte pendant 2649 jours.

L’analyse montre que 74% des failles de sécurité sont en fait non découvertes pendant au moins un an ! Java et Ruby semblent avoir le plus de défis ici, car il faut plus de 1000 jours à la communauté pour trouver et divulguer les vulnérabilités. Notre [white] Chapeau à la communauté PHP/Composer, qui surpasse légèrement les autres.

L’aiguille dans une pile technologique

D’autres facteurs intéressants sont que certains des différents types de faiblesses (CWE) semblent être plus difficiles à trouver et à divulguer, ce qui contredit en fait la loi de Linus. Les types de faiblesses CWE-400 (consommation de ressources non contrôlées) et CWE-502 (désérialisation de données non approuvées) ne sont généralement pas localisés dans une seule fonction ou peuvent apparaître comme la logique prévue dans l’application. En d’autres termes, cela ne peut pas être considéré comme « un bogue superficiel ».

Il semble également que la communauté des développeurs soit un peu meilleure pour trouver CWE-20 (Improper Input Validation), où la faille la plupart du temps n’est que quelques lignes de code dans une seule fonction.

Résolvez les vulnérabilités avec une correction puissante

Pourquoi est-ce important ? En tant que consommateurs d’open source, et c’est à peu près toutes les entreprises du monde entier, le problème des vulnérabilités de l’open source est important. Les données nous indiquent que nous ne pouvons pas entièrement faire confiance à la loi de Linus – non pas parce que l’open source est moins sécurisé que d’autres logiciels, mais parce que tous les bugs ne sont pas superficiels.

Heureusement, il existe des outils puissants pour effectuer une analyse à grande échelle de nombreux projets open source à la fois. Il y a eu [white knight hackers disclose 1000’s] des vulnérabilités à la fois en utilisant ces méthodes. Il serait naïf de ne pas supposer que les organisations et les individus mal intentionnés font de même. En tant qu’écosystème qui jette les bases de notre monde centré sur les logiciels, la communauté doit améliorer considérablement sa capacité à trouver, divulguer et corriger les failles de sécurité dans l’open source.

L’année dernière, Google a engagé 10 milliards de dollars à un fonds open source pour aider à sécuriser l’open source avec un rôle de conservateur spécifique pour travailler aux côtés des mainteneurs avec des efforts de sécurité spécifiques.

De plus, Debricked aide les entreprises à rendre ces vulnérabilités exploitables en analysant tous vos logiciels, chaque branche, chaque push et chaque commit, à la recherche de nouvelles vulnérabilités (open source). Debricked analyse même en continu tous vos anciens commits pour chaque nouvelle vulnérabilité, afin de s’assurer qu’ils apportent des informations à jour, précises et exploitables sur l’open source que vous consommez. Debricked aide même les développeurs à corriger vos failles de sécurité avec des demandes d’extraction automatisées qui ne causeront pas d’enfer de dépendance ; génial!

La vérité réside dans les données

Alors, sachant tout cela, quelle est la meilleure façon de protéger votre projet ou votre entreprise contre les vulnérabilités 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é trouvera et corrigera tous les risques. Il y a de fortes chances qu’il y ait beaucoup de vulnérabilités non découvertes et non divulguées dans votre code aujourd’hui, et vous ne pouvez pas y faire grand-chose.

Selon Debricked, la meilleure façon d’atténuer ce problème consiste à mettre en œuvre une analyse continue des vulnérabilités sur votre SDLC. En analysant automatiquement à chaque poussée de code, en combinaison avec l’apprentissage automatique base de données des vulnérabilités. Cela garantit que vous êtes mis à jour en temps réel, vous serez au courant des nouvelles vulnérabilités avant tout le monde. Dès qu’il y a un correctif, vous pouvez générer un Correction de la demande d’extraction automatiquement ou résolvez-le manuellement avec l’aide de Debricked. Actuellement, Debricked propose une correction pour JavaScript et Go, avec plus de prise en charge linguistique à venir sous peu.