Le code source ouvert est public, mais les bonnes personnes le regardent-elles ?

Les perceptions de la sécurité inhérente au code et aux logiciels à source ouverte varient - mais ces perceptions sont importantes.

D'un côté, certains considèrent que le code source ouvert est moins sûr. Après tout, il y a moins d'incitations commerciales à sécuriser un code à source ouverte qu'un code écrit par un fournisseur à but lucratif dont la réputation est en jeu.

D'un autre côté, certains pensent que le code source ouvert est plus sûr simplement parce qu'il est ouvert à l'examen. L'argument est que cette ouverture l'emporte sur toute incitation commerciale. Le fait qu'un plus grand nombre de personnes examinent le code source ouvert devrait faciliter l'identification des failles de ce dernier.

Dans cet article, nous examinons de plus près l'"ouverture" du code source ouvert et les avantages en matière de sécurité qu'elle devrait apporter, mais qui ne sont pas toujours au rendez-vous. Nous examinerons également le point de vue selon lequel, en fait, trop de mauvaises personnes examinent le code source ouvert à la recherche d'opportunités, et trop peu de bonnes personnes s'efforcent de trouver et de corriger les failles de sécurité.

Sommaire :

1. LE CODE SOURCE OUVERT OFFRE CERTAINS AVANTAGES EN MATIÈRE DE SÉCURITÉ
2. LES ENTREPRISES DÉPENDENT DE L'OPEN-SOURCE, MAIS CONSIDÈRENT LA SÉCURITÉ COMME ACQUISE...
3. PIRE, CE SONT LES MAUVAISES PERSONNES QUI REGARDENT LE CODE OPEN-SOURCE
4. IL Y A UN "BON" EXAMEN, MAIS...
5. Mesures incitatives et sensibilisation

Le code source ouvert offre certains avantages en matière de sécurité

Premièrement, il existe des raisons valables pour lesquelles le code à source ouverte est perçu comme étant plus sûr que le code à source fermée. Il existe des arguments raisonnables qui soulignent pourquoi, dans certaines circonstances, le code à source ouvert peut offrir des avantages en matière de sécurité.

L'idée principale est que, puisque le code source ouvert est public et ouvert à l'examen, davantage de personnes l'examinent. Lorsque le code est largement utilisé, il devrait être examiné de plus près pour détecter les failles de sécurité. Par conséquent, le code devrait être plus sûr, car les failles seront trouvées et corrigées plus rapidement. Toutefois, cela peut ne pas être le cas pour le code utilisé dans des projets plus petits, dans des bibliothèques de code ou dans du code hautement spécialisé.

Le deuxième avantage du code source ouvert en matière de sécurité est que les entreprises qui l'utilisent peuvent réparer plus rapidement les failles avant que celles-ci ne deviennent dangereuses. Plus rapidement, en tout cas, qu'en s'appuyant sur un fournisseur commercial qui peut avoir besoin de passer par des tests approfondis de son code propriétaire.

Si l'on considère ces deux arguments isolément, on peut avoir l'impression que le code source ouvert est une meilleure option en raison de ses avantages en matière de sécurité, mais c'est un point de vue qui passe à côté de quelques points essentiels.

Les entreprises dépendent de l'open source, mais considèrent la sécurité comme acquise...

Presque toutes les entreprises déploient du code à source ouverte à grande échelle. Elles peuvent le faire explicitement, en utilisant un produit tel que Red Hat Enterprise Linux, ou implicitement, car même les logiciels fermés sous licence commerciale contiennent des sources ouvertes.

Une analyse effectuée par Synopsis en 2020 a révélé que 99 % des bases de code auditées pour le rapport contenaient du code open-source. Une grande partie de ce code est également ancienne, avec 91% du code audité pour le rapport contenant du code open-source qui n'a pas été mis à jour depuis quatre ans ou plus.

En fait, peu importe que votre entreprise déploie explicitement ou non des solutions open-source, le code open-source est tellement omniprésent que vous devez prendre la menace au sérieux.

Malheureusement, les entreprises considèrent souvent la sécurité des logiciels libres comme allant de soi. Soit parce qu'elles ne se rendent pas compte de la quantité de code open source qui supporte leurs charges de travail, soit en raison des avantages de sécurité perçus du code open source.

Il s'agit d'une approche risquée et il existe d'innombrables exemples de la façon dont de grandes entreprises fournissant des services clés sont prises en défaut par une faille dans un code open-source. L'un des exemples les plus marquants est la brèche d'Equifax en 2017, qui a exposé les dossiers financiers très personnels de plus de 147 millions de personnes.

Dans le cas de la violation d'Equifax, les pirates ont exploité un code vulnérable dans Apache Struts 2, un framework utilisé par le portail du site web d'Equifax. Il a fallu six semaines à l'entreprise pour s'apercevoir de la violation, ce qui a entraîné le vol d'un très grand nombre de données. Pour Equifax, le coût a été immense, tant en termes de règlement financier que, bien sûr, de retombées publiques.

L'exemple d'Equifax est loin d'être unique. Une partie du problème réside dans le fait que les développeurs peuvent facilement et rapidement intégrer à leurs applications toute une série de fonctionnalités de source ouverte. Des gros blocs de fonctionnalités aux bibliothèques individuelles.

Ils le feraient sans véritable examen - et souvent sans cataloguer les composants. Le résultat est que les entreprises ont peu d'idée du code open-source dont dépendent leurs solutions technologiques. Pourtant, il est presque certain que le code à source ouvert se cachera à peu près partout.

Pire, les mauvaises personnes regardent le code open-source.

Tout le monde peut examiner le code source ouvert, y compris les méchants. L'omniprésence du code source ouvert incite les acteurs malveillants à rechercher des failles susceptibles d'être exploitées.

Dans certains cas, cette chasse est simplement motivée par l'appât du gain : les criminels veulent trouver des moyens de pirater des systèmes pour voler des informations précieuses ou demander une rançon à une entreprise. D'autres groupes, allant des équipes de lutte contre les menaces persistantes avancées (APT) aux acteurs étatiques, ont des objectifs spécifiques qu'ils peuvent atteindre en exploitant les faiblesses de la sécurité.

La découverte de failles dans un code open-source largement utilisé donne à ces acteurs les outils dont ils ont besoin pour s'introduire dans des systèmes autrement sécurisés. Parfois, les acteurs malveillants identifient les failles du code source ouvert bien avant que les utilisateurs du code source ouvert ou la communauté du code source ouvert n'identifient ces failles.

En d'autres termes, ces failles de sécurité sont entre les mains des pirates, mais les correctifs ne sont pas encore disponibles. Cela donne aux criminels et aux États-nations la possibilité d'exploiter les failles du code source ouvert avant la publication des correctifs nécessaires.

Il y a un "bon" examen, mais...

Ce n'est pas que la communauté open-source ignore les défauts, ou écrit négligemment du code simplement pour oublier le code et l'endroit où il est utilisé. Mais le volume même du code open source utilisé - 31 milliards de lignes de code selon certains rapports - signifie qu'il est presque impossible de vérifier minutieusement le code pour détecter les erreurs.

Dans la pratique, nous voyons souvent d'anciennes failles dans le code source ouvert émerger des décennies après que le code source ouvert ait été ajouté à une base de code.

Prenons l'exemple du bogue libcurl récemment découvert, qui a été divulgué en avril 2021. Le code sous-jacent a été ajouté à la base de code en août 2000, il a donc fallu plus de vingt ans pour que la vulnérabilité devienne publique. Il n'y a aucun moyen de savoir quels acteurs malveillants ont eu connaissance de cette vulnérabilité au cours des dernières décennies, et ce qu'ils en ont fait.

De même, le bogue à l'origine de l'exploit Heartbleed, qui a fait l'objet d'une large publicité , a été découvert 15 ans après que le code a été initialement inclus dans les bibliothèques OpenSSL. Là encore, il n'y a aucun moyen de savoir qui d'autre a pu connaître cette vulnérabilité avant qu'elle ne voie le jour.

Il s'agit simplement du fait que les bonnes personnes ne passent pas assez de temps à examiner le code source ouvert. Oui, des efforts sont déployés pour sécuriser le code source ouvert. Mais ces efforts ne sont pas comparables à ceux des acteurs malveillants qui examinent systématiquement le code pour trouver des failles exploitables.

Incitations et sensibilisation

Le problème de l'incitation à trouver les faiblesses du code open-source est connu de la communauté open-source, des experts en sécurité et des fournisseurs qui dépendent fortement du code open-source. C'est pourquoi il existe des programmes conçus pour inciter les développeurs de logiciels libres à trouver des erreurs dans le code.

Le programme de primes aux bugs de l'UE, par exemple, offre jusqu'à 25 000 euros aux développeurs qui découvrent des vulnérabilités dans des projets open-source spécifiques. La Fondation Linux a également formulé un certain nombre de recommandations dans son enquête 2020 auprès des contributeurs de logiciels libres et open-source, en partie parce que cette enquête a révélé que les développeurs de logiciels libres considèrent que la résolution des problèmes de sécurité est une tâche angoissante.

Mais les incitations ne combleront jamais le fossé de motivation entre les criminels, les acteurs de la menace et la communauté des logiciels libres. C'est pourquoi la sensibilisation est importante.

Pour les utilisateurs en entreprise, la première étape consiste à reconnaître que le code source ouvert est partout. L'achat de logiciels auprès de fournisseurs commerciaux qui utilisent du code propriétaire n'est pas une police d'assurance, car ce code repose très probablement sur du code open-source, comme des bibliothèques open-source. Certes, les fournisseurs commerciaux sont davantage incités à sécuriser le code, mais en réalité, le code propriétaire et le code à source ouverte resteront tous deux vulnérables.

Une autre étape clé consiste à rester réactif. Lorsqu'une faille est découverte dans un code source ouvert, un correctif ou une autre méthode d'atténuation suit généralement rapidement. Les entreprises doivent appliquer des correctifs rapidement et de manière exhaustive. Si cela s'avère difficile, elles doivent envisager d'utiliser des outils de correction automatisés qui font le gros du travail, sans interruption.

Enfin, la sécurité des entreprises sera toujours une question de posture de sécurité. Elle peut faire la différence entre l'atténuation rapide d'une attaque en cours et des excuses publiques six mois plus tard. Faire des hypothèses générales sur l'examen public du code source ouvert ne sera jamais bénéfique pour la sécurité des opérations.

Pour conclure, il est difficile d'affirmer de manière définitive que le code à source ouverte est plus ou moins sûr que le code propriétaire, commercial et à source fermée. L'argument est simplement plus compliqué que cela. Il existe d'innombrables défauts signalés dans le code propriétaire à source fermée également. Ne supposez pas qu'un code est plus sûr simplement parce qu'il est ouvert. En soi, cela ne garantit rien. Il faut des efforts considérables, des incitations appropriées et un savoir-faire technique pour sécuriser un code, et pas seulement un accès à la source.

Les entreprises doivent être conscientes que, oui, le code source ouvert est souvent rapidement corrigé et hautement sécurisé en raison de sa nature ouverte. Mais, à l'inverse, le code source ouvert peut aussi cacher des vulnérabilités à la vue de tous - pendant des décennies.

Continuer la lecture : OPEN SOURCE : UNE SÉCURITÉ DE NIVEAU ENTREPRISE AVEC UN CODE OUVERT ?