Aller au contenu principal
own2pwn
Retour à la plateforme AI-Native AppSec

AI-Native SAST

Le SAST qui comprend le flux de la donnée, pas juste des patterns.

L'analyse statique classique remonte des motifs et vous noie sous les faux positifs. Notre SAST fait autre chose : un moteur déterministe trace le flux de la donnée de la source jusqu'au sink, puis un agent LLM relit le code pour trancher l'exploitabilité et écraser les faux positifs avant qu'ils n'atterrissent dans votre backlog. Chaque finding arrive avec sa chaîne de taint, son explication et une remédiation lisible, dans un rapport éditable. C'est le cœur de la plateforme SecAI, conçu par un pentester certifié OSWE et hébergé dans l’UE. Produit en pré-lancement : on ne décrit ici que ce qui tourne déjà.

Commencer gratuitementParler à un pentester
Source vers sink
Suivi de taint multi-fichiers, pas un motif sur une ligne
Triage par agent IA
Les faux positifs sont écartés avant votre backlog
14 langages en profondeur
Sources, sanitizers et sinks, plus 5 en support léger

Fonctionnalités

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

SAST contextuel à suivi de taint

On remonte le flux de la donnée de la source jusqu'au sink sensible, à travers les fonctions et les fichiers, pas juste un motif sur une ligne. Chaque finding affiche sa chaîne source vers sanitizer vers sink, pour voir pourquoi c'est flaggé. Profondeur réelle sur 14 langages : Python, JS/TS et Java en tête, puis Go, PHP, Ruby, Kotlin, C, C++, C#, Rust, Swift, Scala et Bash.

Vérification par agent, moins de faux positifs

Un pré-pass déterministe (tree-sitter + taint) écarte les cas sans source ou déjà assainis avant tout appel au modèle. Par-dessus, un agent LangGraph relit le code via des outils d'analyse AST pour confirmer ou écarter ce qui reste. Vous triez ce qui compte, pas une décharge d'alertes.

Priorisation par exploitabilité réelle

L'agent tranche l'exploitabilité au lieu de recracher un score CVSS isolé. Un finding atteignable et chaînable remonte en tête, un cas mort ou déjà couvert par un assainissement passe au fond. Vous corrigez ce qu'un attaquant atteint vraiment, pas une liste triée par sévérité théorique.

Comment ça marche

Du setup à la première alerte.

  1. 01

    1. Vous connectez votre dépôt

    GitHub via la GitHub App, GitLab via OAuth ou jeton. Accès en lecture seule, scope limité aux dépôts que vous cochez. Pas de fork, pas de commit poussé dans votre code sans votre action. Suppression des données sur demande, chiffrement au repos.

  2. 02

    2. Le taint suit vos flux de données

    Tree-sitter repère les sinks sensibles, le moteur de taint remonte la chaîne source vers sink, à l'intérieur d'un fichier puis entre fichiers et modules. Le pré-pass déterministe écarte les cas non atteignables ou déjà assainis avant d'appeler le LLM. Chaque finding affiche sa chaîne de taint complète : vous voyez pourquoi c'est flaggé, pas un verdict opaque.

  3. 03

    3. L'agent tranche l'exploitabilité

    Un agent LangGraph relit le code autour de chaque candidat avec des outils d'inspection d'AST, confirme les vrais cas, tue les faux positifs et classe ce qui reste par exploitabilité réelle. Le scan tourne à chaque push ou pull request et sur planning cron, donc la couverture statique ne s'arrête pas entre deux pentests.

  4. 04

    4. Rapport, remédiation et CI/CD

    Rapport HTML éditable avec explication et remédiation, export SARIF natif pour GitHub Code Scanning, commentaires de PR ou MR, alertes Slack, webhook ou email. La GitHub Action pose un gate de sévérité configurable dans votre pipeline. GitLab, Jenkins et runners self-hosted passent par la CLI secai. La vérification humaine finale reste l'affaire de nos pentests OSWE, une offre séparée.

Bénéfices

L'impact concret pour vos équipes.

01

Un SAST qui ne noie plus les devs

Le pré-pass tourne d'abord en déterministe : tree-sitter repère les sinks, le moteur de taint remonte la chaîne source vers sanitizer vers sink. Tout ce qui n'a pas de source attaquable ou qui est déjà assaini est écarté avant le moindre appel au modèle. Seuls les cas qui survivent passent au vérificateur LLM, qui les triage pour couper les faux positifs. Vos développeurs voient la chaîne de données complète dans l'interface, pas un verdict opaque, et arrêtent de fermer des tickets en won't fix.

02

Le contexte décide, pas le pattern

Un SAST par motif ne sait pas si l'entrée est réellement contrôlée par l'attaquant ni si un assainissement la neutralise en chemin : il flagge, vous triez à la main. Ici, l'agent lit le code autour du finding, suit la donnée et tranche l'exploitabilité. Deux lignes identiques donnent deux verdicts différents si le contexte diffère. C'est ça qui fait chuter le bruit : la décision porte sur le flux réel, pas sur une regex.

03

Du finding au correctif, sans changer d'outil

Chaque finding est prêt à traiter : chaîne de taint visible, explication en clair, remédiation proposée. Quand le correctif est applicable, SecAI ouvre directement une PR ou une MR, sinon dépose un patch. Rapport HTML éditable, export SARIF compatible GitHub Code Scanning, notifications Slack, webhook ou email : tout sort du même endroit, sans empiler trois outils qui ne se parlent pas.

Aperçu

La plateforme en images.

Liste des findings SAST, IAC, secrets et SCA sur des dépôts réels, avec sévérités et badge Verified by pattern + agent
Liste des findings SAST, IAC, secrets et SCA sur des dépôts réels, avec sévérités et badge Verified by pattern + agentLes findings SAST, IAC, secrets et SCA sur de vrais dépôts, triés par sévérité. Le badge Verified by pattern + agent marque ceux qu'un agent a recroisés.
Détail d'un finding SAST critique (CWE, CVSS élevé) avec triage, Evidence, Summary et Root cause
Détail d'un finding SAST critique (CWE, CVSS élevé) avec triage, Evidence, Summary et Root causeUn finding critique en détail : CWE, CVSS, Evidence, résumé et cause racine. De quoi corriger sans rouvrir le code à l'aveugle.
Analyse de taint source vers sink (SOURCE req.body vers SINK eval) avec verdict candidat exploitable et vecteur CVSS
Analyse de taint source vers sink (SOURCE req.body vers SINK eval) avec verdict candidat exploitable et vecteur CVSSLe suivi de taint de la SOURCE req.body jusqu'au SINK eval, verdict candidat exploitable, vecteur CVSS détaillé. Le chemin de la donnée, pas juste une ligne surlignée.
Dépôts connectés avec le nombre de findings ouverts et de scans par dépôt
Dépôts connectés avec le nombre de findings ouverts et de scans par dépôtLes dépôts connectés, avec leurs findings ouverts et leurs scans. On voit tout de suite lequel traîne le plus de dette.

Pourquoi own2pwn

Ce qu'on fait différemment.

L'IA pour trier, pas pour bavarder

Le pré-pass est déterministe : tree-sitter repère les sinks, le moteur de taint remonte le flux de la donnée jusqu'à sa destination. Ce passage ne consomme aucune validation et écarte les cas sans source ou déjà assainis avant tout appel au modèle. Seuls les candidats qui survivent partent au vérificateur LLM, qui tue les faux positifs. Pas de chatbot, pas de verdict opaque : chaque finding affiche sa chaîne de taint, donc la raison du flag.

Priorisé par ce qu'un attaquant atteint

Un SAST utile ne rend pas une liste triée par sévérité théorique. L'agent tranche l'exploitabilité à partir du code : ce qui est atteignable, ce qui est chaînable, ce qui se neutralise en chemin. La hiérarchie part de là, pas d'un CVSS isolé. Vous passez moins de temps à trier et plus à corriger ce qui compte vraiment.

Conçu par un pentester OSWE

Ce SAST ne sort pas d'une équipe data. La logique de détection et de priorisation vient de l'exploitation réelle : ce qu'un attaquant atteint vraiment, ce qui mérite un correctif, ce qui se déduit du code seul. La certification OSWE porte précisément sur l'exploitation de vulnérabilités applicatives en boîte blanche, là où se joue le SAST.

Hébergé dans l’Union européenne

Votre code est stocké dans l’UE (Allemagne), chiffré au repos, avec purge RGPD sur demande. Pour l'analyse, il est envoyé aux modèles Claude d'Anthropic servis via Google Cloud Vertex AI en région européenne : ni Google ni Anthropic n'utilisent vos données pour entraîner leurs modèles. Un RSSI garde une chaîne de traitement claire à documenter, sans revue juridique de trois semaines.

Des tarifs lisibles, sans surprise.

Starter
0 €
  • 2 dépôts
  • Pré-pass déterministe illimité (SAST, SCA, IaC, secrets)
  • 20 validations IA / mois, jusqu'à 10 scans par jour
  • Scans sur push/PR et planifiés par cron
  • Rapport HTML et export SARIF
  • Support communautaire
Commencer gratuitement
Recommandé
Pro
99 € / mois
  • Dépôts illimités
  • 250 validations IA / mois, jusqu'à 200 scans par jour
  • Vérification par agent LLM et corrélation en chemins d'attaque
  • GitHub App, Action SARIF, gate de sévérité et auto-fix PR/MR
  • Notifications Slack, webhook et email
  • Validation supplémentaire à 0,30 € (pay-as-you-go), jusqu'à 5 utilisateurs
  • TVA non applicable, art. 293 B du CGI
S'abonner
Team
299 € / mois
  • Dépôts illimités
  • 750 validations IA / mois
  • SSO / SAML et RBAC
  • File d'analyse prioritaire
  • Validation supplémentaire à 0,30 € (pay-as-you-go)
  • Jusqu'à 15 utilisateurs
  • TVA non applicable, art. 293 B du CGI
S'abonner
Enterprise
Sur devis
  • Volume de validations négocié
  • SSO / SAML / SCIM, audit logs
  • Runner auto-hébergé, déploiement dédié
  • DPA conforme RGPD, exports et preuves exploitables dans un audit ISO 27001 ou SOC 2
  • Couplage avec les pentests et l'EASM own2pwn
Parler à un expert

Questions fréquentes

Ce que vous voulez probablement savoir.

Comment vous réduisez les faux positifs du SAST ?

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.

Comment fonctionne le SAST contextuel, concrètement ?

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.

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

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.

Quels langages sont couverts en profondeur ?

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.

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

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.

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

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.

Puis-je éditer et exporter les rapports ?

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.

Ce SAST remplace-t-il mon pentest humain ?

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.

Pour aller plus loin

SAST, DAST, IAST : le comparatif

Trois manières de chasser les failles applicatives, et ce que l'IA change.

Lire →

SAST et DAST dans la CI/CD

Le guide DevSecOps pour brancher l'analyse sur le pipeline.

Lire →

Vibe coding et sécurité

Coder au feeling avec l'IA : les angles morts de sécurité que ça introduit.

Lire →

Parlons de votre besoin.

Démo, devis ou question technique : réponse sous 48 h ouvrées.

Demander une démoNous écrire