Sécurité, conformité et souveraineté — rendues transparentes.

En mode SaaS, nous stockons les données de la plateforme VAMIDAST exclusivement dans des centres de données situés en Allemagne ; les données au repos sont chiffrées et les transferts passent par TLS. Le cocontractant, le droit applicable et le for juridique sont allemands. Lorsqu’une fonction fait appel à des prestataires externes — par exemple Anthropic ou OpenAI pour les étapes d’IA —, nous indiquons le prestataire, la finalité et la région de traitement dans le tableau des sous-traitants ultérieurs. En mode on-premise, VAMIDAST fonctionne sur votre propre cluster Kubernetes.

VAMIDAST est exploité par VamiSec GmbH, dont le SMSI est certifié ISO/IEC 27001:2022 par Proks Certification GmbH, organisme accrédité DAkkS (certificat DE-IS-20250191, valable jusqu’au 18 septembre 2028). Selon le certificat, le périmètre couvre la « fourniture de prestations de conseil en sécurité de l’information, des produits numériques qui y sont liés et des installations de traitement de l’information associées … » (notre traduction du certificat allemand). VAMIDAST n’y est pas cité nommément ; il n’existe pas de certificat propre au produit.

La connexion à VAMIDAST s’effectue avec une authentification multifacteur (MFA). Pour l’authentification unique (SSO), VAMIDAST prend en charge votre propre annuaire Microsoft Entra ID (OIDC Authorization Code avec PKCE). Un annuaire n’est admis qu’une fois configuré par un administrateur de la plateforme et approuvé par votre administrateur général (Global Administrator) ; la MFA et la vérification d’identité relèvent alors d’Entra. VAMIDAST ne demande que les autorisations de connexion openid, profile et email — aucune autorisation Microsoft Graph — et ne stocke aucun jeton Microsoft. Les droits sont attribués exclusivement dans VAMIDAST : les claims de rôle ou de groupe des jetons n’accordent aucun droit. Avec le SSO, la connexion par mot de passe est désactivée par défaut ; les accès d’urgence (break-glass) sont réservés aux administrateurs de la plateforme, avec leur propre MFA et une entrée d’audit à chaque utilisation. VAMIDAST prend également en charge des comptes locaux avec e-mail et mot de passe. Vous pouvez révoquer l’accès à tout moment dans Entra.

Un moteur déterministe pilote chaque scan ; le modèle ne fait que conseiller et ne décide jamais de ce qui est testé ni de ce qui s’exécute ensuite. Dans le déroulement du scan, VAMIDAST utilise l’IA à exactement trois endroits : la classification de la catégorie de vulnérabilité en dernier recours, les payloads de repli (chaînes de détection uniquement) lorsqu’aucun outil ne convient ou qu’un outil échoue, et le triage de la zone grise. Chaque sortie du modèle est validée par schéma avant utilisation. Le modèle reçoit des extraits de réponse limités par défaut à 2 000 caractères, des noms de paramètres, des payloads et des éléments de preuve — jamais des corps complets ni les identifiants de test de l’application cible. Les extraits de réponse et les éléments de preuve peuvent toutefois contenir des données personnelles ou des secrets de l’application cible. VAMIDAST est agnostique vis-à-vis des LLM. Pour les étapes d’IA, vous choisissez le Qwen3.8 local du centre de données de VamiSec à Sankt Augustin (sur vos propres GPU en mode on-premise), Anthropic Claude, OpenAI ou votre propre LLM (BYOLLM). Avec Qwen3.8, les données de la cible restent en Allemagne ou sur votre infrastructure ; avec Anthropic Claude ou OpenAI, les extraits sont traités par le fournisseur aux États-Unis ; avec votre propre LLM, la relation contractuelle s’établit directement entre vous et le fournisseur. Les identifiants de votre propre LLM ne sont jamais stockés en clair, jamais journalisés et jamais restitués. En option — déclenchée par l’utilisateur après le scan et désactivable par l’exploitant —, le modèle peut aussi rédiger des textes d’accompagnement pour la remédiation. Il ne peut ni créer de constats ni modifier une évaluation ; les cookies, jetons Bearer et JWT, éléments de clé et valeurs de paramètres d’URL sont supprimés au préalable, et les textes générés par l’IA sont signalés dans le rapport PDF. Sans LLM, le scan continue ; seuls les payloads de repli et l’assistance au triage disparaissent.

Nous suivons un processus de réponse aux incidents défini, intégré à notre SMSI certifié ISO/IEC 27001, et informons les clients concernés ; les modalités sont fixées dans le DPA. Signalez-nous les vulnérabilités de sécurité en toute confidentialité à security@vamisec.com — lisible par machine selon la RFC 9116 : /.well-known/security.txt.

Non. Nous n’utilisons pas les données clients comme données d’entraînement : nous n’entraînons ni n’affinons aucun modèle d’IA avec elles, et nous ne connectons des modèles d’IA externes que dans le cadre de conditions contractuelles excluant toute utilisation pour l’entraînement. Le tableau des sous-traitants ultérieurs indique si VAMIDAST fait appel à des fournisseurs d’IA externes, et lesquels. Si vous utilisez votre propre LLM (BYOLLM), ce sont les conditions de votre contrat avec le fournisseur qui s’appliquent à ce modèle.

Les documents publics sont directement accessibles. Pour la déclaration d’applicabilité, le livre blanc sécurité ou les questionnaires renseignés, une brève demande à security@vamisec.com suffit ; les justificatifs soumis à NDA sont communiqués après signature.

VAMIDAST est conçu pour des scans sûrs. Un verrou de sécurité classe chaque requête active — y compris les requêtes de référence — comme lecture seule ou modification d’état et la bloque en cas de doute (fail closed). Il existe trois modes : Passif (exploration et lecture uniquement), Sûr (par défaut ; points de terminaison modifiant l’état uniquement par violation de précondition, pas de DELETE, PUT ni PATCH) et Agressif — uniquement après confirmation explicite d’un environnement hors production ; une valeur d’environnement « prod », erronée ou vide revient au mode Sûr. Les systèmes de production ne sont scannés qu’en mode Passif ou Sûr et uniquement avec autorisation. La liste de blocage (par exemple déconnexion, configuration, réinitialisation de base de données) s’applique dans tous les modes, les paramètres destructifs tels que mot de passe, rôle ou champs de suppression ne sont jamais fuzzés directement, et la limitation de débit, les délais d’expiration ainsi qu’un budget de requêtes par point de terminaison sont configurables. L’autorisation d’un test complet (full testing) pour un scan est consignée dans le journal d’audit avec le nom du demandeur.

Dans VamiAppSec, de trois façons : comme étape fixe de votre pipeline CI/CD (GitLab, GitHub, Azure DevOps) — chaque build déployé en préproduction est scanné, et les constats confirmés au-delà d’un seuil de gravité peuvent bloquer la gate ; à la demande via CLI contre toute cible autorisée, avec les mêmes modes et protections ; et en continu ou de manière planifiée contre les systèmes de production — uniquement en mode Passif ou Sûr et uniquement avec autorisation. VAMIDAST s’utilise de manière indépendante avec son propre tableau de bord, son API REST et ses rapports (PDF, SARIF 2.1.0, CSV), ou entièrement intégré à VamiAppSec, où les constats rejoignent le même backlog que SAST, SCA, SBOM et secrets.

Oui. Il existe pour VAMIDAST un contrat de traitement des données (DPA) propre au produit, conformément à l’art. 28 du RGPD, disponible sur demande auprès de privacy@vamisec.com. Les délais de suppression et de conservation de vos données sont définis et régis par le DPA. Les données au repos sont chiffrées et les transferts passent par TLS.