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.
- 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.
Prioritisation by real exploitability
We don't rank by isolated CVSS. The hierarchy starts from what is reachable: a critical CVE in a package that is never called ranks below a medium CVE referenced on an exposed path. SCA, SAST, IaC misconfigs and secrets are correlated into attack paths in the same scan, so you see the vulnerable dependency in the context of everything else, not as one more line.
License and supply-chain risk
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 proprietary license, a missing license text. It also spots supply-chain signals, typosquats and malicious packages. All legal and compromise risks you want to see before an audit, not after, in the same place as the vulnerabilities.
Correlated with SAST, IaC and secrets
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 or a leaked secret reads as a complete path, not as one entry in a list.
Comment ça marche
Du setup à la première alerte.
- 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.
- 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.
- 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.
- 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.
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.
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.
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.
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.
- 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
- 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
- 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
- Negotiated validation volume
- SSO / SAML / SCIM, audit logs
- Self-hosted runner, dedicated deployment
- Stronger SLA, compliance support (GDPR, ISO, SOC 2)
- Coupling with own2pwn pentests and EASM
Questions fréquentes
Ce que vous voulez probablement savoir.
Pour aller plus loin
SAST, DAST, IAST: the comparison
Three ways to hunt application flaws, and what AI changes.
Lire →SAST and DAST in CI/CD
The DevSecOps guide to wiring analysis into the pipeline.
Lire →The OWASP Top 10 explained
The ten most common web flaw families, and how to deal with them.
Lire →Vibe coding and security
Coding on vibes with AI: the security blind spots it introduces.
Lire →Parlons de votre besoin.
Démo, devis ou question technique : réponse sous 48 h ouvrées.