Le DSPM existe parce que les données sensibles ne sont plus statiques.
Au-delà de la base de données, les données sensibles se trouvent dans les journaux, les files d'attente, les outils SaaS, les systèmes de support, les pipelines d'analyse, les entrepôts de données, les sauvegardes, et maintenant les invites d'IA et les bases de données vectorielles. Elles se déplacent parce que l'application les déplace. L'adresse e-mail d'un client peut commencer dans un formulaire d'inscription, transiter par une API, être écrite dans Postgres, apparaître dans un journal d'application, être copiée dans Snowflake, transiter vers un outil de support, être envoyée à Stripe, puis éventuellement être intégrée ultérieurement dans un flux de travail d'IA. Et cela est considéré comme un flux de travail assez normal.
Ainsi, lorsque l'on parle de DSPM, ou Data Security Posture Management, l'idée de base est assez simple. Il s'agit d'aider les équipes à comprendre où se trouvent les données sensibles, de quel type de données il s'agit, qui ou quoi peut y accéder, comment elles sont protégées et où elles peuvent être exposées.
La plupart des entreprises ne disposent pas d'une cartographie parfaite de l'emplacement des données sensibles. Elles savent qu'elles possèdent des données clients, des détails de paiement, des jetons, des données d'employés, et maintenant toutes sortes de contextes d'IA. Ce qu'elles ne savent pas toujours, c'est où toutes ces données ont abouti, qui peut y accéder, ou si elles sont traitées d'une manière qui correspond à leurs attentes en matière de sécurité et de conformité.
La visibilité est le problème que le DSPM traditionnel tente de résoudre.
Le DSPM traditionnel commence là où les données ont atterri
Le DSPM traditionnel commence principalement par le patrimoine de données. Cela implique généralement l'analyse des systèmes de stockage et des plateformes connectées : buckets S3, bases de données, entrepôts de données, applications SaaS et sauvegardes.
L'outil recherche les données sensibles, les classe, vérifie les permissions et l'exposition, et aide l'équipe de sécurité à prioriser ce qui est important. Il pourrait vous indiquer qu'un bucket S3 contient des PII. Ou qu'une table d'entrepôt contient des données liées aux paiements. Ou qu'un partage de fichiers est trop largement accessible. Ou qu'une sauvegarde contient des enregistrements clients de production stockés dans un endroit que personne n'a consulté depuis un an.
C'est évidemment utile. De nombreuses données sensibles circulent dans les environnements modernes, et une grande partie d'entre elles est copiée, répliquée, exportée, journalisée, synchronisée, archivée et oubliée. Le DSPM traditionnel aide les équipes à les retrouver. Il offre à l'équipe de sécurité une meilleure vue du patrimoine de données réel, au-delà des simples ressources cloud qui l'entourent.
Mais pour les développeurs et les équipes AppSec, c'est souvent la deuxième partie de l'histoire.
La première partie est de savoir comment les données sont arrivées là.
La question manquante est le chemin du code
Un outil DSPM traditionnel pourrait dire : « Des PII ont été trouvées dans ce magasin de journaux. »
Mais le développeur doit encore comprendre pourquoi les PII sont là, quelle partie de l'application les a écrites, si c'était intentionnel, et quel changement permettrait réellement de corriger le problème. Et pour cela, il faut examiner le code.
L'application a collecté les données, les a traitées et a décidé quels champs retourner depuis une API. Elle a ensuite enregistré le corps de la requête, transmis un jeton à un worker, envoyé les métadonnées client à un fournisseur, et construit l'invite qui incluait un contexte sensible.
Ainsi, la question plus orientée développeur devrait aller au-delà de « Où sont stockées les données sensibles ? » pour devenir « Quel chemin de code a créé l'exposition ? » C'est la version shift-left du DSPM.
Le DSPM basé sur le code commence par l'application plutôt que par la couche de stockage. Il examine les API, les modèles ORM, les appels de journalisation, les consommateurs de files d'attente, les workflows CI/CD, les intégrations d'IA, et plus encore. L'objectif est de comprendre comment les données sensibles entrent dans le système, comment elles se déplacent, où elles sont stockées, où elles sortent et où elles pourraient être mal gérées.
DSPM basé sur le code et Audits d'exposition des données
Chez Aikido, je pense que la manière la plus claire de décrire notre DSPM basée sur le code est de la considérer comme un audit d'exposition des données, qui utilise l'IA pour détecter les flux de données sensibles et les risques de sécurité dans le code.
Un audit d'exposition des données couvre les PII, PHI, PCI, les secrets, les jetons, le contenu client et la gestion des données liées à l'IA. Chaque résultat est accompagné de preuves et d'une remédiation dans le code, sans nécessiter de connexion directe aux bases de données.
La lecture du code peut également révéler des protections de données faibles. Elle peut signaler un champ sensible stocké sans chiffrement, une clé codée en dur dans le code source, MD5, SHA1 ou base64 utilisés comme s'il s'agissait de chiffrement, un secret commité dans le dépôt, et des données sensibles envoyées via un canal non sécurisé.
Il y a une autre façon d'aborder cela. Le DSPM traditionnel nécessite un accès à vos données réelles, se connectant aux buckets S3, aux bases de données et aux entrepôts de données pour scanner leur contenu. Le DSPM basé sur le code lit plutôt le code qui crée et déplace ces données, il ne demande donc jamais d'accès ni ne télécharge quoi que ce soit. La lecture à partir du code réduit la barrière à l'activation, car il n'y a pas de nouvel accès de production à accorder.
Cela le rend également plus rapide, car il n'y a rien à crawler. C'est aussi plus précis, car il lit comment un champ est utilisé plutôt que de supposer que n'importe quel nombre à neuf chiffres est un numéro de sécurité sociale. Le résultat est une cartographie de l'endroit où les données sensibles résident dans votre architecture et comment elles sont protégées, entièrement construite à partir du code.
Chez Aikido, cela s'exécute dans le cadre de l'analyse de code par IA, ainsi l'Audit d'exposition des données se positionne aux côtés du reste de la code review plutôt que comme une intégration d'accès aux données distincte.
Comment la qualité des résultats diffère
Prenons la journalisation comme un exemple simple.
Un produit DSPM traditionnel pourrait éventuellement vous indiquer que des PII existent dans les logs d'application. Encore une fois, utile. Mais maintenant, quelqu'un doit aller chercher la source.
Un Audit d'exposition des données basé sur le code peut raconter une histoire plus complète en connectant les données, le chemin du code, la destination, le risque d'exposition et la correction. Cela le rend plus utile pour les développeurs.
Par exemple, le contrôleur de paiement enregistre l'objet `billingDetails` complet lorsque l'autorisation de paiement échoue. Cet objet inclut l'e-mail, le numéro de téléphone, l'adresse de facturation et les quatre derniers chiffres de la carte. Les logs sont envoyés à Datadog. La correction consiste à masquer ces champs avant la journalisation et à ne conserver que l'ID client, l'ID d'intention de paiement et le code d'erreur.
C'est une information très différente de celle que vous obtenez d'un DSPM traditionnel.
La même chose s'applique aux secrets et aux tokens. Prenons un token SCM utilisé pour lire le code de GitHub, GitLab ou Bitbucket. Une vue orientée stockage pourrait se demander si le token est chiffré dans la base de données. Ce n'est cependant pas toute l'histoire.
Où le token entre-t-il dans la plateforme ? Est-ce un token OAuth, un token d'application GitHub ou un PAT soumis par l'utilisateur ? Quels scopes possède-t-il ? Comment est-il validé ? Où est-il chiffré ? Où est-il stocké ? Quand est-il déchiffré ? Est-il mis en cache ? Est-il intégré dans une URL de clonage ? Est-il transmis à un worker ? Pourrait-il fuir via les logs, les traces, les erreurs, les arguments de processus ou la télémétrie ? C'est un problème de sécurité des données, mais le code nous dit ce que nous devons savoir sur son mouvement.
Du tableau de bord à la correction
C'est là que le DSPM basé sur le code devient intéressant, à mon avis.
La meilleure version de cela n'est pas un autre tableau de bord qui dit : « Vous avez des données sensibles. » Tout le monde le sait. La meilleure expérience dit : voici l'inventaire des données sensibles, voici le flux, voici le risque d'exposition, voici les contrôles pertinents, et voici la modification de code qui réduit le risque.
Si le code a créé l'exposition, la correction appartient probablement au code.
Le workflow typique du développeur devrait donc être :
- Masquer les champs sensibles avant la journalisation.
- Retourner un objet de réponse API plus petit.
- Ajouter une vérification de propriété du locataire.
- Arrêter de passer des tokens dans les URL.
- Masquer les données de production avant de les restaurer en environnement de staging.
- Ajouter un chiffrement avant le stockage.
- Supprimer les données client d'une invite de LLM.
- Corriger la logique de suppression afin que les enregistrements dépendants soient effectivement supprimés.
L'ingénieur souhaite savoir quel chemin de code spécifique crée un risque spécifique d'exposition des données et comment y remédier.
Cela rend également le lien avec les cadres de sécurité et de conformité beaucoup plus concret. Si un jeton est mal géré, cela peut avoir des implications pour la gestion des authentificateurs, la protection de la transmission, le principe du moindre privilège et la protection des journaux d'audit. Si des PII sont enregistrées sans masquage, cela peut avoir des implications pour la confidentialité, la rétention, la minimisation des données et les contrôles de surveillance. Si des données client sont copiées en environnement de staging sans masquage, cela peut affecter le contrôle d'accès, la séparation des environnements et les obligations de conformité. Si des enregistrements survivent à une demande de suppression, ou si des données persistent au-delà de leur fenêtre de rétention, cela est directement lié aux obligations du GDPR et du CCPA, et doit être corrigé dans la logique de suppression et de rétention elle-même.
La constatation qui se contente de dire « Modèle de journalisation non sécurisé » est assez limitée dans son utilité. Mais une information telle que « Les PII client transitent vers les journaux via ce chemin de code, ce qui crée un risque d'exposition des données, affecte ces contrôles et peut être corrigé en masquant ces champs avant la journalisation » est exploitable.
C'est une bien meilleure façon de réunir l'ingénierie, l'AppSec et la conformité dans la même conversation.
La version simple
Le DSPM traditionnel reste important. Il aide les équipes à comprendre où résident les données sensibles dans l'environnement réel. Il peut détecter les buckets oubliés, les bases de données exposées, les données fantômes et les stockages avec des permissions excessives.
Mais le DSPM basé sur le code ajoute la couche applicative manquante. Il aide à expliquer comment les données sensibles y parviennent, comment elles se déplacent, où se situe le mécanisme d'exposition et ce que les développeurs peuvent faire à ce sujet.
Ainsi, la version simple se présente comme suit :
Le DSPM traditionnel trouve les données sensibles là où elles résident.
Le DSPM basé sur le code découvre comment les données sensibles sont exposées.
Un audit d'exposition des données relie ce flux au code, à la lacune de contrôle et à la correction.
C'est la version shift-left du DSPM. Et pour les développeurs et les équipes AppSec, c'est probablement la version qui aide le plus les équipes.
Aikido propose le premier de son genre en matière de DSPM basé sur le code. Protégez et suivez vos données, sans même connecter vos bases de données.
