Le Monde Informatique : pour commencer, pouvez-vous nous présenter Checkmarx et nous raconter ce qui vous a conduit à fonder la société ?

 Maty Siman : J’ai créé Checkmarx en février 2006, la société va bientôt fêter son seizième anniversaire. Pour expliquer ses origines, je vais revenir un peu sur mon parcours personnel : j’ai eu mon premier ordinateur à l’âge de sept ans et j’ai commencé à développer en Basic. Depuis, j’écris du code tous les jours. À 18 ans, j’ai rejoint les forces de défense israéliennes et l’une de mes responsabilités était de trouver une solution pour aider les développeurs à écrire du code sécurisé. À l’époque, très peu d’outils existaient et le marché était embryonnaire. Les solutions ciblaient les RSSI et ne considéraient pas les développeurs comme des utilisateurs finaux, or je cherchais un produit qui s’adresse à moi en tant que développeur. En créant Checkmarx, j’ai voulu essayer de trouver une solution de sécurité applicative qui réponde à cet enjeu, et qui aide les développeurs à sécuriser le code. C’est cette vision qui rend notre approche unique : nos utilisateurs finaux sont les développeurs, mais les RSSI sont également partie prenante. Nous regardons des deux côtés du spectre.

Vous venez de lancer une plateforme cloud intégrée de sécurité applicative, Checkmarx Application Security Platform. À quels enjeux répond-elle, et quel est son positionnement sur le marché ?

Le secteur IT a fortement changé. Pour moi, le changement le plus drastique est intervenu il y a sept ou huit ans, avec l’émergence du développement cloud. Auparavant, les développeurs écrivaient des millions de lignes de code. Avec les services cloud, il y a moins besoin d’écrire du code. Il n’est pas nécessaire de réinventer la roue, il suffit de piocher dans les multiples services existants, de choisir les bons composants et de les combiner. C’est ce que j’appelle le « Legolizing » : on assemble des briques de code, auxquelles on ajoute quelques lignes de logique métier. Cette génération de développeurs cloud est très différente des précédentes, il ne s’agit plus seulement d’écrire du code, mais d’utiliser de multiples langages et services différents de façon simultanée.

 Ces développeurs cloud ont besoin d’une approche holistique pour la sécurité applicative, permettant à la fois de scanner chaque brique individuellement et d’analyser l’ensemble de l’architecture. Pour nous, répondre aux besoins de cette génération est à la fois un défi, car il faut prendre en charge de multiples produits, mais c’est aussi une opportunité, en étant le premier acteur à leur fournir une telle solution. Avant de bâtir notre plateforme, nous avions plusieurs moteurs d’analyse distincts. Aujourd’hui ils sont intégrés dans la plateforme, qui fournit également une couche de corrélation. Cette dernière corrèle les données de chaque moteur afin d’évaluer la sévérité des différentes alertes remontées et de les hiérarchiser. C’est une approche unique, qui allie la capacité à zoomer en profondeur sur chaque composant et la vision macro. Pour moi il n’existe pas de concurrent qui associe ces deux approches.

Justement, pouvez-vous nous présenter les différents moteurs qui sont aujourd’hui intégrés dans la plateforme ?

Au total nous avons sept moteurs et outils différents. Nous avons commencé par l’analyse de code statique et nous avons ajouté des produits additionnels au fil du temps. La solution la plus ancienne est notre outil SAST (Static Application Security Testing), qui couvre aujourd’hui 25 langages de programmation. Ensuite est venu l’outil SCA, pour analyser les composants venant de tierces parties. Nous avons aussi un outil IAST (Interactive Application Security Testing) pour détecter des vulnérabilités lors de l’exécution, de façon automatisée lors des tests. Il y a quatre mois, nous avons acquis Dustico, une solution d’analyse de code dynamique pour prévenir les attaques par supply chain, complémentaire de notre outil SCA. Cette solution ne regarde pas si les composants sont vulnérables, mais s’il y a du code malveillant ou des backdoors dans du code open source utilisé par les fournisseurs, mais que ceux-ci n’ont pas développé. Le but n’est pas de détecter les failles introduites par erreur dans le code, comme avec les outils précédents, mais la présence intentionnelle de composants malveillants.

 Nous avons également lancé il y a un an notre produit KICS (Keeping Infrastructure as Code Secure) en open source. L’un des changements avec la génération des développeurs cloud, c’est qu’ils sont aussi responsables de l’infrastructure. Avant, une équipe d’infrastructure se chargeait de réceptionner, brancher et préparer les machines, maintenant une ligne de code suffit pour instancier un nouveau serveur. C’est ce qu’on appelle l’infrastructure-as-code. Il faut pouvoir scanner ce code, dans lequel peuvent aussi apparaître des vulnérabilités. KICS a été téléchargé plus de 460 000 fois à ce jour. Il couvre les principaux outils d’infrastructure-as-code (Terraform, Kubernetes, Docker, AWS CloudFormation, Ansible et Helm) et est également intégré dans notre plateforme.

Nous avons aussi une solution de sécurité pour les interfaces de programmation applicatives (API). La sécurité des API est un sujet chaud. C’est d’ailleurs notre équipe de sécurité qui a écrit le OWASP top 10 pour la sécurité des API.

Enfin, nous avons un produit qui s’appelle Codebashing, issu d’une entreprise anglaise que nous avons acquise il y a quatre ans. C’est un outil de formation contextuelle en ligne pour les développeurs.

Pouvez-vous détailler un peu les enjeux et votre approche sur ce sujet essentiel de la formation des développeurs à la sécurité ?

Avant, les formations à la sécurité pour les développeurs étaient souvent rapidement dépassées, avec au mieux une vidéo YouTube par an sur le sujet. L’idée de Codebashing était de donner aux développeurs l’accès à de courtes vidéos contextuelles. Quand nous trouvons une vulnérabilité, nous préparons une leçon de 5-8 minutes sur celle-ci, sous une forme actionnable et gamifiée. Les participants doivent hacker un serveur en utilisant l’exploit en question, c’est ce qui leur permet de comprendre. C’est une solution où l’on peut consommer des leçons en fonction du contexte, mais il est également possible d’inviter tous les développeurs à se former dessus de façon plus globale et de suivre leur progression. La solution aborde la plupart des vulnérabilités courantes, comme les injections SQL. Une majorité de ces failles peuvent facilement être évitées par des équipes de développement formées.

Prendre en compte la sécurité dès le développement n’est pas forcément simple, mais c’est toute l’ambition de DevSecOps. De votre point de vue, où en est l’adoption de cette approche ?

Concernant DevSecOps, nous observons une accélération de l’adoption. Le fait d’avoir des outils developer-friendly comme le nôtre y contribue. La question n’est pas tant de savoir combien de vulnérabilités sont trouvées, mais surtout combien sont corrigées, d’où l’importance de fournir des éléments actionnables aux développeurs. Il faut prioriser les résultats remontés, en indiquant le top 10 des failles à corriger immédiatement, dans une vision de MVP (produit minimum viable).

Selon vous, la sécurité applicative peut-elle être agile ?

Cela dépend des outils de scan. Sur notre outil SCA, si une faille est détectée dans une version d’un composant, nous pouvons simplement recommander une mise à jour, c’est une tâche facile qui ne requiert pas un grand effort. Avec SAST, les failles trouvées sont dans votre propre code, c’est plus ardu, car l’action recommandée nécessite alors de modifier ce code.

Comment procédez-vous pour identifier de nouvelles vulnérabilités à intégrer dans vos solutions ?

Nous avons une équipe de recherche d’une quinzaine de personnes, chargées de détecter de nouvelles vulnérabilités. Parmi les plus notables figure une faille d’Android OS que nous avons découverte en 2019, qui permettait d’hacker la caméra, le GPS et de se connecter à n’importe quel terminal Android dans le monde. Celle-ci a depuis été corrigée par Google. Nous avons aussi trouvé des failles dans l’application Tinder, dans Alexa ou encore dans un robot aspirateur qui était équipé d’une caméra vidéo. Cette équipe réalise des Proofs of Concept, qui sont ensuite traduits dans nos solutions par nos équipes de développement (dont une grande équipe basée au Portugal).

Envisagez-vous de vous appuyer sur du machine learning pour la détection de failles ?

C'est une question qu’on nous pose fréquemment. Dans notre domaine, les données changent très vite ; or l’un des prérequis pour le machine learning est de disposer de suffisamment de données de bonne qualité. Nous regardons ces technologies, mais nous pensons qu’il faudra encore quelques années avant que celles-ci soient matures dans notre domaine.