Ronen Slavin, CTO et co-fondateur, Cycode – Série d’entretiens

Ronen Slavin, CTO et co-fondateur, Cycode, est un entrepreneur en série et ancien officier de l’unité 8200 des Forces de défense d’Israël. Avant de lancer Cycode en 2019, il a co-fondé FileLock, qui a été acquis par Reason Security en 2018, et a occupé le poste de responsable de la recherche chez Reason Cybersecurity. Avec une expertise approfondie en détection de logiciels malveillants, en recherche de vulnérabilités et en exploitation, Slavin a construit une carrière à l’intersection de la recherche en sécurité avancée et de l’innovation de produits.

Cycode est une plateforme de sécurité d’application native AI qui unit les équipes de sécurité et de développement avec un contexte actionnable du code à l’exécution. En convergeant AST, ASPM et la sécurité de la chaîne d’approvisionnement logicielle, elle sécurise à la fois le code généré par l’AI et le code généré par l’homme. Propulsée par son graphique d’intelligence de risque (RIG), ses analyseurs propriétaires et ses intégrations, Cycode fournit une détection de risque instantanée, une analyse d’impact des modifications (CIA) et des correctifs pilotés par l’AI – en fermant les lacunes de visibilité, en accélérant la correction et en réduisant les coûts dès le premier jour.

Qu’est-ce qui vous a motivé à lancer Cycode, et quel problème clé en matière de sécurité des logiciels vouliez-vous résoudre dès le début ?

L’idée de Cycode est née de quelque chose que nous avions observé à plusieurs reprises ; le code source étant volé ou involontairement divulgué aux mauvaises personnes. Après avoir passé des années dans la cybersécurité et l’espace de la sécurité offensive, et dirigé la protection des points de terminaison chez Reason, nous sommes arrivés à la conclusion que le code source est extrêmement critique – pas seulement en tant que lignes de code, mais en tant que l’un des actifs les plus précieux d’une entreprise. Il ne recevait pas la sécurité qu’il méritait.

Cette prise de conscience éclairante est ce qui m’a inspiré pour lancer Cycode. Dès le départ, notre mission était claire : protéger le code source à chaque étape, du moment où il est écrit au moment où il est expédié, le tout sans entraver la dynamique et la traction des développeurs. Nous nous sommes efforcés de garantir que la sécurité et l’ingénierie puissent travailler côte à côte, avec la sécurité intégrée de manière transparente dans le flux de travail quotidien, plutôt que d’être un obstacle.

Ce qui importait le plus, c’était de donner aux équipes la visibilité, la responsabilité et la collaboration dont elles avaient besoin. Les développeurs ne devraient pas avoir à sacrifier leur productivité pour la sécurité, et les équipes de sécurité ne devraient pas avoir à fonctionner sans contexte ou contrôle. Cycode a été créé pour rendre les deux possibles.

Comment votre expérience précédente en tant qu’entrepreneur en cybersécurité et votre service dans l’unité d’élite de renseignement d’Israël, l’unité 8200, ont-ils façonné votre approche technique chez Cycode ?

Mon temps dans l’écosystème de la cybersécurité d’Israël, en particulier dans des environnements techniques de pointe, m’a inculqué une mentalité d’exactitude, d’adaptabilité et de curiosité sans relâche. Que j’étais à l’unité 8200 ou dans mes premiers jours de startup, j’ai appris à penser comme un attaquant et un défenseur. Cette perspective duale a été fondamentale pour la façon dont nous avons construit Cycode.

En tant qu’entrepreneur en cybersécurité, j’ai vu de première main à quel point le paysage de la sécurité était devenu fragmenté et réactif. Les outils de sécurité étaient souvent ajoutés après coup, laissant les développeurs naviguer dans un labyrinthe d’alertes sans contexte. C’est ce que nous nous sommes efforcés de changer.

Chez Cycode, nous avons adopté une approche de niveau système, en traitant le code source comme un actif critique et en intégrant la sécurité dans le cycle de vie du développement logiciel dès le départ. Mon expérience m’a enseigné que la sécurité doit être proactive, contextuelle et conviviale pour les développeurs. C’est pourquoi nous nous concentrons beaucoup sur l’automatisation, la visibilité et le pont entre la sécurité et le développement logiciel. Il ne s’agit pas seulement de trouver des vulnérabilités, mais de résoudre ce qui compte, rapidement.

Cycode combine plusieurs couches de protection, notamment AST (Application Security Testing) et ASPM (Application Security Posture Management). Pour ceux qui ne sont pas familiers, pouvez-vous expliquer comment ces éléments fonctionnent ensemble – et ce qui rend l’approche de Cycode unique ?

Absolument. Chez Cycode, sécuriser les logiciels modernes nécessite plus que de simplement analyser le code ; cela exige une compréhension holistique de la façon dont ce code est construit, déployé et maintenu. Maintenant, en tant que plateforme de sécurité d’application native AI, notre approche est un différentiateur en raison de la convergence de l’Application Security Testing (AST), de l’Application Security Posture Management (ASPM) et de la sécurité de la chaîne d’approvisionnement logicielle (SSCS).

Les outils AST, tels que SAST, DAST et SCA, sont efficaces pour identifier les vulnérabilités dans le code, les dépendances et l’infrastructure. Mais ils opèrent souvent dans des silos, générant des alertes sans contexte. C’est là que l’ASPM intervient. L’ASPM relie les points entre l’ensemble du cycle de vie du développement logiciel. Il fournit une visibilité sur la posture de sécurité de l’application avec une priorisation des risques et une remédiation actionnable, le SSCS sandwichant la plateforme pour sécuriser les pipelines CI/CD.

Ce qui rend Cycode unique, c’est la façon dont nous unifions ces couches et établissons une nouvelle norme d’entreprise. Aujourd’hui, à l’ère de l’AI, la sécurité devra devenir plus intelligente. Nous avons construit sur notre fondation avec l’AST, l’ASPM et le SSCS avec des agents AI pour aider à prioriser et à corriger ce qui compte plus rapidement, en fermant cette faille de sécurité que j’ai mentionnée plus tôt.

Comment Cycode s’intègre-t-il aux pipelines DevOps modernes comme GitHub, GitLab ou Azure DevOps pour détecter les risques plus tôt dans le cycle de vie ?

Cycode a été conçu en tenant compte des DevOps modernes. Nous nous intégrons directement aux plateformes comme GitHub, GitLab et Azure DevOps pour intégrer la sécurité dans chaque phase du cycle de vie du développement logiciel, sans ralentir les équipes.

Notre plateforme se connecte aux systèmes de contrôle de source et de CI/CD pour surveiller en continu le code, les configurations et les flux de travail. Nous analysons et traitons les demandes d’extraction en temps réel, de sorte que les développeurs reçoivent des commentaires immédiats sur les vulnérabilités avant que le code ne soit fusionné. Nous analysons également l’historique des validations et les métadonnées pour attribuer les problèmes aux propriétaires appropriés, en réduisant ainsi les frictions et en accélérant la correction.

Dans notre approche, nous ne surfacions pas seulement les alertes ; nous fournissons un contexte complet. Cela inclut l’origine du problème, son impact potentiel et les étapes pour le résoudre. Et comme nous nous intégrons à des outils comme JIRA, nous pouvons créer et suivre automatiquement les tickets, en gardant ainsi la sécurité et l’ingénierie en phase.

En fin de compte, notre objectif est de déplacer la sécurité vers la gauche de manière contrôlée et conviviale pour les développeurs, de sorte que les risques soient identifiés tôt, traités rapidement et ne deviennent pas des bloqueurs plus tard dans le pipeline.

Pouvez-vous nous guider à travers la façon dont le graphique d’intelligence de risque de Cycode aide les équipes à relier les menaces à travers le code, les conteneurs, l’infrastructure et l’exécution ?

Oui, c’est une fonctionnalité dont nous sommes fiers. Le graphique d’intelligence de risque, ce que nous appelons RIG, est le moteur derrière la capacité de Cycode à corréler et à contextualiser les données de sécurité dans l’ensemble de la chaîne d’approvisionnement logicielle.

Pensez au RIG comme une carte dynamique qui relie tout, des codes source et des dépendances open source aux pipelines CI/CD, aux registres d’artefacts et aux environnements d’exécution. Il ne collecte pas seulement des données – il comprend les relations. Lorsqu’une vulnérabilité est découverte dans un conteneur, le RIG peut la retracer jusqu’à la ligne de code exacte, au développeur qui l’a validé, au pipeline qui l’a construit et à l’infrastructure sur laquelle il s’exécute.

Cette visibilité est critique. Elle permet aux équipes de sécurité de prioriser les risques en fonction de leur impact réel, et non seulement de leur score de gravité. Avec l’AI intégrée, il fournit aux développeurs des informations actionnables et un contexte complet, leur permettant de corriger les problèmes plus rapidement et avec plus de confiance.

Il est important de noter que le RIG n’est pas seulement un tableau de bord ; c’est un outil de prise de décision. Il aide les équipes à passer de la détection à la résolution à la vitesse des DevOps, en reliant les points entre les systèmes fragmentés et en mettant en évidence les risques qui comptent vraiment.

Comment Cycode détecte-t-il et gère-t-il les risques liés au code généré par l’AI et aux intégrations avec des services comme OpenAI ou Hugging Face ?

Le code généré par l’AI introduit une nouvelle couche de complexité et de risque, en particulier lorsque celui-ci provient de services externes tels que OpenAI ou Hugging Face. Chez Cycode, nous avons construit des capacités spécifiquement pour répondre à ce paysage de menaces en évolution. Récemment, notre agent d’exploitabilité AI et le serveur MCP pour sécuriser les flux de travail de développement et de codage AI.

En ce qui concerne notre plateforme, nous fournissons un inventaire d’actifs d’application centralisé qui cartographie tous les composants d’un écosystème logiciel, y compris les modèles AI, les bibliothèques AI tierces et les intégrations avec des services comme OpenAI ou Hugging Face. Cela fournit aux équipes une visibilité complète sur l’utilisation de l’AI, même si elle est profondément intégrée dans la pile.

Deuxièmement, nous utilisons des outils d’analyse de code propriétaires qui vont au-delà de la correspondance de motifs. Ces outils peuvent détecter les modèles de code généré par l’AI et identifier les bibliothèques ou les frameworks couramment associés au machine learning, au NLP ou à l’AI générative – même si ils ne sont pas explicitement étiquetés comme tels.

Troisièmement, Cycode scanne en continu les vulnérabilités spécifiques à l’AI, comme les surfaces d’attaque adverses, les risques de poisoning de données et les menaces d’extraction de modèles. Ce sont des vecteurs émergents que les outils AST traditionnels manquent souvent. Nous priorisons ces risques en fonction de la gravité et de l’impact commercial, et nous fournissons des conseils de remédiation adaptés au contexte de l’AI.

Enfin, nous aidons les organisations à rester conformes aux réglementations comme l’Acte AI de l’UE en automatisant la documentation et en fournissant une transparence sur l’utilisation de l’AI à travers l’application. Cela inclut la génération de rapports sur les composants AI, leur objectif et leur impact potentiel, ce qui est essentiel à la fois pour la gouvernance interne et les audits externes.

En résumé, Cycode ne détecte pas seulement les risques liés à l’AI ; il aide à les gérer avec un contexte complet, une responsabilité et une conformité en tête.

Quels sont les plus grands défis dans la détection de secrets à travers les environnements SDLC modernes, et comment Cycode résout-ils ?

La détection de secrets est l’un des défis les plus critiques et négligés dans le développement logiciel moderne. Les secrets, tels que les clés API, les jetons et les informations d’identification, sont souvent codés en dur dans le code source, les pipelines CI/CD et les fichiers de configuration. Et avec l’essor des équipes distribuées, des dépendances open source et des cycles de publication rapides, ces secrets peuvent facilement fuiter dans les référentiels publics ou être exploités par les attaquants.

Le défi est que les secrets ne se trouvent plus seulement dans le code. Ils sont partout, dans les environnements de construction, les registres d’artefacts et même les outils tiers. Les analyseurs traditionnels les manquent souvent ou génèrent un bruit excessif, ce qui rend difficile pour les équipes de prendre des mesures.

Chez Cycode, nous adoptons une approche holistique de la sécurité. Notre plateforme scanne l’ensemble du SDLC, du référentiel de code aux pipelines CI/CD et aux environnements d’exécution, pour détecter les secrets exposés en temps réel. Nous corrélons les résultats avec le contexte, de sorte que les équipes sachent non seulement ce qui a été exposé, mais où, par qui et à quel point c’est critique.

Nous appliquons également un accès à privilèges minimum et sécurisons les configurations de pipeline pour empêcher les secrets d’être mal utilisés. Et comme nous nous intégrons aux systèmes de suivi des problèmes et aux flux de travail des développeurs, la correction est rapide et sans friction.

En fin de compte, la détection de secrets ne consiste pas seulement à trouver la fuite, mais à sécuriser l’ensemble de l’usine logicielle. C’est ce à quoi la plateforme de Cycode est conçue pour le faire.

Comment assurez-vous l’exactitude et réduisez les faux positifs lors de l’analyse des vulnérabilités ou des secrets ?

Faire face aux faux positifs peut être extrêmement frustrant pour les développeurs. Lorsque les équipes sont constamment bombardées d’alertes non pertinentes, il est facile de commencer à les ignorer, et c’est précisément lorsque les menaces réelles peuvent passer inaperçues. Grâce à notre moteur SAST, nous aidons les équipes à identifier les faiblesses du code, à atteindre l’exactitude et à se concentrer sur les vrais positifs pour gagner du temps et accélérer la livraison logicielle. Dans les tests de référence OWASP, Cycode a obtenu un taux de faux positifs de 2,1 %, représentant une réduction de plus de 94 % par rapport aux méthodes alternatives.

Tout d’abord, nous nous concentrons sur la corrélation contextuelle. Au lieu de simplement signaler un problème potentiel et passer à autre chose, notre plateforme relie cela à l’image plus large de la chaîne d’approvisionnement logicielle d’une organisation. Par conséquent, si un secret est découvert dans un commit, nous l’associons au pipeline qui l’a construit, à l’environnement dans lequel il a été déployé et au développeur qui l’a ajouté. Ce contexte supplémentaire nous aide à déterminer si quelque chose pose un véritable risque ou est simplement inoffensif.

Ensuite, nos algorithmes d’analyse propriétaires font beaucoup plus que la simple correspondance de motifs. Notre moteur de détection de secrets analyse les modèles, l’entropie et la façon dont la chaîne est utilisée, nous permettant de distinguer entre les secrets réels et les entités similaires, telles que les données de test ou le texte de remplacement.

Nous nous intégrons également aux systèmes de suivi des problèmes et aux flux de travail des développeurs pour garder tout connecté. Lorsqu’une vulnérabilité ou un secret est confirmé et corrigé, ces commentaires aident à rendre nos modèles plus intelligents. En attribuant les problèmes en fonction de la propriété du code, nous aidons à garantir que les problèmes sont dirigés vers les bonnes personnes sans duplication inutile.

En fin de compte, notre objectif est simple. Nous visons à rendre la sécurité quelque chose sur laquelle les équipes peuvent compter : moins de fausses alarmes, des résultats plus précis et des corrections plus rapides. De cette façon, les équipes peuvent se concentrer sur la résolution des problèmes réels qui comptent le plus.

Quelle est la valeur des outils de sécurité “développeur d’abord”, et comment Cycode évite-t-il de perturber les flux de travail ?

Au cœur, la sécurité “développeur d’abord” est à propos de rendre la protection rapide, pertinente et seulement aussi visible que nécessaire. C’est ainsi que nous maintenons le développement en cours tout en préservant la sécurité logicielle.

Si les outils de sécurité ralentissent les développeurs ou les submergent avec trop d’alertes, ces outils risquent d’être ignorés. C’est pourquoi Cycode a été conçu pour aider les développeurs plutôt que de les gêner.

La véritable valeur vient de l’intégration de la sécurité directement dans le flux de travail quotidien du développeur. Avec Cycode, les contrôles de sécurité se produisent instantanément, là où les développeurs écrivent et examinent le code, comme dans l’IDE ou lors des demandes d’extraction. Cela signifie que les développeurs reçoivent des commentaires au moment où ils en ont besoin, ce qui facilite la détection des problèmes tôt et la construction d’habitudes de codage sécurisées sans problèmes supplémentaires.

Le contexte est également clé. Au lieu d’envoyer des alertes vagues, Cycode fournit aux développeurs des détails précis : ce qu’est la vulnérabilité, d’où elle provient, qui en est responsable et comment la résoudre. Ce type d’informations aide à réduire la confusion et permet aux équipes de résoudre les problèmes plus efficacement.

En intégrant avec des outils CI/CD populaires et des suiveurs de problèmes comme JIRA, Cycode garantit que la sécurité devient une partie intégrante du processus de développement logiciel, plutôt que quelque chose de séparé ou déconnecté. Les développeurs peuvent rester sur la tâche, et les équipes de sécurité obtiennent la supervision dont elles ont besoin.

Quels types d’attaques ou de vulnérabilités vous attendez-vous à voir augmenter à mesure que davantage d’entreprises adoptent l’AI dans leurs flux de travail de développement ?

À mesure que l’AI devient une partie intégrante du travail de développement quotidien, nous sommes susceptibles de rencontrer un nouveau ensemble de vulnérabilités. Ceux-ci ne seront pas seulement des défis techniques – certains proviendront de la façon dont les personnes et les équipes interagissent avec ces outils.

L’un des risques les plus importants est que les développeurs puissent devenir trop dépendants du code généré par l’AI. Bien que l’AI puisse aider à accélérer le processus, elle n’est pas parfaite. Si les développeurs supposent que chaque suggestion AI est correcte, ils risquent d’introduire involontairement des bogues ou des problèmes de sécurité. Puisque les lignes de responsabilité peuvent devenir floues lorsque le code provient d’une machine, ces problèmes peuvent passer inaperçus.

Il existe également une préoccupation croissante concernant les attaques de la chaîne d’approvisionnement qui ciblent spécifiquement les modèles et les API AI. Par exemple, si des services de confiance comme OpenAI ou Hugging Face sont compromis, ou si quelqu’un insère un modèle malveillant dans un flux de travail, les attaquants pourraient modifier les sorties ou voler des informations sensibles.

Une autre menace émergente est l’empoisonnement des données. Dans ce scénario, les attaquants effectuent des modifications subtiles et stratégiques aux données d’entraînement qui peuvent plus tard affecter la façon dont le modèle AI se comporte. Ce type d’attaque est particulièrement dangereux dans des domaines tels que la détection de fraude ou le contrôle d’accès, où la sécurité est cruciale.

En outre, les entreprises seront confrontées à une pression croissante en matière d’explicabilité et de conformité. De nouvelles réglementations, telles que l’Acte AI de l’UE, exigeront que les organisations expliquent comment leurs systèmes AI prennent des décisions et les fondements de ces décisions. Cela peut être très difficile si les modèles sont des boîtes noires ou si les équipes utilisent des outils tiers qui manquent de transparence.

Chez Cycode, nous développons des outils pour aider les équipes à identifier les risques spécifiques à l’AI, tels que les vulnérabilités adverses, les abus de modèles et les intégrations non sécurisées. Nous voulons également nous assurer que les développeurs restent responsables du code qu’ils livrent, qu’il soit écrit par une personne ou généré de manière autonome.

En regardant cinq ans à l’avance, comment voyez-vous l’évolution du rôle de l’AI dans la sécurisation des chaînes d’approvisionnement logicielles ?

L’AI est déjà en train de transformer la façon dont nous abordons la sécurité des applications, mais son influence totale sur la chaîne d’approvisionnement logicielle ne fait que commencer. Au cours des cinq prochaines années, je crois que l’AI deviendra une partie intégrante de la façon dont nous identifions, priorisons et traitons les risques tout au long du processus de développement.

Tout d’abord, l’AI aidera à rapprocher les équipes de sécurité et de développement. Actuellement, il y a souvent une tension, car les outils de sécurité peuvent interrompre les flux de travail ou manquer de contexte essentiel. L’AI a le potentiel de lisser ces arêtes en transformant les résultats de sécurité en insights actionnables, en recommandant des correctifs automatiquement et même en générant des solutions de code sécurisées adaptées au flux de travail de chaque équipe.

L’AI deviendra également de plus en plus importante pour comprendre ce qui se passe en temps réel. Il surveillera les environnements de construction, les conteneurs et les API, en identifiant les activités inhabituelles à mesure qu’elles se produisent. Cette surveillance en temps réel sera essentielle à mesure que les attaques de la chaîne d’approvisionnement deviennent de plus en plus sophistiquées et difficiles à détecter avec la seule analyse traditionnelle.

En outre, l’AI aidera les entreprises à naviguer dans le labyrinthe croissant des réglementations. À mesure que les gouvernements introduisent plus de règles sur la façon dont l’AI devrait être utilisée, les organisations auront besoin d’outils qui peuvent expliquer le raisonnement derrière chaque décision AI, suivre d’où viennent les modèles et tenir les personnes responsables. Je vois l’AI intervenant pour créer une documentation, cartographier les dépendances et aider à appliquer les politiques à travers des systèmes complexes.

Toutefois, avec tous ces progrès, la supervision humaine restera critique. L’AI n’est pas là pour remplacer les personnes, mais pour les doter de capacités. Les développeurs et les équipes de sécurité devront toujours assumer la responsabilité, en particulier lorsque le code généré par l’AI pourrait introduire de nouveaux risques. C’est une grande raison pour laquelle nous nous engageons à construire des outils qui rendent l’AI aussi transparente, compréhensible et responsable que possible.

En fin de compte, l’AI deviendra le fil conducteur qui rendra les chaînes d’approvisionnement logicielles plus sûres, mais seulement si nous l’utilisons de manière réfléchie et gardons les personnes impliquées à chaque étape.

Je vous remercie pour cette excellente interview, les lecteurs qui souhaitent en savoir plus devraient visiter Cycode.