Aller au contenu principal
own2pwn

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 (l'endroit où elle finit par être utilisée : requête SQL, appel système, rendu HTML), 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 (le trajet complet de la donnée non fiable), 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. Inscription en libre-service, plan gratuit sans carte bancaire.

Commencer gratuitementParler à un pentester
Lecture seule, hébergé dans l'UE, votre code n'entraîne aucun modèle
Suivi de taint multi-fichiers, pas un motif sur une ligne
Source vers sink
Les faux positifs sont écartés avant votre backlog
Triage par agent IA
Sources, sanitizers et sinks, plus 5 en support léger
14 langages en profondeur

Fonctionnalités

Ce que l'analyse statique suit dans votre code.

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 (une première passe sans IA, à règles fixes, qui rend toujours le même verdict) é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.

Tarifs de l'analyse statique IA-native.

Starter

0 €

  • Module SAST inclus dans l'offre SecAI
  • En clair : 2 dépôts Git suivis, 20 vérifications IA par mois, 1 personne.
  • Pré-pass déterministe illimité (SAST, SCA, IaC, secrets)
  • Jusqu'à 10 scans par jour
  • Scans sur push/PR et planifiés par cron
  • Rapport HTML et export SARIF
  • Gratuit, sans limite de durée et sans carte bancaire
Commencer gratuitement
Recommandé

Pro

99 € / mois

  • En clair : dépôts illimités pour une équipe de 5 personnes, 250 vérifications IA par 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)
S'abonner

Réservé aux professionnels, identifiant d'entreprise demandé à l'étape suivante.

Team

299 € / mois

  • En clair : dépôts illimités pour une équipe de 15 personnes, 750 vérifications IA par mois.
  • SSO / SAML et RBAC
  • File d'analyse prioritaire
  • Validation supplémentaire à 0,30 € (pay-as-you-go)
S'abonner

Réservé aux professionnels, identifiant d'entreprise demandé à l'étape suivante.

Enterprise

Sur devis

  • En clair : le volume de vérifications et le mode de déploiement que vous cadrez au contrat.
  • 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

TVA non applicable, art. 293 B du CGI

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

Ce que le chemin de la donnée change pour vos développeurs.

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 + 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 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 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ô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

Pourquoi on suit le flux plutôt qu'un motif.

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.

Questions fréquentes

Vos questions sur l'analyse statique IA-native.

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.

Y a-t-il un engagement de durée, et comment je résilie ?

Aucune durée minimale d'engagement. L'abonnement est mensuel ou annuel (l'annuel revient à dix mois payés), reconduit tacitement à chaque échéance, et vous le résiliez à tout moment, sans justification à fournir : soit vous le faites vous-même depuis votre espace de facturation, soit vous écrivez à contact@own2pwn.fr et la réponse tombe sous 24 heures. Pas de préavis à respecter : la résiliation prend effet à la fin de la période de facturation en cours, et vous gardez l'accès jusque-là. En contrepartie, cette période n'est pas remboursée au prorata. Ce n'est pas une promesse commerciale, c'est l'article 7 des conditions générales de vente.

Faut-il une carte bancaire pour le plan gratuit ?

Non. Le plan Starter s'ouvre depuis le formulaire d'inscription, sans moyen de paiement : aucune carte à saisir, aucun compteur qui se déclenche au bout de quatorze jours. Ce n'est pas une période d'essai mais un plan gratuit sans limite de durée, avec ses quotas propres (2 dépôts, 20 vérifications IA par mois, 10 scans par jour). Le module SAST y est compris, pas vendu à part. La carte bancaire n'apparaît que si vous passez sur un plan payant, et le paiement se fait sur own2pwn.fr, par carte uniquement.

Combien de temps entre le paiement et l'accès effectif ?

L'accès est ouvert immédiatement après la validation du paiement. Concrètement : dès que le règlement est confirmé, l'abonnement est rattaché à votre compte et les quotas du plan s'appliquent, sans intervention manuelle. Si vous souscrivez sans avoir encore de compte own2pwn, le paiement en crée un et vous recevez un email pour définir votre mot de passe : l'accès est effectif dès que c'est fait. Si quelque chose coince, écrivez à contact@own2pwn.fr, la réponse tombe sous 24 heures.

Je peux changer de plan en cours d'abonnement ?

Oui, et sans repartir de zéro : le compte, les dépôts connectés et l'historique de scans restent en place, seuls les quotas changent. Les modules ne se facturent jamais séparément : SAST est compris dans l'abonnement SecAI, donc un changement de plan déplace les quotas de tous les modules d'un coup. Le changement se demande par un email à contact@own2pwn.fr, en indiquant le plan visé et la date d'effet souhaitée ; la réponse tombe sous 24 heures. Ce qui est acquis côté facturation, c'est que la période déjà réglée n'est pas remboursée au prorata (article 7 des conditions générales de vente) ; le montant exact et la date d'effet du nouveau plan vous sont confirmés par écrit avant toute validation.

Qu'est-ce qu'un développeur voit exactement sur un finding ?

Chaque finding vient avec sa chaîne de taint, une explication en clair de la faille et une remédiation concrète. Sur les cas applicables, SecAI peut ouvrir une PR (GitHub) ou une MR (GitLab) qui applique le correctif en place, ou déposer un patch .secai/fixes/. Le fix passe par votre revue habituelle avant merge, rien n'est appliqué dans votre dos.

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 →

Brancher un dépôt en lecture seule ?

Produit en pré-lancement : demandez un accès anticipé. Pour un audit de code conduit à la main, la réponse arrive sous 24 h.

Réserver une démoNous écrire