Open source : quelle place pour la sécurité ?

Comment appréhender la sécurité de l’open source ? Sonatype donne des éclairages à la fois quant au développement de projets et à leur réutilisation.

Tout comme un fabricant formalise des pratiques d’approvisionnement, l’usage de l’open source suppose un « réflexe supply chain ».

Sonatype – éditeur d’une plate-forme de gouvernance – fait traditionnellement passer le message à travers une étude annuelle. L’édition 2020 n’y déroge pas. Elle se fonde sur un large éventail de données publiques, additionnées de divers sondages auprès de développeurs.

Il en ressort, en particulier, une évolution : la nette augmentation (+430 %) des attaques dites « de nouvelle génération »*. Sonatype y range notamment les injections de code malveillant. Et plus globalement, toutes les attaques « par anticipation », qu’il oppose à celles basées sur des vulnérabilités connues et non corrigées.

attaques next-gen

On trouve, en page 8 du rapport, une liste non exhaustive de ces attaques « next-gen ». Parmi elles, la récente offensive contre l’IDE NetBeans, avec le malware Octopus Scanner. Les dépôts le plus souvent ciblés sont npm (Node.js) et PyPi (Python).

Qu’en est-il en matière de réponse à ces attaques ? Dans plus de la moitié des cas (51 %), la remédiation n’intervient pas avant au moins une semaine. La détection elle-même nécessite une certain temps : d’après les témoignages de 679 professionnels du développement, 48 % des organisations mettent plus d’une semaine à apprendre l’existence d’une faille.

TTR

En analysant les dépôts Maven, Sonatype a dégagé trois grandes typologies de projets open source, en fonction de la manière dont les dépendances y sont gérées.

Sur les quelque 8 000 projets qu’a englobés l’analyse, environ 10 % se positionnent comme « exemplaires ». Leurs caractéristiques : un court délai médian de mise à jour et un faible nombre de dépendances obsolètes (premier quintile dans les deux cas).
À l’autre extrémité (dernier quintile) se trouvent les « traînards ». Ils mettent en moyenne deux ans pour mettre à jour des dépendances.
Le troisième profil qui se détache est celui des « prudents ». Ces derniers affichent un délai de remédiation acceptable (première moitié de l’échantillon), mais un grand nombre de dépendances obsolètes. Leurs releases sont espacées de deux mois en moyenne.

typologies projets

Open source : une question d’implication ?

Du côté des entreprises utilisatrices de l’open source, Sonatype dégage quatre groupes, fonction de deux paramètres : la productivité des équipes de développement et la sécurité des projets.

Le groupe le plus nombreux (167 éléments) est plus avancé sur la sécurité que sur la productivité. Ses membres présentent un taux important d’automatisation des processus d’approbation, de gestion et d’analyse des dépendances.

Ceux qui parviennent à associer productivité et gestion du risque (« High Performers » ; 151 éléments) ont tendance à déployer plus fréquemment. Mais aussi à rendre leurs développeurs plus rapidement opérationnels.

profils entreprises

Le rapport liste quatre facteurs principaux favorisant la gestion du risque :

  • Disposer d’un processus clair pour l’ajout et la suppression de dépendances
  • Corriger les failles dans le cadre du processus de développement
  • Mettre régulièrement à jour les dépendances
  • Employer des outils SCA (analyse de composition logicielle) et les coupler aux démarches d’intégration continue

Pour ce qui est des facteurs qui influencent plus particulièrement le délai de détection des failles, on retrouve en premier lieu la planification de la mise à jour des dépendances dans le cadre du travail quotidien.
Côté remédiation, c’est le degré d’implication des développeurs dans l’open source qui s’impose comme le premier facteur.

visiblité développement open source

* Ce taux résulte de la comparaison du nombre de ces attaques recensées entre juillet 2019 et mai 2020 (929), par rapport à la période février 2015 – juin 2019 (216).

Illustration principale © opensourceway via VisualHunt / CC BY-SA