Logiciels open source : moyens pour les RSSI d’apaiser la peur

Pour de nombreuses parties prenantes, les logiciels open source ont de nombreux avantages. Les développeurs ont tendance à apprécier la possibilité d’accélérer le développement d’applications en empruntant du code open source. Les directeurs financiers apprécient le fait que l’open source soit souvent gratuit ou peu coûteux. Les équipes informatiques bénéficient des communautés de support dynamiques et étendues qui entourent les grands projets open source.

Pourtant, pour les RSSI, l’open source est dans de nombreux cas plus susceptible d’inspirer la peur que l’amour. Les bibliothèques et modules open source ont été au cœur de nombreuses vulnérabilités majeures en matière de sécurité de la chaîne d’approvisionnement logicielle ces dernières années – ce qui n’est pas surprenant étant donné que, dans l’ensemble, les projets open source ne bénéficient pas de la surveillance de sécurité approfondie qu’offrent les principaux éditeurs de logiciels commerciaux.

Mais il y a une bonne nouvelle : lorsque les organisations exploitent l’open source de manière délibérée et responsable, elles peuvent profiter pleinement des avantages qu’offre l’open source tout en minimisant les risques de sécurité. À cette fin, cet article propose des conseils pour parvenir à la meilleure approche possible pour intégrer l’open source dans les chaînes d’approvisionnement de logiciels d’entreprise, en se concentrant particulièrement sur les nouvelles pratiques de sécurité open source qui vont au-delà des mesures conventionnelles de validation des composants logiciels open source. .

La question séculaire : dans quelle mesure les logiciels open source sont-ils sécurisés ?

Commençons par discuter d’une question fondamentale : si les logiciels open source sont réellement moins (ou plus) sécurisés que le code source fermé.

Depuis les années 1990, lorsque les plates-formes open source telles que Linux et Apache Web Server ont fait leur apparition dans les environnements de production d’entreprise, le débat a fait rage sur la question de savoir si les logiciels open source sont aussi sécurisés que les alternatives fermées.

De manière générale, les points de vue sur ce sujet peuvent être divisés en deux perspectives principales :

• L’argument avancé par les défenseurs de l’open source, qui soutiennent que l’open source est plus sécurisé parce que n’importe qui peut l’inspecter et découvrir des failles de sécurité
• L’argument avancé par les éditeurs de logiciels fermés, qui ont tendance à faire valoir que le code source fermé est plus fiable car il est soumis à une surveillance et à des contrôles de sécurité plus minutieux que les logiciels open source, qui dans de nombreux cas sont développés par des bénévoles.

Les deux arguments ont leurs mérites – et leurs défauts. Par exemple, s’il est vrai que les logiciels open source peuvent être plus sécurisés parce que n’importe qui peut théoriquement en vérifier les failles de sécurité, cela ne signifie pas que des milliers de bénévoles examinent constamment les référentiels open source, à la recherche de risques de sécurité. Juste parce que tout le monde peut contribuer à rendre l’open source plus sécurisé ne signifie pas que tout le monde le fait réellement.

S’ils l’avaient fait, le monde aurait pu éviter des fiascos sécuritaires comme celui de Log4j et régreSSHion affaires, qui découlaient toutes deux de vulnérabilités dans le code open source largement utilisé. En outre, la sécurité pourrait être l’une des principales raisons pour lesquelles les entreprises choisissent de ne pas utiliser l’open source, selon un rapport d’IDC sur l’adoption de l’open source dans l’entreprise (Tendances des logiciels open source, septembre 2023). Et le même rapport n’aurait peut-être pas révélé que le code open source est plus susceptible que les logiciels fermés d’être lié à des incidents de sécurité. Voir la figure ci-dessous.

Dans le même temps, même si de nombreux éditeurs de logiciels fermés investissent massivement dans la sécurité, leur bilan est loin d’être parfait. En effet, certaines des violations les plus graves de ces dernières années, comme Vents solaires et La caissière Ces attaques résultent de failles de sécurité dans des bases de codes sources fermées gérées par des entreprises qui, de toute évidence, prennent la sécurité très au sérieux – mais qui ont néanmoins été violées.

En bref, il semble impossible de prouver que l’open source est plus ou moins sécurisé que le code source fermé. Ce qui est clair, c’est que les deux types de logiciels peuvent exposer, et exposent effectivement, les organisations qui en dépendent à des attaques majeures.

Nouvelles approches pour gérer les risques de sécurité open source

Pour les RSSI dont les entreprises déploient du code open source – comme le font aujourd’hui près des quatre cinquièmes des entreprises – selon le rapport IDC mentionné ci-dessus – la vraie question à laquelle il faut répondre n’est pas de savoir dans quelle mesure l’open source est sécurisé, mais de savoir ce qu’ils font pour garantir qu’ils atténuent les risques de sécurité associés au code open source.

Dans le passé, les stratégies de gestion des risques open source avaient tendance à se résumer à des pratiques relativement simplistes, comme analyser le code open source à la recherche de failles de sécurité avant de le déployer ou de l’incorporer dans une base de code d’entreprise.

Ces pratiques restent importantes aujourd’hui. Cependant, les RSSI prennent désormais des mesures supplémentaires pour utiliser la responsabilité open source. Une pratique émergente clé est l’adoption accrue d’outils de sécurité de la chaîne d’approvisionnement logicielle, qui contribuent à automatiser le processus d’identification et de validation de la source des composants tiers dans les chaînes d’approvisionnement logicielles, y compris ceux qui proviennent de produits open source.

Bien que ce type de solution ne soit actuellement utilisé que par une minorité d’entreprises, le rapport d’IDC cité ci-dessus conclut que les outils de sécurité de la chaîne d’approvisionnement logicielle sont susceptibles de jouer un rôle de plus en plus important dans la capacité des entreprises à exploiter l’open source de manière sécurisée : surtout si les fournisseurs d’outils peuvent améliorer leurs solutions afin qu’elles répondent mieux aux besoins des entreprises qui s’appuient fortement sur l’open source. Voir la figure ci-dessous.

D’autres pratiques permettant d’atténuer les risques de sécurité de l’open source incluent la définition de critères indiquant quand et où les développeurs d’entreprise peuvent emprunter du code open source. Du point de vue de la sécurité, il existe une énorme différence entre les grands projets open source très actifs, comme Linux ou Kubernetes, et les référentiels open source obscurs sur des sites comme GitHub. Ces derniers sont moins susceptibles d’offrir de solides protections de sécurité ou de réagir rapidement si quelqu’un découvre des vulnérabilités dans leur base de code.

Pour être aussi efficaces que possible, les critères concernant les types de projets open source que les développeurs peuvent utiliser doivent être clairs et cohérents. Par exemple, plutôt que de simplement établir une politique de gouvernance exigeant que les codeurs fassent preuve de bon jugement lorsqu’ils décident d’emprunter ou non le code d’un référentiel, une entreprise pourrait envisager de générer une liste approuvée de projets open source ou de composants logiciels sur lesquels les développeurs peuvent s’appuyer, ainsi que de mettre en œuvre un processus d’approbation pour l’ajout de nouvelles sources de logiciels à la liste.

Conclusion : l’avenir brillant – mais complexe – de la sécurité des logiciels open source

Compte tenu de l’ampleur et de l’ampleur de l’adoption des logiciels open source dans les entreprises modernes, il semble peu probable que les problèmes de sécurité empêchent les entreprises de dépendre du code open source dans un avenir proche. Cela dit, les données montrent que l’open source est un peu plus susceptible d’être lié à des attaques que les logiciels fermés, ce qui suggère que les RSSI devraient faire davantage pour anticiper les défis de sécurité de l’open source. À elles seules, les pratiques de base, comme l’analyse du code open source, ne suffisent pas. Les entreprises doivent adopter des mesures supplémentaires, comme celles décrites ci-dessus, si elles souhaitent réellement maximiser les avantages qu’elles tirent de l’open source tout en minimisant les défis de sécurité auxquels elles sont confrontées.

En savoir plus sur Recherche d’IDC pour les leaders technologiques.

International Data Corporation (IDC) est le premier fournisseur mondial d’informations commerciales, de services de conseil et d’événements pour les marchés technologiques. IDC est une filiale en propriété exclusive d’International Data Group (IDG Inc.), le leader mondial des services de médias technologiques, de données et de marketing. Récemment élu cabinet d’analystes de l’année pour la troisième fois consécutive, les solutions technologiques leaders d’IDC vous fournissent des conseils d’experts soutenus par nos services de recherche et de conseil de pointe, de solides programmes de leadership et de développement et les meilleures données d’analyse comparative et d’approvisionnement. auprès des conseillers les plus expérimentés de l’industrie. Contactez-nous dès aujourd’hui pour en savoir plus.

Christophe Tozzi, conseiller de recherche adjoint pour IDC, est maître de conférences en informatique et société au Rensselaer Polytechnic Institute. Il est également l’auteur de milliers de billets de blog et d’articles pour divers sites de médias technologiques, ainsi que de nombreuses publications scientifiques.

Avant de se consacrer actuellement à la recherche et à l’écriture sur la technologie, Christopher a travaillé à temps plein en tant que professeur d’histoire titulaire et analyste pour une startup technologique de la région de la baie de San Francisco. Il est également un connaisseur de longue date de Linux et a occupé des postes dans l’administration système Linux. Cette combinaison inhabituelle de compétences techniques « concrètes » et d’un accent sur les questions sociales et politiques aide Christopher à réfléchir de manière unique à l’impact de la technologie sur les entreprises et la société.