L'avenir de l'open source est-il menacé ?

Le logiciel Open Source (OSS) est l'épine dorsale de l'architecture d'application d'aujourd'hui. En accélérant la mise sur le marché et en réduisant la charge des développeurs souvent surchargés de travail, l'open source a consolidé sa position révolutionnaire dans le paysage DevOps. Bien que profondément transformateur pour le développement d'applications modernes, le copier-coller open source continue de représenter un risque de sécurité majeur pour les organisations et les individus. Pour lutter contre cela, il faut soit une liste noire totale de code open source, soit la mise en œuvre proactive de contre-mesures telles qu'une solution WAF de nouvelle génération .

Le code tiers est vital pour le développement d'applications

Les bibliothèques sont des réserves incroyablement pratiques de code source pour les composants d'applications Web ou mobiles. Ces bibliothèques peuvent être open-source – accessibles à tous gratuitement – ​​ou propriétaires, ce qui verrouille le code derrière le paiement. Bien que l'open source revendique une grande partie de la gloire, le code propriétaire joue également un rôle dans le fonctionnement continu des applications d'entreprise.

Ce logiciel tiers, lorsqu'il est utilisé de manière responsable, évite aux développeurs d'avoir à réinventer constamment la roue. Cela améliore considérablement l'efficacité du processus de développement, tout en aidant à la production d'un produit final de haute qualité. En fin de compte, l'utilisation gratuite et libérale du code open source crée une boucle de rétroaction positive, permettant aux développeurs de publier plus rapidement leur produit minimum viable, ce qui ouvre la voie à une collecte et une mise en œuvre rapides des commentaires et de l'évaluation des utilisateurs. Bien que les développeurs soient profondément conscients de la position critique de l'open source dans le processus DevOps, les dirigeants sont souvent surpris d'apprendre que 80 % du code prenant en charge les applications modernes provient d'un code préexistant.

Le sombre danger des dépendances transitives

Ce n'est pas une nouvelle que le code open source comporte des risques. Les récentes faiblesses généralisées telles que Log4j et HeartBleed ont irrévocablement placé le risque open source sur la carte. Ce qui reste un domaine de compréhension croissant est la fréquence à laquelle l'open source est utilisé et la furtivité avec laquelle les vulnérabilités peuvent se faufiler dans un projet actif. Malgré le risque continu présenté par les projets open source, très peu de recherches ont été menées sur le type spécifique de risque que présente l'open source. Les chercheurs d'Endor Labs ont entrepris de changer cela en clarifiant l'origine des principales menaces OSS.

Dans le logiciel, les dépendances transitives décrivent une relation indirecte unique entre deux composants. Par exemple, supposons que votre équipe de développement ajoute le package B à un projet en cours. Le package B, à son tour, télécharge automatiquement le package C. Dans ce scénario, alors que le logiciel en développement bénéficie d'une relation directe avec le package B, le package C reste caché en arrière-plan - intégral mais largement invisible. Le fait que seulement 5 % des dépendances logicielles open source sont sélectionnées manuellement pour être mises en œuvre dans le cadre du processus DevOps est frustrant pour toute tentative de pratiques de développement plus sûres. De cette manière, la plupart des dépendances sont simplement automatiquement insérées dans la base de code. Ceci décrit la source d'une vulnérabilité transitive. Un rapport récent d'Endor Labs a révélé que 95 % des vulnérabilités open source proviennent de dépendances transitives .

Les données ont été compilées à partir du rapport Census II de Core Infrastructure, qui répertorie les logiciels open source gratuits les plus populaires. Ces données ont ensuite été enrichies avec d'autres sources qui ont permis aux chercheurs d'Endor d'analyser les gestionnaires de packages et les bibliothèques OSS populaires. Les chercheurs ont découvert que - sur 254 packages mentionnés dans les données du recensement II - la plupart souffrent en moyenne de 14 dépendances transitives. Dans le vide, 14 peuvent ne pas sembler étonnamment élevés, mais la plupart des applications reposent sur des dizaines, voire des centaines, de dépendances directes ; leurs homologues transitifs évoluent de façon exponentielle.

La principale préoccupation exprimée par les chercheurs est basée sur la sous-estimation généralisée du problème par l'industrie. Les dirigeants continuent de saper la quantité de code source utilisée dans le processus de développement - les dépendances transitives ne sont même pas encore sur le radar. La profondeur même des problèmes de sécurité continue de se cacher sous la surface, augmentant le rayon d'explosion des attaques de typosquattage et d'exécution de code à distance. Pour que la réutilisation constante du code open source soit pleinement à la hauteur de son potentiel, la sécurité doit devenir une priorité plus élevée dans le processus DevOps.

Comment se protéger contre les vulnérabilités cachées

Le processus de maintien d'une pile technologique sécurisée n'a jamais été aussi complexe. Les alertes de correctifs devenant rapidement accablantes, il est temps pour la sécurité de l'entreprise de donner la priorité à une protection automatisée et sans correctif. Les mesures traditionnelles qui accordent la priorité à la sécurité du périmètre parallèlement à l'analyse statique et dynamique reposent sur des mises à jour manuelles, ce qui signifie qu'il n'y a aucune protection contre les jours zéro. Le code de porte dérobée que les attaquants ont utilisé dans le cadre de la tristement célèbre attaque SolarWinds n'a été détecté par aucune analyse statique, car il n'y avait techniquement aucune erreur.

L'identification et le blocage des tentatives d'exploitation nécessitent une petite suite de logiciels de verrouillage. Pour d'abord aider à définir et à protéger le périmètre d'une application, un pare-feu d'application Web (WAF) de nouvelle génération peut être déployé. Situé à la frontière entre l'externe et l'interne, le WAF surveille tout le trafic entrant et sortant d'une application. L'aspect nouvelle génération permet à ce WAF d'adapter et de mettre en œuvre automatiquement de nouvelles politiques. Le déploiement automatisé de cette évolution constante libère beaucoup de temps et d'énergie pour l'équipe de sécurité qu'un WAF à l'ancienne épuiserait autrement.

Alors que WAF contrôle toutes les tentatives externes d'exécution de code, Runtime Application Self Protection (RASP) protège contre les faiblesses internes et les injections de code. Ce niveau de protection évalue toutes les charges utiles (telles que les requêtes SQL et les commandes du système d'exploitation) en temps réel. Ce processus ne nécessite pas de signatures ni de phase d'apprentissage et se déroule entièrement dans le contexte de l'application. Comme cela fonctionne au sein de l'application, il couvre presque tous les contextes. Cela signifie que, même si un exploit permet de franchir le périmètre, un attaquant est empêché de se déplacer latéralement, car tout comportement suspect de l'application déclenche un arrêt du RASP. Cela met fin à l'activité suspecte et alerte les équipes de sécurité. De cette manière, RASP est complémentaire d'un WAF de nouvelle génération ; alors que le WAF aide à empêcher le mauvais trafic d'entrer, le risque posé par les exploits transitifs cachés est atténué par RASP. Avec ces composants protégeant une pile technologique, le fardeau que l'OSS place actuellement sur la sécurité est considérablement allégé.