Skip to main content
own2pwn

AI-Native AppSec

AI-Native SCA

Software composition analysis, filtered by real reachability: is the vulnerable function ever called.

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 (untrusted data tracked from entry to use), IaC and secrets in a single scan. Built by an OSWE-certified pentester, hosted in the EU. A facet of the SecAI platform: self-service signup, free plan with no credit card.

Read-only, hosted in the EU, your code trains no model
We only surface dependency CVEs actually reachable from your code
Reachability
PyPI, npm, Go, Maven, RubyGems, PHP, Rust, NuGet, transitive deps included
SBOM, 8 ecosystems
GDPR, European law, zero training on your code
Hosted in the EU

Features

What composition analysis looks at in your dependencies.

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.

Software composition analysis pricing.

Starter

€0

  • SCA module included in the SecAI offering
  • In plain terms: 2 tracked Git repositories, 20 AI checks per month, 1 person.
  • Unlimited deterministic pre-pass (SAST, SCA, IaC, secrets)
  • Up to 10 scans per day
  • Scans on push/PR and cron-scheduled
  • HTML report and SARIF export
  • Free, no time limit and no credit card
Start for free
Recommended

Pro

€99 / mo

  • In plain terms: unlimited repositories for a team of 5, 250 AI checks per 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)
Subscribe

For businesses only, a company identifier is asked at the next step.

Team

€299 / mo

  • In plain terms: unlimited repositories for a team of 15, 750 AI checks per month.
  • SSO / SAML and RBAC
  • Priority analysis queue
  • Extra validation at €0.30 (pay-as-you-go)
Subscribe

For businesses only, a company identifier is asked at the next step.

Enterprise

On request

  • In plain terms: the validation volume and deployment mode you set in the contract.
  • 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

VAT not applicable (art. 293 B of the French tax code)

How it works

From setup to the first alert.

  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.

Benefits

What reachability triage changes in your backlog.

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 (the standard format for analysis results), Slack, webhook or email notifications: everything comes out of the same place, without stacking three tools that don't talk to each other.

Overview

The platform in pictures.

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 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 consumptionThe history of SCA, IAC and SAST scans, with credits consumed. You track the spend as you go.

Why own2pwn

Why a present CVE is not a reachable CVE.

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.

Frequently asked questions

Your questions about software composition analysis.

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.

Is there a minimum term, and how do I cancel?

No minimum term. The subscription is monthly or annual (annual works out at ten months paid), renewed tacitly at each due date, and you cancel it at any time, with no justification to give: either you do it yourself from your billing area, or you write to contact@own2pwn.fr and the answer comes within 24 hours. No notice period to serve: cancellation takes effect at the end of the current billing period, and you keep access until then. In return, that period is not refunded pro rata. That is not a sales promise, it is article 7 of the terms of sale.

Do I need a credit card for the free plan?

No. The Starter plan opens from the sign-up form, with no payment method: no card to enter, no counter starting after fourteen days. It is not a trial but a free plan with no time limit and its own quotas (2 repositories, 20 AI checks per month, 10 scans per day). The SCA module is included in it, not sold separately. A card only comes into play if you move to a paid plan, and payment happens on own2pwn.fr, by card only.

How long between payment and actual access?

Access opens immediately after the payment is validated. In practice: as soon as the payment is confirmed, the subscription is attached to your account and the plan quotas apply, with no manual step in between. If you subscribe without an own2pwn account yet, the payment creates one and you get an email to set your password: access is live as soon as that is done. If anything gets stuck, write to contact@own2pwn.fr, the answer comes within 24 hours.

Can I change plan mid-subscription?

Yes, and without starting over: the account, the connected repositories and the scan history stay in place, only the quotas change. Modules are never billed separately: SCA comes with the SecAI subscription, so changing plan moves the quotas of every module at once. You request the change by email to contact@own2pwn.fr, stating the plan you want and the date it should take effect; the answer comes within 24 hours. What is settled on the billing side is that the period already paid for is not refunded pro rata (article 7 of the terms of sale); the exact amount and the effective date of the new plan are confirmed to you in writing before anything is validated.

Is SCA isolated, or wired into the rest of the scan?

SCA is not a silo. In a single scan, SecAI links the reachable vulnerable dependency to your code's data flow (taint-based SAST), to infrastructure misconfigurations and exposed secrets, then rebuilds attack paths. A reachable CVE that leads to a sensitive sink (the point where the data is actually used) or a leaked secret reads as a complete path, not as one entry in a list.

Want to know which CVEs actually reach you?

The product is in pre-launch: ask for early access. For a hands-on dependency audit, a reply lands within 24 hours.