Yann Albou, Sokube : «Il importe d’intégrer les besoins sécuritaires le plus en amont possible»

Qu’est-ce qui explique l’attention croissante prêtée à la sécurité de la supply chain logicielle?

Avec la multiplication des vecteurs d’attaque, le paradigme du château fort et de la sécurité périmétrique appartiennent au passé. De plus en plus d’entreprises s’intéressent et cherchent à adopter une approche transversale de type zero trust. Dans cette conception, ce n’est plus le seul réseau mais l’ensemble des composants de l’IT qu’il faut protéger : rien n’est a priori infaillible, y compris ce qui est interne à l’entreprise. C’est un changement profond au niveau humain et au niveau organisationnel. La sécurité devient l’affaire de chacun et de chaque élément de la chaîne applicative, de la conception à la mise en production, et cela passe par les identités, par la data, par l’infrastructure, par les applications et désormais par la supply chain logicielle. Il y a en effet une volonté d’intégrer les besoins sécuritaires le plus en amont possible – shift left – pour que la sécurité se propage ensuite jusqu’aux environnements de production.

La question de la supply chain n’est-elle pas aussi liée au fait que les applications et architectures reposent de plus en plus sur des composants tiers?

Effectivement. Les entreprises évoluent dans des environnements changeant rapidement, au niveau économique, sanitaire ou même écologique. Elles doivent être extrêmement réactives et se focaliser sur leur business. Au niveau IT, il faut donc délivrer bien et vite et s’appuyer sur ce qui est disponible sur le marché, à commencer par l’open source. Aujourd’hui, les applications sont en large partie formées de tels composants. La question de la manière de gérer la sécurité de ces éléments se pose donc pour les organisations.

A quels risques s’exposent les organisations face aux vulnérabilités de ces composants?

Les impacts causés par des composants vulnérables sont variés : divulgation de données, logiciels malveillants, mais aussi dysfonctionnements ou encore surconsommation de ressources. Premier exemple, Log4shell, un composant Java très populaire dont la vulnérabilité a été soudainement révélée, et dont j’ai pu constater l’impact chez nos clients. Les entreprises ont tout à coup dû répondre à deux problèmes : comment est-ce que j’identifie les applications concernées et comment est-ce que je patche rapidement ? Et elles n’étaient pas prêtes. Un an après que la vulnérabilité a été dévoilée, 30% des downloads se faisaient encore sur des versions boguées. Second exemple, les librairies npm Colors et Faker, elles aussi très populaires. Ici ce n’est pas une vulnérabilité qui a été dévoilée, mais bien le développeur qui s’occupait de ces composants qui a décidé de les saboter délibérément pour réveiller la communauté. Tout le monde profite en effet de ces composants, mais personne ne paie ceux qui passent du temps à les développer. Pour la petite histoire, le développeur a cassé uniquement les versions « en cours de développement » et pas les versions validées. Ce qui n’a pas empêché des milliers d’applications en production d’être pénalisées…

Les organisations sont-elles attentives à ces dangers?

Cela dépend. Une première catégorie d’entreprises a vraiment pris conscience de ce risque : elles sensibilisent leurs collaborateurs, revoient leurs processus et mettent en place des solutions et une gouvernance de la sécurité adaptée. Une deuxième catégorie d’entreprises, bien qu’attentives à la question, traitent les problèmes de manière ciblée et ponctuelle sans remettre en cause la manière dont elles se protègent. Et bien sûr, il y a une troisième catégorie d’entreprises qui n’ont aucune conscience de cette problématique. Au final, je dirai que rares sont les entreprises qui traitent ce risque dans son intégralité, et cela ne dépend pas des secteurs ou de la taille des organisations. Il faut dire que ce n’est pas évident: ce n’est pas une démarche naturelle que de considérer la supply chain comme un vecteur d’attaque.

Quelles sont vos recommandations pour sécuriser la supply chain logicielle?

Comme je le disais au début, il faut que l’entreprise et les équipes prennent conscience du problème et du nouveau paradigme de sécurité avec une approche en amont et un principe de moindre privilège. Ensuite il y a un certain nombre de mesures techniques à mettre en œuvre au niveau de la supply chain. D’abord publier sa SBOM pour lister les packages tant applicatifs que systèmes, mettre à jour régulièrement ses dépendances, assurer l’immuabilité du système et des containers, avoir une approche minimaliste pour réduire la surface d’attaque et s'assurer de l'intégrité des composants. Il faut aussi éliminer tous les secrets des containers, repositories et autres VM. Il importe également de disposer d’un système effectuant un scanning régulier aussi bien dans la CI qu’en production, d’un système d’isolation des registres dans lesquels on stocke nos packages, avec un mécanisme de promotion et des permissions et pratiques différentes selon que l’on soit en dev, en test ou en prod. Je recommanderais aussi de mettre en place un système GitOps, une RBAC forte et des outils d’observabilité incluant la supply chain logicielle. Il faut enfin fortifier les solutions de la software factory, souvent mal configurées. En conclusion, il est important de considérer la sécurité de manière globale et de responsabiliser au plus tôt dans la chaîne de développement. Ce sujet devient de plus en plus critique et des standards et frameworks émergent tels que SLSA permettant d’identifier son niveau de maturité dans ce domaine.