Question 1

Comment vous réduisez les faux positifs du SAST ?

Accepted Answer

En deux temps. D'abord un pré-pass déterministe écarte tout ce qui n'a pas de source attaquable ou qui passe par un assainissement : ces cas ne partent jamais au modèle et ne consomment aucune validation. Ensuite, sur les candidats qui survivent, un agent LLM relit le code autour du finding avec des outils d'inspection d'AST et tranche l'exploitabilité réelle. Un SAST par motif flagge la ligne ; nous suivons le flux de la donnée et regardons le contexte. Deux lignes identiques peuvent donner deux verdicts différents si l'une est atteignable et l'autre non. Résultat : ce qui atterrit dans votre backlog a survécu à un filtre déterministe puis à une vérification contextuelle, pas juste à une regex.

Question 2

Comment fonctionne le SAST contextuel, concrètement ?

Accepted Answer

Deux étages. D'abord un pré-pass déterministe : tree-sitter repère les sinks sensibles, puis un moteur de taint remonte le flux de la donnée depuis sa source jusqu'au sink, à travers les fonctions et les fichiers du dépôt. Ce qui n'a pas de source attaquable ou passe par un assainissement est rejeté tout de suite, sans consommer de validation. Ne survivent que les chaînes plausibles, qui partent ensuite à la vérification. Chaque finding affiche sa chaîne de taint complète (source, étapes intermédiaires, sink) : vous voyez pourquoi c'est remonté, pas un verdict opaque.

Question 3

Qu'est-ce que le suivi de taint apporte face à un SAST par motif ?

Accepted Answer

Un SAST par motif s'arrête souvent au fichier et à la ligne : il repère une forme de code suspecte sans savoir si l'entrée est vraiment contrôlée par l'attaquant, ni si un assainissement la neutralise plus loin. Le suivi de taint relie la source au sink à travers les fonctions et les fichiers, donc il raisonne sur le flux réel de la donnée. C'est ce qui permet de distinguer une vraie injection d'un cas mort, et de faire chuter le bruit au lieu d'empiler des alertes que personne ne trie.

Question 4

Quels langages sont couverts en profondeur ?

Accepted Answer

On couvre 19 langages avec un moteur de taint (grammaire tree-sitter plus walker de flux), dont 14 en profondeur : sources, sanitizers et règles de sinks sur plusieurs catégories de vulnérabilités. Les plus matures sont Python, JavaScript/TypeScript et Java, suivis de Go, PHP, Ruby et Kotlin, puis C, C++, C#, Rust, Swift, Scala et Bash. Cinq langages (Dart, Lua, Perl, PowerShell, R) sont parsés mais limités à l'injection et au path traversal, sans sanitizers : un support léger, qu'on présente comme tel plutôt que de survendre une couverture uniforme. Si votre stack n'est pas dans la liste, écrivez-nous : on cadre le périmètre avant d'engager quoi que ce soit.

Question 5

Est-ce que l'agent IA exécute mon application ?

Accepted Answer

Non. C'est de l'analyse statique : SecAI lit votre code, il ne le lance pas. L'agent LangGraph relit les findings de code avec des outils d'inspection d'AST pour écarter les faux positifs, mais il ne fait pas de DAST, n'exécute pas votre application et ne rejoue pas un pentest sur une cible vivante. Aucun runtime, donc aucun risque pour votre production. La couverture entre deux audits humains vient de l'analyse statique continue, déclenchée à chaque commit ou pull request et via des scans planifiés en cron.

Question 6

En quoi c'est différent de Snyk, Semgrep, CodeQL ou Checkmarx ?

Accepted Answer

Les SAST classiques par motif s'arrêtent souvent au fichier et noient l'équipe sous le bruit. Ici, le suivi de taint multi-fichiers remonte le flux réel de la donnée, et un vérificateur IA tranche l'exploitabilité pour tuer une partie des faux positifs avant qu'ils n'atterrissent dans votre backlog. On est moins exhaustif que les historiques sur les langages exotiques ; notre parti pris est ailleurs : le triage, l'exploitabilité et une remédiation lisible. Et surtout, ce SAST s'inscrit dans une logique de pentester : il prolonge la couverture, l'humain garde la décision finale.

Question 7

Puis-je éditer et exporter les rapports ?

Accepted Answer

Oui. Chaque scan produit un rapport HTML éditable (vous ajustez, commentez, retirez ce qui ne vous concerne pas) et un export SARIF (serveur et CLI) qui s'intègre directement dans GitHub Code Scanning. Les résultats sont aussi poussés là où votre équipe travaille : commentaires de PR/MR, Slack, webhook, email. En cas d'arrêt, vous exportez vos rapports et vos données sont supprimables sur demande via les routes de purge RGPD.

Question 8

Ce SAST remplace-t-il mon pentest humain ?

Accepted Answer

Non, et ce n'est pas le but. L'analyse statique assure la couverture en continu entre deux missions, là où votre code bouge à chaque déploiement. La vérification humaine reste notre offre de pentest, séparée, menée par un pentester certifié OSWE. Le rapport le rappelle d'ailleurs explicitement : les findings doivent être revus par un professionnel. Le SAST et le pentest own2pwn se complètent, ils ne se substituent pas.

AI-Native SAST

Tout ce qu'il faut pour sécuriser, sans le superflu.

SAST contextuel à suivi de taint

Vérification par agent, moins de faux positifs

Priorisation par exploitabilité réelle

Explication et remédiation lisibles

Branché sur GitHub, SARIF natif

Rapports éditables, en continu

Du setup à la première alerte.

1. Vous connectez votre dépôt

2. Le taint suit vos flux de données

3. L'agent tranche l'exploitabilité

4. Rapport, remédiation et CI/CD

L'impact concret pour vos équipes.

Un SAST qui ne noie plus les devs

Le contexte décide, pas le pattern

Du finding au correctif, sans changer d'outil

Ce qu'on fait différemment.

L'IA pour trier, pas pour bavarder

Priorisé par ce qu'un attaquant atteint

Conçu par un pentester OSWE

Hébergé dans l’Union européenne

Des tarifs lisibles, sans surprise.

Ce que vous voulez probablement savoir.

Pour aller plus loin

SAST, DAST, IAST : le comparatif

SAST et DAST dans la CI/CD

Vibe coding et sécurité

Parlons de votre besoin.