Aller au contenu principal
own2pwn

AI-Native AppSec

AI-Native SCA

Analyse de composition logicielle, filtrée par l'atteignabilité réelle : la fonction vulnérable est-elle appelée.

Un scan de dépendances classique vous rend 500 CVE et vous laisse trier. SecAI fait l'inverse : il dresse l'inventaire complet de vos dépendances (SBOM) sur huit écosystèmes, croise chaque paquet avec les advisories d'OSV.dev, puis coupe le bruit avant de remonter quoi que ce soit. Une passe d'atteignabilité vérifie si la fonction vulnérable de l'advisory est vraiment référencée dans votre code : absente de l'index de symboles du SAST, la CVE part en NOT_CALLED sans même consulter l'IA ; présente, un modèle juge si une référence est sur un vrai chemin d'exécution. Ce qui reste est priorisé par exploitabilité réelle, avec le risque de licences, et corrélé au SAST à suivi de taint (la donnée non fiable pistée de son entrée jusqu'à son usage), à l'IaC et aux secrets dans un seul scan. Conçu par un pentester certifié OSWE, hébergé dans l'UE. Facette de la plateforme SecAI : 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
On ne remonte que les CVE de dépendances réellement atteignables depuis votre code
Reachability
PyPI, npm, Go, Maven, RubyGems, PHP, Rust, NuGet, transitives comprises
SBOM, 8 écosystèmes
RGPD, droit européen, zéro entraînement sur votre code
Hébergé dans l'UE

Fonctionnalités

Ce que l'analyse de composition regarde dans vos dépendances.

Inventaire complet des dépendances (SBOM)

SecAI découvre vos lock files sur huit écosystèmes (PyPI, npm, Go, Maven, RubyGems, Packagist/PHP, crates/Rust, NuGet) et reconstruit l'arbre réel de vos dépendances, directes et transitives. Vous obtenez un SBOM exploitable avec la provenance de chaque paquet : quelle version résolue, tirée par quoi, sur quelle chaîne (A vers B vers X). La faille est le plus souvent trois niveaux plus bas que ce que vous croyez, dans un paquet que vous n'avez jamais installé à la main.

Advisories OSV.dev croisés en continu

Chaque paquet et chaque version résolue sont confrontés aux advisories publiés sur OSV.dev (Open Source Vulnerabilities). Le croisement tourne à chaque push, chaque pull request et sur planning cron, donc une vulnérabilité divulguée hier remonte sur votre code d'aujourd'hui sans que vous relanciez quoi que ce soit. Chaque finding de base pointe le paquet, la version affectée et la version qui corrige, en confiance basse tant que l'atteignabilité n'a pas tranché.

Filtrage par atteignabilité, en deux temps

Le cœur du produit. D'abord une porte déterministe : SecAI regarde si les fonctions vulnérables listées par l'advisory sont référencées dans votre dépôt, via l'index de symboles produit par le SAST. Absentes de l'index, la CVE part en NOT_CALLED et sort sans consommer d'IA. Présentes, ou sans index disponible, elle devient candidate : une recherche textuelle des symboles vulnérables (plafonnée à vingt occurrences) alimente un modèle qui juge si une référence est sur un vrai chemin d'exécution, de l'entrypoint jusqu'à la fonction fautive. La confiance est réévaluée, le site d'invocation gardé comme preuve. Atteignabilité mappée pour sept langages.

Tarifs de l'analyse de composition logicielle.

Starter

0 €

  • Module SCA 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. SecAI lit vos manifestes et vos lock files, pas de fork ni de commit poussé dans votre code sans votre action. Chiffrement au repos, suppression des données sur demande.

  2. 02

    2. SecAI construit le SBOM et croise OSV.dev

    Découverte des lock files sur huit écosystèmes, résolution de l'arbre complet, directes et transitives, avec les versions réellement installées et leur provenance. Chaque paquet et chaque version sont confrontés aux advisories d'OSV.dev. À ce stade vous avez déjà l'inventaire, les licences et la liste brute des vulnérabilités connues en confiance basse, avec la version qui corrige.

  3. 03

    3. La passe d'atteignabilité coupe le bruit

    Deux temps. Porte déterministe d'abord : si les fonctions vulnérables de l'advisory ne sont pas dans l'index de symboles produit par le SAST, la CVE est classée NOT_CALLED sans appel au modèle. Sinon, une recherche textuelle des symboles (plafonnée à vingt occurrences) alimente un modèle qui juge le chemin d'exécution. Sans run SAST, donc sans index, les candidats partent directement au modèle : l'atteignabilité reste calculée, au prix d'un coût IA plus élevé. Un agent relie ensuite ce qui est atteignable au SAST, à l'IaC et aux secrets en chemins d'attaque.

  4. 04

    4. Rapport, SARIF et CI/CD

    Rapport HTML, 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 tri par atteignabilité change dans votre backlog.

01

Arrêter de noyer les devs sous 500 CVE

Un scan de dépendances brut remonte tout ce qui est déclaré vulnérable, atteignable ou non, et l'équipe finit par tout ignorer par lassitude. SecAI inverse le tri : le SBOM sert de base, le croisement OSV.dev identifie les candidats, puis la passe d'atteignabilité écarte d'abord en déterministe celles dont aucune fonction vulnérable n'apparaît dans votre index de symboles, avant de faire trancher l'IA sur ce qui reste. Ce qui remonte est court et défendable, avec le site d'invocation comme preuve. Vos développeurs arrêtent de fermer des tickets en won't fix et corrigent ce qui compte vraiment.

02

Le risque des dépendances suivi en continu, pas à date

Une CVE peut tomber n'importe quel jour sur un paquet que vous n'avez pas touché depuis des mois. Un audit humain, c'est une photo à une date ; entre deux missions, votre arbre de dépendances bouge à chaque mise à jour et le paysage des vulnérabilités change tout seul. SecAI recroise votre SBOM avec OSV.dev à chaque commit et sur planning cron, donc une divulgation d'hier remonte sur votre code d'aujourd'hui. La vérification offensive reste le métier du pentester certifié OSWE qui signe les missions, en offre séparée : le SCA bouche le trou entre deux audits.

03

Une seule vue : dépendances, code, infra, secrets

Le risque des dépendances ne vit pas isolé du reste. SecAI corrèle le SCA filtré par atteignabilité avec le SAST contextuel, les misconfigs IaC et les secrets, dans le même scan et le même rapport. Vous voyez la CVE atteignable au bout d'un chemin d'attaque, pas dans un onglet séparé qu'on lit une fois par trimestre. Rapport HTML, export SARIF natif (le format standard des résultats d'analyse), 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.

Détail d'un finding SCA listant les dépendances vulnérables d'un projet, issues du lockfileLe détail d'un finding SCA : les dépendances vulnérables du projet, telles que lues dans le lockfile. La version installée, pas celle du package.json.
Liste des findings incluant les vulnérabilités de dépendances détectées par le SCALes findings, vulnérabilités de dépendances comprises, triés au milieu du reste. On voit ce qui vient d'une lib et ce qui vient de votre code.
Historique des scans (SCA, IAC, SAST) avec la consommation de créditsL'historique des scans SCA, IAC et SAST, avec les crédits consommés. Vous suivez la dépense au passage.

Pourquoi own2pwn

Pourquoi une CVE présente n'est pas une CVE atteignable.

La reachability plutôt que la liste brute

La plupart des outils de SCA remontent toute CVE présente dans l'arbre, atteignable ou non, et laissent l'équipe trier au CVSS. SecAI part de la référence réelle : la dépendance vulnérable compte si ses fonctions fautives apparaissent dans votre code et sur un chemin d'exécution plausible, sinon elle sort du haut de pile dès la porte déterministe. C'est ce filtre en deux temps qui fait la différence entre 500 lignes ignorées et une liste courte qu'on corrige.

Conçu par un pentester OSWE

Le SCA de SecAI ne sort pas d'une équipe data. La logique de priorisation vient de l'exploitation réelle : une dépendance vulnérable ne vaut que si un attaquant peut l'atteindre et l'enchaîner. La certification OSWE porte précisément sur l'exploitation de vulnérabilités applicatives en boîte blanche, exactement là où se joue l'atteignabilité entre votre code et vos dépendances.

L'IA pour trier et corréler, pas pour bavarder

La découverte des lock files, la résolution du SBOM et le croisement OSV.dev sont déterministes, et la porte d'atteignabilité écarte sans IA tout ce que l'index de symboles du SAST ne référence pas. Le modèle n'intervient que sur les références ambiguës, pour juger si elles sont sur un vrai chemin d'exécution, et pour relier la dépendance au reste (code, IaC, secrets). Pas de chatbot, pas de verdict opaque : chaque CVE remontée montre le site d'invocation qui la rend atteignable.

Complémentaire de vos pentests, pas un remplaçant

Le SCA couvre le risque des dépendances en continu, à chaque commit et sur planning cron, pendant que votre arbre de paquets bouge. La validation humaine reste l'affaire de nos pentests, une offre séparée signée par un pentester. Chaque rapport recommande d'ailleurs une revue par un professionnel. On ne vend pas une IA qui remplace l'humain, on vend la continuité entre ses passages.

Questions fréquentes

Vos questions sur l'analyse de composition logicielle.

Qu'est-ce que le SCA, et en quoi celui de SecAI est différent ?

Le SCA (software composition analysis, ou analyse de composition logicielle) inventorie les dépendances open source de votre application et repère celles qui portent des vulnérabilités connues. La plupart des outils s'arrêtent là et vous rendent la liste complète, souvent des centaines de CVE, atteignables ou non. SecAI ajoute une étape décisive : la passe d'atteignabilité. On vérifie si les fonctions vulnérables de chaque dépendance sont vraiment référencées puis appelées depuis votre code avant de le remonter en priorité. Résultat, une liste courte et défendable au lieu d'une décharge d'alertes.

Comment marche le filtrage par atteignabilité, concrètement ?

Une CVE dans une dépendance désigne des fonctions ou symboles vulnérables précis (les vulnerable_functions de l'advisory). SecAI procède en deux temps. Porte déterministe : ces symboles sont-ils référencés dans votre dépôt ? On le vérifie via l'index de symboles produit par le SAST. Absents, la CVE est classée NOT_CALLED et écartée sans appeler le modèle. Présents, ou pas d'index disponible, elle devient candidate. Ensuite, une recherche textuelle des symboles vulnérables, plafonnée à vingt occurrences, alimente un modèle qui juge si une référence est sur un vrai chemin d'exécution, de l'entrypoint jusqu'à la fonction fautive. La confiance est réévaluée et le site d'invocation gardé comme preuve. Ce n'est pas un graphe d'appels complet ni un suivi de taint inter-procédural sur vos dépendances : c'est un lookup de symboles, une recherche textuelle bornée et un jugement de modèle.

Faut-il lancer le SAST pour que l'atteignabilité fonctionne ?

Ça marche mieux avec. L'atteignabilité s'appuie d'abord sur l'index de symboles que le SAST construit sur votre code : c'est lui qui permet d'écarter en déterministe, sans IA, les CVE dont les fonctions vulnérables n'apparaissent nulle part. Si vous ne lancez pas le SAST, donc sans cet index, SecAI ne devine pas à l'aveugle : tous les candidats partent au modèle pour jugement. L'atteignabilité reste calculée, mais le coût IA grimpe. En pratique, SCA et SAST tournent dans le même scan, l'un alimente l'autre.

Est-ce que le SCA voit aussi les dépendances transitives ?

Oui, c'est même là que se cache l'essentiel du risque. SecAI reconstruit l'arbre complet à partir des lock files des huit écosystèmes supportés : dépendances directes que vous avez déclarées, et transitives tirées par elles, sur toute la profondeur. Le SBOM indique quel paquet, quelle version résolue, importé par quoi et par quelle chaîne (A vers B vers X). Une faille est très souvent trois niveaux plus bas que ce que vous croyez, dans un paquet que vous n'avez jamais installé à la main. La passe d'atteignabilité s'applique aussi aux transitives.

Le SCA gère-t-il les licences et le risque supply-chain ?

Oui, en passe best-effort par-dessus le SBOM. Le même inventaire remonte la licence de chaque dépendance, transitive comprise : une copyleft qui s'invite sous une lib permissive, une dépendance sans texte de licence clair, un changement de licence entre deux versions. Il repère aussi des signaux de supply-chain, typosquats et paquets malveillants. C'est le genre de détail qu'on préfère voir avant un audit ou une due diligence, pas après, et il vit dans le même endroit que les CVE.

En quoi c'est différent de Snyk, Dependabot ou l'OWASP Dependency-Check ?

Ces outils font surtout du croisement de versions : ils comparent votre arbre de dépendances à une base de CVE et remontent tout ce qui correspond, atteignable ou non. C'est utile, mais ça noie souvent l'équipe. SecAI garde ce croisement (OSV.dev) comme base, puis ajoute la passe d'atteignabilité en deux temps pour ne prioriser que les vulnérabilités réellement référencées et appelées depuis votre code, et corrèle le SCA avec le SAST, l'IaC et les secrets dans un seul scan. Notre parti pris est le tri par exploitabilité réelle et la corrélation en chemins d'attaque, dans une logique de pentester où l'humain garde la décision finale.

Le SCA remplace-t-il un pentest humain ?

Non, et ce n'est pas le but. Le SCA assure la couverture continue du risque des dépendances entre deux missions, là où votre arbre de paquets et le paysage des CVE bougent tout seuls. La vérification humaine reste notre offre de pentest, séparée, menée par un pentester certifié OSWE. Le rapport SecAI le rappelle explicitement : les findings doivent être revus par un professionnel. Le SCA et le pentest own2pwn se complètent, ils ne se substituent pas.

Mon code source sort-il de l'UE, et sert-il à entraîner un modèle ?

Le stockage reste dans l'UE (Allemagne), chiffré au repos, avec purge RGPD implémentée. Pour l'analyse, le code est envoyé aux modèles Claude d'Anthropic servis via Google Cloud Vertex AI : Google est un prestataire dont la maison mère est américaine, encadré par des clauses contractuelles types (RGPD). Ni Google ni Anthropic n'utilisent vos données pour entraîner leurs modèles (data governance de Vertex AI). L'accès à votre dépôt est en lecture seule, limité au périmètre que vous définissez.

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 SCA 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 : SCA 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.

Le SCA est-il isolé, ou relié au reste du scan ?

Le SCA n'est pas un silo. Dans un seul scan, SecAI relie la dépendance vulnérable atteignable au flux de données de votre code (SAST à suivi de taint), aux misconfigurations d'infrastructure et aux secrets exposés, puis reconstruit des chemins d'attaque. Une CVE atteignable qui débouche sur un sink sensible (le point où la donnée est réellement utilisée) ou un secret leaké se lit comme un chemin complet, pas comme une entrée de liste.

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 →

OWASP Top 10 expliqué

Les dix familles de failles web les plus courantes, et comment les traiter.

Lire →

Vibe coding et sécurité

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

Lire →

Savoir quelles CVE vous concernent vraiment ?

Produit en pré-lancement : demandez un accès anticipé. Pour faire auditer vos dépendances à la main, la réponse arrive sous 24 h.

Réserver une démoNous écrire