Bienvenue à Fugue : construisons ensemble l’avenir de la sécurité cloud axée sur les développeurs

Aujourd’hui, j’ai le plaisir d’annoncer l’acquisition de Fugue par Snyk et de souhaiter la bienvenue à son équipe au sein de la famille Snyk. L’intégration de Fugue à la plateforme Snyk nous permettra de poursuivre notre mission : aider les développeurs à détecter et corriger les problèmes de sécurité dans les applications qu’ils créent, en leur donnant une visibilité sur la sécurité des applications et des services cloud qu’ils utilisent. Mais il ne s’agit pas seulement d’avoir une meilleure visibilité sur la posture de sécurité du cloud. Cette nouvelle connaissance de l’état des applications déployées dans le cloud nous permettra de mieux contextualiser les vulnérabilités et les problèmes de configuration. Nous pourrons hiérarchiser les vulnérabilités en nous appuyant sur la visibilité et le contexte de l’environnement de production, et veiller à ce que les applications et leur configuration restent conformes à l’état prévu.

Du code au cloud, et du cloud au code

Snyk a aidé des millions de développeurs à sécuriser leur code, leurs conteneurs et leurs configurations dès le début du cycle de vie, avant le déploiement. Dans les équipes DevOps modernes, le rôle des développeurs en matière de sécurité des applications ne s’arrête pas une fois l’application déployée. Ils sont également responsables de la sécurité et des performances continues de leur code en cours d’exécution. Cela inclut la gestion de l’infrastructure cloud utilisée par leurs applications, idéalement sous forme d’infrastructure as code (IaC). Une solution de sécurité cloud qui commence par le code, offre une visibilité sur le cloud, puis réinjecte les informations obtenues dans le code permet aux développeurs d’assumer pleinement la responsabilité de la sécurité.

De nombreux outils de gestion de la posture de sécurité du cloud (CSPM) fournissent des informations sur l’état de l’infrastructure, mais ils ont été conçus pour les équipes de sécurité et d’exploitation. La plupart ne sont pas reliés à l’IaC et ne donnent pas non plus de détails sur les applications exécutées sur l’infrastructure. Pourtant, l’infrastructure est conçue pour faire fonctionner les applications : les problèmes qui la touchent doivent donc être corrigés sans interrompre ces applications — ni provoquer une dérive par rapport aux définitions de l’infrastructure dans l’IaC, qui constituent la « source de vérité ». Snyk et Fugue vont résoudre ces problèmes ensemble.

Beaucoup considèrent le cloud comme un centre de données. En pratique, le cloud est un logiciel, de plus en plus piloté par du code. Fugue a conçu sa plateforme autour de cette idée : considérer le déploiement cloud comme du code et optimiser la sécurisation de l’infrastructure automatisée. Fugue relie la posture de sécurité du cloud au code de configuration et s’appuie sur un ensemble unique de règles pour gérer la sécurité et la conformité tout au long du cycle de vie. Snyk et Fugue partagent la même vision de cette boucle de rétroaction : sécuriser le code avant son déploiement, maintenir la sécurité en production et proposer des correctifs dans le code que les développeurs doivent gérer. En unissant nos forces, nous pouvons concrétiser ces projets bien plus rapidement.

Pourquoi Fugue ?

Dès le début de nos échanges avec l’équipe de Fugue, nous avons constaté que nous partagions les mêmes principes fondamentaux : l’infrastructure doit être définie sous forme de code, puis gérée et sécurisée par les développeurs. Nous avons également convenu que les outils CSPM actuels manquent d’un élément essentiel : la visibilité et les retours d’information. Dès 2018, l’équipe de Fugue écrivait :

Alors que la plupart des [entreprises] utilisent une forme ou une autre d’outil de surveillance du cloud, elles s’appuient trop sur des processus manuels pour détecter et corriger les événements critiques liés à des erreurs de configuration… Les équipes d’infrastructure et de développement doivent avancer vite, et les équipes de sécurité et de conformité doivent les aider à le faire.

Snyk et Fugue partagent la conviction et la vision selon lesquelles nous pouvons donner aux développeurs les moyens de détecter, hiérarchiser et corriger les problèmes dans leurs applications, y compris ceux liés à la configuration et à l’infrastructure dont elles dépendent.

Nous partageons également la conviction qu’il faut utiliser des technologies ouvertes et natives du cloud comme OPA et son langage de politiques, Rego. En fait, les politiques utilisées aujourd’hui avec Fugue peuvent facilement être adaptées pour fonctionner avec Snyk. Mais, plus largement, cela signifie que les utilisateurs de Snyk et de Fugue n’ont pas besoin d’apprendre un moteur de politiques ou un langage spécifique, compatible uniquement avec nos produits. OPA est largement utilisé avec Kubernetes et un nombre croissant de technologies natives du cloud. Les développeurs et les équipes de sécurité gagnent ainsi en productivité, ce qui profite à tous.

Notre vision d’une sécurité cloud axée sur les développeurs

Notre première étape pour aider les développeurs à sécuriser leurs applications dans le cloud consistera à créer un moteur de politiques unifié, qui alimentera à la fois nos solutions IaC et de sécurité cloud. Nous proposerons le meilleur moteur de politiques sous forme de code, afin que les développeurs et les équipes de sécurité cloud puissent collaborer, corriger les erreurs de configuration dans le code et dans le cloud, et gérer les écarts entre les deux.

En plus d’éviter les erreurs de configuration, cette solution donnera aux développeurs une visibilité sur l’exécution de leurs applications et nous permettra de proposer une analyse avancée de leur exploitabilité. C’est essentiel : l’analyse des seules définitions cloud dans le code ne révèle pas des détails contextuels importants, qui apparaissent lorsqu’on dispose d’une vue complète de l’environnement en production. À l’inverse, se limiter à l’environnement cloud en production, comme le font les outils CSPM traditionnels, ne permet pas de voir les détails au niveau du code : les vulnérabilités présentes dans l’application et ses dépendances, dont l’exposition au monde extérieur aggrave le risque. Pour résoudre ces deux problèmes, il faut une boucle de rétroaction couvrant le code de l’application, les conteneurs et la configuration, qui ajoute la visibilité sur l’état actuel de l’application en cours d’exécution et réinjecte ces informations dans le code et les outils que les développeurs utilisent pour corriger les problèmes.

Qu’est-ce que cela signifie pour les utilisateurs et clients actuels de Fugue ?

Si vous êtes actuellement client de Fugue, nous continuerons à vous accompagner avec Fugue dans un premier temps. Nous allons travailler à intégrer les fonctionnalités de Fugue à la plateforme Snyk, et nous avons hâte de vous faire part de notre feuille de route et de nos projets au fil de leur avancement.

Qu’est-ce que cela signifie pour les utilisateurs et clients actuels de Snyk IaC ?

Pour les clients de Snyk IaC, le produit Snyk IaC continuera d’évoluer et d’enrichir ses fonctionnalités, grâce à la fois à l’intégration du produit IaC de Fugue et à l’accélération de notre feuille de route déjà prévue. Les règles de configuration et de sécurité cloud de Fugue et de Snyk IaC seront fusionnées : de nouvelles règles seront donc bientôt disponibles, et nous continuerons à faire évoluer Snyk IaC. Nous travaillons sur les fonctionnalités de détection de dérive issues de l’acquisition de CloudSkiff et, comme nous l’avions annoncé à l’époque, elles feront partie de Snyk IaC. D’autres fonctionnalités passionnantes sont également prévues pour IaC cette année. Le contexte cloud fourni par Fugue nous permettra d’améliorer considérablement l’expérience des développeurs en tirant parti des informations cloud pendant le développement local et en hiérarchisant les problèmes de sécurité.