La cybersécurité est confrontée à un problème étrange.
Tout le monde dit vouloir réduire les risques. Mais trop souvent, la manière dont nous évaluons les produits récompense quelque chose de plus restreint : la rapidité avec laquelle un fournisseur peut démontrer de la valeur lors d'une POC.
Peut-il être déployé rapidement ? Peut-il fonctionner sans agent ? Peut-il produire un rapport clair ? Peut-il s'aligner sur OWASP, NIST, l'EU AI Act ou le dernier cadre de référence ? Peut-il cocher suffisamment de cases dans l'appel d'offres ?
Le piège des cases à cocher
Les équipes de sécurité sont débordées. Chaque année apporte une nouvelle surface d'attaque, catégorie, cadre de référence et exigence de conformité.
Alors les acheteurs simplifient. Ils créent des grilles. Ils comparent les fonctionnalités. Ils demandent un déploiement rapide, une valeur immédiate et une couverture des cadres de référence.
C'est logique. Mais cela a une conséquence inattendue.
La manière dont nous évaluons les produits de sécurité façonne ce que les startups développent. Si le marché récompense une valeur rapide en POC, des tableaux de bord sans agent, une large couverture des cases à cocher et des rapports soignés plus que la profondeur, la précision et l'opérationnalisation, les startups construiront pour ce marché.
Le délai rapide de création de valeur est important. Le déploiement sans agent est important. La couverture des cadres de référence est importante. Mais lorsque ceux-ci deviennent l'unique critère d'évaluation, nous créons un marché où les startups optimisent pour les deux premières semaines d'une POC au lieu des cinq prochaines années de réduction des risques pour l'entreprise.
L'IA va aggraver la situation
Une petite équipe peut désormais coder à l'instinct une interface utilisateur propre, quelques flux de travail, un rapport soigné et suffisamment de correspondance avec les cadres de référence pour paraître crédible. Cela ne signifie pas qu'il peut survivre dans une entreprise.
Nous ne remplacerions jamais Salesforce par un CRM codé à l'instinct après avoir vu trois beaux écrans. Nous nous demanderions s'il est évolutif, s'il s'intègre à l'entreprise, s'il prend en charge les autorisations et les flux de travail, s'il produit des preuves d'audit, s'il forme les utilisateurs et s'il survit à des années d'utilisation opérationnelle.
La sécurité mérite le même niveau d'exigence.
Les cadres de référence sont utiles. Les cases à cocher ne suffisent pas.
Les cadres de référence comme OWASP, NIST, l'EU AI Act, MITRE et CIS donnent aux équipes un langage commun. L'erreur est de traiter chaque exigence comme une question oui/non.
Prenons BOLA, Broken Object Level Authorization (Autorisation au niveau de l'objet brisée), le risque numéro un dans le Top 10 des API OWASP. En termes simples, BOLA signifie qu'un utilisateur peut accéder aux données d'une autre personne en modifiant un identifiant.
Imaginez que j'ouvre mon application bancaire et que l'application appelle :
GET /accounts/12345
L'API renvoie mon nom, mon e-mail, mon solde, mes transactions récentes et les quatre derniers chiffres de mon compte bancaire. Si un attaquant modifie l'identifiant et obtient les détails du compte d'un autre client, c'est une BOLA.
Dans de nombreuses évaluations, le test est évident : un scanner envoie 1 000 appels d'API en quelques secondes, en modifiant rapidement les identifiants. La plupart des outils peuvent le détecter. C'est bruyant, rapide et facile à reconnaître.
Les vrais attaquants sont plus patients. Ils peuvent énumérer lentement sur des heures ou des jours, utiliser des jetons valides, changer une valeur toutes les quelques minutes et se déplacer entre les comptes, les points d'accès, les sessions, les régions ou les unités commerciales. Chaque requête peut sembler normale en soi.
Agents d'IA aggravent la situation. Si des agents sont connectés à ces API, les attaquants peuvent les utiliser pour explorer et exploiter plus rapidement les chemins d'autorisation faibles. La vulnérabilité de l'API était déjà grave. L'accès agentique la rend évolutive.
Chez Salt, nous avons beaucoup investi dans un moteur d'intention big data pour détecter ce comportement lent et discret : pas seulement si quelqu'un a modifié un identifiant, mais si son comportement révèle une intention d'énumérer des objets auxquels il ne devrait pas avoir accès.
Les équipes qui ont testé cela ont compris la différence. Mais de nombreuses évaluations n'avaient pas de moyen clair de le noter. Si deux fournisseurs affichaient tous deux « BOLA détecté » lors du test bruyant, ils obtenaient tous deux la même coche.
La profondeur a disparu dans la feuille de calcul.
Le showroom n'est pas la route
Une POC est le showroom. La production est la route.
Dans le showroom, tout est contrôlé. L'ensemble de données est limité. Le fournisseur surveille de près. Le tableau de bord est propre. Le rapport est bon.
Ensuite, la solution est mise en production, et de vraies équipes en héritent.
L'AppSec trie les résultats. Le SOC décide de ce qui est important. L'ingénierie a besoin de tickets qu'elle peut corriger. Le risque a besoin de preuves. Les unités commerciales ont besoin d'appropriation. Les outils existants ont besoin d'intégration.
Souvent, les évaluateurs ne sont pas les utilisateurs quotidiens. C'est pourquoi l'opérationnalisation est importante.
Le vrai test n'est pas la clarté de la première semaine. C'est de savoir si le produit crée toujours de la valeur six mois plus tard, à travers les unités commerciales, les équipes distribuées, les données bruyantes, les exceptions, les lacunes en matière de propriété et les vrais attaquants.
Il en va de même pour le fournisseur : aide-t-il à construire le programme, à former les équipes et à favoriser l'adoption, ou ne réagit-il qu'après la signature de l'accord ?
Nous l'avons appris à la dure
Chez Salt, nous l'avons appris à la dure.
Nous avons commencé par la technologie. Nous nous sommes d'abord concentrés sur les problèmes les plus difficiles : l'analyse comportementale approfondie, la détection précise, les modèles d'attaque complexes et une compréhension en temps réel que les approches superficielles manquent souvent.
Certains clients ont immédiatement compris pourquoi cette profondeur était importante. Mais de nombreuses évaluations n'étaient pas conçues pour la mesurer. Elles étaient conçues pour comparer des caractéristiques : se déploie-t-il rapidement, prend-il en charge ce framework, dispose-t-il de ce rapport et présente-t-il quelque chose d'impressionnant dès la première réunion ?
Cela nous a forcés à tirer une leçon importante : la profondeur compte, mais elle doit aussi être présentée d'une manière que le marché puisse adopter.
Nous avons donc construit le parcours : valeur sans déploiement, visibilité et gouvernance sans agent, puis protection complète en temps réel. Faciliter le démarrage, sans sacrifier la profondeur nécessaire pour réellement sécuriser une entreprise.
Cela a pris plus de huit ans. Une réelle profondeur de sécurité est difficile à construire. Si les évaluations ne la mesurent pas, moins d'entreprises y investiront.
Évaluez la route, pas seulement la vitrine
L'écosystème des startups réagit aux incitations.
Si les acheteurs récompensent les tableaux de bord immédiats, les correspondances étendues de frameworks et le déploiement sans friction par-dessus tout, les fournisseurs s'optimiseront pour cela.
Demandez donc ce que l'outil ne peut pas voir sans une intégration plus poussée ou une visibilité en temps réel. Demandez dans quelle mesure il couvre chaque exigence et comment il se comporte lorsque l'environnement est désordonné. Demandez ce qui se passe six mois plus tard, lorsque de vraies équipes, des flux de travail, des attaquants et des conséquences se manifestent.
La valeur rapide compte. Mais elle doit devenir une valeur plus profonde.
Les POVs comptent. Les RFPs comptent. Les frameworks comptent.
Mais ils ne sont pas l'objectif.
L'objectif est de rendre l'entreprise plus sûre.
Si nous voulons que les startups construisent pour cela, nous devons évaluer pour cela.
Les agents d'IA stimulent l'innovation, mais ils introduisent également des risques invisibles. La plateforme de sécurité Agentic™ de Salt vous offre une visibilité et un contrôle complets, afin que vous puissiez réduire les risques, assurer la conformité et rester résilient. Réserver une démo pour en savoir plus.