Avec 600% d’attaques en plus sur la chaîne d’approvisionnement logicielle en trois ans, les équipes DevOps doivent repenser leur approche : intégrer la sécurité dès la conception sans sacrifier la vélocité de développement.
L’open source est un élément indispensable à la conception et à la distribution des logiciels actuels. En effet, l’open source est présent dans 96 % des programmes commerciaux et, en 2024, des millions de nouveaux paquets ont été ajoutés aux registres publics de codes. L’open source accélère le développement, favorise l’innovation communautaire et constitue l’épine dorsale d’innombrables applications grand public et professionnelles. Selon une étude de la Harvard Business School, sans les logiciels open source, les entreprises devraient débourser environ 8 800 milliards de dollars pour développer les logiciels et les plateformes qui leur permettent de fonctionner.
S’il ne fait aucun doute que l’open source est essentiel à la poursuite de l’innovation dans le secteur, cet ingrédient clé s’accompagne également d’un nombre croissant de défis en matière de sécurité, les pirates apprenant à exploiter cette ouverture même qui fait la richesse de cet écosystème. Au cours des trois dernières années, les attaques visant la chaîne d’approvisionnement des logiciels ont augmenté de 600 %, les pirates ciblant de plus en plus les pipelines CI/CD, les gestionnaires de paquets et les registres publics. Plus de 10 millions de personnes et 1 700 organisations ont été touchées par des attaques visant la chaîne d’approvisionnement open source rien qu’en 2022. La réalité est claire : l’open source est indispensable, mais il nécessite un nouveau niveau de vigilance en matière de sécurité.
L’open source : un outil puissant qui nécessite des garde-fous
82 % des composants logiciels open source présentent un niveau de risque inhérent, tel que des vulnérabilités non corrigées, des difficultés de maintenance ou des problèmes de qualité. Les organisations tentent souvent de limiter l’utilisation des dépendances aux seuls paquets approuvés et vérifiés, mais ce faisant, elles freinent l’innovation et la vélocité. Pour respecter les délais, les développeurs avisés trouvent des solutions de contournement et ces composants sont souvent ajoutés aux projets sans suivi cohérent ni contrôle de sécurité continu, créant une opportunité pour les attaquants de passer à l’action.
De nombreux professionnels du DevOps connaissent bien le mantra « release fast or die » (livrer rapidement ou mourir). Mais lorsque ce mantra dicte vos délais, la sécurité passe parfois au second plan. Il peut être tentant de lancer une version pour atteindre les objectifs commerciaux et de promettre de corriger les vulnérabilités plus tard. Mais le coût d’un retard en matière de sécurité est élevé : la correction des vulnérabilités binaires après le déploiement peut coûter des millions, et la réputation d’une entreprise peut être gravement compromise à la suite d’une violation. La leçon à retenir est simple mais essentielle : traiter la sécurité dès le début, d’une manière conviviale pour les développeurs, est beaucoup moins coûteux que de devoir nettoyer en production.
Ce que les développeurs et les équipes DevSecOps doivent prioriser
Concevoir des logiciels sécurisés signifie intégrer la sécurité dans les workflows sans ralentir la livraison. Voici quatre mesures pratiques que les développeurs et les équipes DevSecOps peuvent adopter :
* Restez proactif en matière de gestion des dépendances. Ne laissez pas des bibliothèques obsolètes devenir un maillon faible. Prenez l’habitude de revoir, mettre à jour et, si nécessaire, remplacer régulièrement les dépendances afin de traiter les vulnérabilités avant qu’elles ne puissent être exploitées.
* Automatisez la révision des dépendances. L’utilisation de politiques automatisées associées à des bases de données de sécurité riches peut accélérer la vélocité des logiciels et améliorer simultanément la sécurité en transférant la charge des ressources manuelles vers des outils intelligents.
* Vérifiez l’intégrité des fichiers binaires. La confiance est essentielle, mais elle ne doit pas être aveugle. Veillez toujours à vérifier l’authenticité des fichiers binaires et des artefacts tiers que vous utilisez dans votre environnement. Cela réduit le risque d’inclure des paquets malveillants ou compromis dans votre pipeline.
* Adoptez une surveillance continue. L’analyse automatisée des vulnérabilités intégrée à vos pipelines CI/CD vous permet de détecter rapidement les problèmes de sécurité. Une approche continue fait de la sécurité une partie intégrante du rythme de développement, et non une réflexion après coup.
De nombreuses organisations repensent également leur infrastructure système afin de créer une zone tampon plus sécurisée entre les développeurs et les registres sur l’Internet public. En utilisant un référentiel centralisé et organisé qui sert de proxy aux registres publics pour tous les artefacts logiciels, conteneurs et même modèles ML, les équipes disposent d’un point de contrôle unique où elles peuvent appliquer des contrôles de sécurité, une organisation et une analyse cohérents avant que les composants n’entrent dans les pipelines. Cela simplifie en fin de compte l’expérience des développeurs et renforce la sécurité tout au long de la chaîne d’approvisionnement logicielle.
Le prochain défi : les modèles ML open source
Les développeurs sont peut-être plus familiarisés qu’auparavant avec la sécurisation des bibliothèques de code et des binaires, mais un nouveau défi est apparu : les modèles d’apprentissage automatique open source. Les modèles ML sont souvent volumineux et opaques, posent des problèmes de licence et peuvent contenir des vulnérabilités cachées implantées par des acteurs malveillants.
Contrairement au code traditionnel, les modèles ML peuvent être plus difficiles à inspecter, ce qui en fait une cible attrayante pour les attaquants qui cherchent à s’introduire dans les environnements d’entreprise avec du code malveillant. Il est essentiel de traiter les modèles ML de la même manière que les autres artefacts logiciels, notamment en les analysant à la recherche de vulnérabilités, en vérifiant leur provenance et en les stockant de manière sécurisée avant leur déploiement.
Construire un avenir sécurisé pour l’open source
La sécurisation de la chaîne d’approvisionnement des logiciels est plus qu’un défi technique. Il s’agit d’un changement de mentalité dans la façon dont les équipes abordent le développement. En termes simples, la sécurité ne peut pas être un simple contrôle final avant la mise en production : elle doit être présente à chaque étape, depuis le moment où une dépendance est prise en compte jusqu’au déploiement final en production. En gérant de manière proactive les dépendances, en vérifiant les binaires, en effectuant des analyses continues et en gérant les modèles ML de manière responsable, les équipes de développement peuvent contribuer à combler les failles que les pirates attendent de mettre à profit. La centralisation des contrôles de sécurité peut simplifier ce processus, réduisant ainsi les risques tout en maintenant la vitesse requise par le développement moderne.
En intégrant la sécurité au cœur de leur ADN de développement, les équipes peuvent continuer à innover rapidement tout en protégeant leur organisation, leurs utilisateurs et l’écosystème numérique au sens large.
____________________________
Par Fred Simon, Cofondateur et Chief Architecte chez JFrog
puis