Skip to main content
own2pwn
Back to the AI-Native AppSec platform

AI-Native SCA

Software composition analysis, filtered by real reachability.

A classic dependency scan hands you 500 CVEs and leaves you to sort them out. SecAI does the opposite: it builds the full inventory of your dependencies (SBOM) across eight ecosystems, cross-references each package against OSV.dev advisories, then cuts the noise before surfacing anything. A reachability pass checks whether the advisory's vulnerable function is actually referenced in your code: absent from the SAST symbol index, the CVE goes NOT_CALLED without even consulting the AI; present, a model judges whether a reference sits on a real execution path. What remains is prioritised by real exploitability, along with license risk, and correlated with the taint-based SAST, IaC and secrets in a single scan. Built by an OSWE-certified pentester, hosted in the EU. A facet of the SecAI platform, in pre-launch: we only describe what already runs today.

Start for freeTalk to a pentester
Reachability
We only surface dependency CVEs actually reachable from your code
SBOM, 8 ecosystems
PyPI, npm, Go, Maven, RubyGems, PHP, Rust, NuGet, transitive deps included
Hosted in the EU
GDPR, European law, zero training on your code

Fonctionnalités

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

Full dependency inventory (SBOM)

SecAI discovers your lock files across eight ecosystems (PyPI, npm, Go, Maven, RubyGems, Packagist/PHP, crates/Rust, NuGet) and rebuilds the real tree of your dependencies, direct and transitive. You get a usable SBOM with each package's provenance: which resolved version, pulled by what, on which chain (A to B to X). The flaw is most often three levels below what you think, in a package you never installed by hand.

OSV.dev advisories cross-referenced continuously

Every package and every resolved version is matched against advisories published on OSV.dev (Open Source Vulnerabilities). The cross-reference runs on every push, every pull request and on a cron schedule, so a vulnerability disclosed yesterday surfaces against today's code without you re-running anything. Every base finding points to the package, the affected version and the version that fixes it, at low confidence until reachability has ruled.

Reachability filtering, in two steps

The heart of the product. First a deterministic gate: SecAI checks whether the vulnerable functions listed by the advisory are referenced in your repo, via the symbol index produced by the SAST. Absent from the index, the CVE goes NOT_CALLED and drops out without spending any AI. Present, or with no index available, it becomes a candidate: a textual search of the vulnerable symbols (capped at twenty occurrences) feeds a model that judges whether a reference sits on a real execution path, from the entrypoint to the offending function. Confidence is re-evaluated, the invocation site kept as evidence. Reachability mapped for seven languages.

Comment ça marche

Du setup à la première alerte.

  1. 01

    1. You connect your repository

    GitHub via the GitHub App, GitLab via OAuth or token. Read-only access, scope limited to the repositories you tick. SecAI reads your manifests and lock files, no fork and no commit pushed into your code without your action. Encryption at rest, data deletion on request.

  2. 02

    2. SecAI builds the SBOM and cross-references OSV.dev

    Lock-file discovery across eight ecosystems, resolution of the full dependency tree, direct and transitive, with the versions actually installed and their provenance. Every package and every version is matched against OSV.dev advisories. At this stage you already have the inventory, the licenses and the raw list of known vulnerabilities at low confidence, with the version that fixes them.

  3. 03

    3. The reachability pass cuts the noise

    Two steps. Deterministic gate first: if the advisory's vulnerable functions are not in the symbol index produced by the SAST, the CVE is marked NOT_CALLED without a model call. Otherwise, a textual search of the symbols (capped at twenty occurrences) feeds a model that judges the execution path. Without a SAST run, hence no index, the candidates go straight to the model: reachability is still computed, at the cost of higher AI spend. An agent then links what is reachable to the SAST, IaC and secrets into attack paths.

  4. 04

    4. Report, SARIF and CI/CD

    HTML report, native SARIF export for GitHub Code Scanning, PR or MR comments, Slack alerts, webhook or email. The GitHub Action sets a configurable severity gate in your pipeline. GitLab, Jenkins and self-hosted runners go through the secai CLI. Final human verification remains the business of our OSWE pentests, a separate offering.

Bénéfices

L'impact concret pour vos équipes.

01

Stop drowning devs under 500 CVEs

A raw dependency scan surfaces everything declared vulnerable, reachable or not, and the team ends up ignoring all of it out of fatigue. SecAI flips the sorting: the SBOM is the base, the OSV.dev cross-reference identifies the candidates, then the reachability pass first discards deterministically those whose vulnerable functions appear nowhere in your symbol index, before letting AI rule on what remains. What surfaces is short and defensible, with the invocation site as evidence. Your developers stop closing tickets as won't fix and fix what actually matters.

02

Dependency risk tracked continuously, not on a date

A CVE can drop any day on a package you haven't touched in months. A human audit is a snapshot on a given date; between two engagements, your dependency tree moves on every update and the vulnerability landscape changes on its own. SecAI re-cross-references your SBOM against OSV.dev on every commit and on a cron schedule, so yesterday's disclosure surfaces against today's code. Offensive verification remains the job of our OSWE-certified pentesters, as a separate offering: SCA fills the gap between two audits.

03

One view: dependencies, code, infra, secrets

Dependency risk does not live in isolation from the rest. SecAI correlates reachability-filtered SCA with contextual SAST, IaC misconfigs and secrets, in the same scan and the same report. You see the reachable CVE at the end of an attack path, not in a separate tab read once a quarter. HTML report, native SARIF export, Slack, webhook or email notifications: everything comes out of the same place, without stacking three tools that don't talk to each other.

Aperçu

La plateforme en images.

Detail of an SCA finding listing a project vulnerable dependencies, read from the lockfile
Detail of an SCA finding listing a project vulnerable dependencies, read from the lockfileAn SCA finding in detail: the project's vulnerable dependencies, as read from the lockfile. The installed version, not the one in package.json.
List of findings including dependency vulnerabilities detected by SCA
List of findings including dependency vulnerabilities detected by SCAFindings, dependency vulnerabilities included, sorted alongside the rest. You see what comes from a lib and what comes from your code.
Scan history (SCA, IAC, SAST) with credit consumption
Scan history (SCA, IAC, SAST) with credit consumptionThe history of SCA, IAC and SAST scans, with credits consumed. You track the spend as you go.

Pourquoi own2pwn

Ce qu'on fait différemment.

Reachability over the raw list

Most SCA tools surface every CVE present in the tree, reachable or not, and leave the team to sort by CVSS. SecAI starts from the real reference: the vulnerable dependency counts if its offending functions appear in your code and on a plausible execution path, otherwise it leaves the top of the pile at the deterministic gate. That two-step filter is the difference between 500 ignored lines and a short list you actually fix.

Built by an OSWE pentester

SecAI's SCA does not come out of a data team. The prioritisation logic comes from real exploitation: a vulnerable dependency only matters if an attacker can reach and chain it. The OSWE certification is precisely about exploiting white-box application vulnerabilities, exactly where reachability between your code and your dependencies plays out.

AI to triage and correlate, not to chat

Lock-file discovery, SBOM resolution and the OSV.dev cross-reference are deterministic, and the reachability gate discards without AI everything the SAST symbol index does not reference. The model only steps in on ambiguous references, to judge whether they sit on a real execution path, and to link the dependency to the rest (code, IaC, secrets). No chatbot, no opaque verdict: every surfaced CVE shows the invocation site that makes it reachable.

Complementary to your pentests, not a replacement

SCA covers dependency risk continuously, on every commit and on a cron schedule, while your package tree moves. Human validation remains the business of our pentests, a separate offering signed by a pentester. Every report even recommends a review by a professional. We don't sell an AI that replaces the human, we sell the continuity between their passes.

Des tarifs lisibles, sans surprise.

Starter
€0
  • 2 repositories
  • Unlimited deterministic pre-pass (SAST, SCA, IaC, secrets)
  • 20 AI validations / month, up to 10 scans per day
  • Scans on push/PR and cron-scheduled
  • HTML report and SARIF export
  • Community support
Start for free
Recommandé
Pro
€99 / mo
  • Unlimited repositories
  • 250 AI validations / month, up to 200 scans per day
  • LLM agent verification and attack-path correlation
  • GitHub App, SARIF Action, severity gate and auto-fix PR/MR
  • Slack, webhook and email notifications
  • Extra validation at €0.30 (pay-as-you-go), up to 5 users
  • VAT not applicable (art. 293 B of the French tax code)
Subscribe
Team
€299 / mo
  • Unlimited repositories
  • 750 AI validations / month
  • SSO / SAML and RBAC
  • Priority analysis queue
  • Extra validation at €0.30 (pay-as-you-go)
  • Up to 15 users
  • VAT not applicable (art. 293 B of the French tax code)
Subscribe
Enterprise
On request
  • Negotiated validation volume
  • SSO / SAML / SCIM, audit logs
  • Self-hosted runner, dedicated deployment
  • GDPR-compliant DPA, exports and evidence usable in an ISO 27001 or SOC 2 audit
  • Coupling with own2pwn pentests and EASM
Talk to an expert

Questions fréquentes

Ce que vous voulez probablement savoir.

What is SCA, and how is SecAI's different?

SCA (software composition analysis) inventories your application's open-source dependencies and spots the ones carrying known vulnerabilities. Most tools stop there and hand you the full list, often hundreds of CVEs, reachable or not. SecAI adds a decisive step: the reachability pass. We check whether each dependency's vulnerable functions are actually referenced and then called from your code before surfacing it as a priority. The result is a short, defensible list instead of a dump of alerts.

How does reachability filtering work, concretely?

A CVE in a dependency points to specific vulnerable functions or symbols (the advisory's vulnerable_functions). SecAI proceeds in two steps. Deterministic gate: are those symbols referenced in your repo? We check via the symbol index produced by the SAST. Absent, the CVE is marked NOT_CALLED and dropped without calling the model. Present, or with no index available, it becomes a candidate. Then a textual search of the vulnerable symbols, capped at twenty occurrences, feeds a model that judges whether a reference sits on a real execution path, from the entrypoint to the offending function. Confidence is re-evaluated and the invocation site kept as evidence. This is not a full call graph nor an inter-procedural taint analysis over your dependencies: it is a symbol lookup, a bounded textual search and a model judgement.

Do I need to run the SAST for reachability to work?

It works better with it. Reachability relies first on the symbol index the SAST builds over your code: that is what lets us deterministically discard, without AI, the CVEs whose vulnerable functions appear nowhere. If you don't run the SAST, hence without that index, SecAI does not guess blindly: all candidates go to the model for judgement. Reachability is still computed, but AI cost climbs. In practice, SCA and SAST run in the same scan, one feeding the other.

Does the SCA also see transitive dependencies?

Yes, and that's where most of the risk hides. SecAI rebuilds the full tree from the lock files of the eight supported ecosystems: direct dependencies you declared, and transitive ones pulled by them, all the way down. The SBOM indicates which package, which resolved version, imported by what and through which chain (A to B to X). A flaw is very often three levels below what you think, in a package you never installed by hand. The reachability pass applies to transitive dependencies too.

Does the SCA handle license and supply-chain risk?

Yes, in a best-effort pass over the SBOM. The same inventory surfaces each dependency's license, transitive ones included: a copyleft that sneaks in below a permissive lib, a dependency with no clear license text, a license change between two versions. It also spots supply-chain signals, typosquats and malicious packages. That's the kind of detail you'd rather see before an audit or a due diligence, not after, and it lives in the same place as the CVEs.

How is it different from Snyk, Dependabot or OWASP Dependency-Check?

These tools mostly do version matching: they compare your dependency tree against a CVE database and surface everything that matches, reachable or not. That's useful, but it often drowns the team. SecAI keeps that cross-reference (OSV.dev) as a base, then adds the two-step reachability pass to prioritise only the vulnerabilities actually referenced and called from your code, and correlates SCA with SAST, IaC and secrets in a single scan. Our focus is triage by real exploitability and correlation into attack paths, in a pentester's logic where the human keeps the final decision.

Does the SCA replace a human pentest?

No, and that's not the goal. SCA provides continuous coverage of dependency risk between two engagements, where your package tree and the CVE landscape move on their own. Human verification remains our pentest offering, separate, run by an OSWE-certified pentester. The SecAI report states it explicitly: findings must be reviewed by a professional. SCA and the own2pwn pentest complement each other, they don't substitute for one another.

Does my source code leave the EU, and is it used to train a model?

Storage stays in the EU (Germany), encrypted at rest, with an implemented GDPR purge. For analysis, the code is sent to Anthropic's Claude models served through Google Cloud Vertex AI: Google is a provider with a US parent company, covered by standard contractual clauses (GDPR). Neither Google nor Anthropic uses your data to train their models (Vertex AI data governance). Access to your repository is read-only, limited to the perimeter you define.

Go further

SAST, DAST, IAST: the comparison

Three ways to hunt application flaws, and what AI changes.

Read →

SAST and DAST in CI/CD

The DevSecOps guide to wiring analysis into the pipeline.

Read →

The OWASP Top 10 explained

The ten most common web flaw families, and how to deal with them.

Read →

Vibe coding and security

Coding on vibes with AI: the security blind spots it introduces.

Read →

Parlons de votre besoin.

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

Demander une démoNous écrire