Analyser du code inconnu, c'est exécuter des outils sur des données conçues par quelqu'un d'autre. La question n'est pas de savoir si un dépôt tentera quelque chose, mais ce qui se passe quand il le fera. Voici les réponses, mécanisme par mécanisme.
Chaque moteur s'exécute dans son propre conteneur gVisor, détruit à la fin du scan. gVisor intercale un noyau applicatif entre le processus et l'hôte : les appels système ne touchent pas le noyau de la machine. Le conteneur tourne sans réseau, en lecture seule, sans aucune capacité Linux, sous un utilisateur non privilégié.
Nous partons du principe que l'exécution de code arbitraire est possible dans chaque sandbox, y compris via un moteur. C'est pourquoi l'isolation ne dépend pas de la confiance dans l'outil : mêmes contraintes pour tous, images épinglées par empreinte et non par étiquette mouvante, et le worker ne parle jamais au socket Docker de l'hôte — il passe par un proxy qui n'autorise que la création de conteneurs.
Les scanners statiques n'ont pas de réseau du tout. Les rares étapes qui en ont besoin sortent par un proxy qui bloque 169.254.169.254, l'ensemble des plages privées et la boucle locale, et journalise le reste. Même un modèle de détection malveillant ne peut pas atteindre ce qu'il vise.
Le contenu de votre dépôt est transmis au modèle encadré comme donnée non fiable, jamais comme instruction. Les modèles d'analyse n'ont accès à aucun outil à effet de bord ni au réseau. La sortie est contrainte par un schéma, et un identifiant CVE qui n'apparaît pas dans la sortie brute du scanner est rejeté à la validation.
Le filtrage applicatif par organisation est doublé d'une politique PostgreSQL au niveau ligne, en refus par défaut. Un WHERE oublié dans une requête ne rend rien plutôt que de rendre les données du voisin.
La propriété du domaine se prouve par un enregistrement DNS, et la vérification est imposée par le modèle de données, pas par l'interface. Au démarrage du scan les adresses IP sont ré-résolues puis épinglées, ce qui ferme la fenêtre de réattribution DNS. Sans preuve valide, la cible est physiquement inatteignable depuis nos sorties réseau.
Le clone vit dans un répertoire éphémère détruit à la fin du run. Seuls les findings, les rapports et les journaux d'exécution sont conservés.
gVisor intercale un noyau applicatif entre le scanner et l'hôte. Un moteur compromis ne voit pas le noyau de la machine.
PostgreSQL applique une politique de sécurité au niveau ligne, refus par défaut. Un filtre oublié dans le code ne peut pas faire fuiter une autre organisation.
Les scanners tournent sans réseau. Les rares étapes qui en ont besoin passent par un proxy qui bloque les adresses privées et les métadonnées cloud.
Chaque moteur est épinglé sur un digest, jamais sur un tag mouvant. La version qui a produit votre relevé est celle qui est inscrite dedans.
Le contenu du dépôt est encadré comme donnée non fiable, la sortie du modèle est contrainte par un schéma, et aucun outil à effet de bord ne lui est accessible.
Le détail des durées de conservation, des sous-traitants et de vos droits figure dans la politique de confidentialité. Pour un usage en entreprise, l'accord de sous-traitance décrit les engagements au titre de l'article 28 du RGPD.
Nous ne sommes certifiés ni ISO 27001 ni SOC 2. Le jour où nous le serons, le rapport d'audit sera lié depuis cette page.
Aucun outil ne trouve tout. L'absence de finding n'est pas une preuve d'absence de faille, et aucun rapport auditer ne le prétendra.
La couverture CVE dépend de la fraîcheur des bases de vulnérabilités. La date et la provenance de la base utilisée sont inscrites dans chaque relevé.
L'analyse automatique ne remplace pas un audit humain sur une application critique. Elle réduit la surface que l'humain doit couvrir.
Accusé de réception sous 72 heures. Aucune poursuite contre un signalement de bonne foi, sans exfiltration de données ni dégradation du service.