Many tools. Several formats. Three names for the same bug.
M.A.R.I.A. ingests SARIF, CycloneDX and raw scanner output, deduplicates across tools, and gives you one model of what is actually wrong.
Every scanner you add makes the picture worse
A normal pipeline today: SAST, SCA, secrets, container scanning, IaC, DAST. Six categories, often more than one tool per category, each with its own format, its own severity scale, its own identifier scheme, and its own idea of what a "finding" even is.
The result:
- The same vulnerable dependency reported by three tools, as three findings, with three different severities
- Severity scales that don't compare — one tool's "high" is another's "medium"
- No cross-tool correlation: the exposed endpoint and the vulnerable library sitting inside it are unrelated rows in unrelated reports
- Counts that inflate every time you adopt a scanner, making your security program look like it's getting worse the more you invest in it
Teams solve this with a spreadsheet, a script somebody wrote and left behind, or by giving up and looking at one tool.
One model, built from whatever your tools produce
- Ingest — SARIF, CycloneDX and JSON output from the scanners you already run
- Normalize — one severity scale, one identity model, mapped to CVE, CWE and package coordinates
- Deduplicate — the same issue from four tools becomes one finding with four sources of evidence, which makes it more trustworthy rather than four times louder
- Correlate — findings link to the application, the service, the endpoint and the owner
- Track identity — findings keep an identity across scans, so "still open", "reintroduced" and "fixed" are facts instead of guesses
Adding a scanner should improve your picture. Today, mostly, it just increases your count.
Why it matters
Everything else in M.A.R.I.A. depends on this. You can't score an application, evaluate a pull request, or draw a timeline on top of four contradictory reports.
It's also the layer teams most often build themselves — badly, once, and then maintain forever. If you have a script that merges scanner output, you've already built a worse version of this, and you know exactly what it costs to keep alive.
There's a second-order effect too: when duplicates collapse, the number goes down. A team that trusts the count starts reading it again.
A practical example
One vulnerable dependency, as three tools see it — and as M.A.R.I.A. resolves it:
Before — same dependency, three tools:
Trivy CVE-2025-31324 spring-core 6.1.4 CRITICAL pkg:maven/…
Grype GHSA-4wrc-… spring-core 6.1.4 High maven:org.springframework
Dep-Check CVE-2025-31324 spring-core-6.1.4 9.8 cpe:/a:vmware:…
→ 3 findings, 3 severities, 3 identifiers, 1 actual problem.
After — one finding, three sources agreeing:
CVE-2025-31324 · spring-core 6.1.4 → 6.1.6
Severity Critical Confirmed by Trivy, Grype, Dependency-Check
Reachable Yes — called from /api/v1/checkout
Present in payments-api, checkout-worker · Owner: @team-payments
Risk contribution +23 to payments-api
→ 1 finding. One upgrade fixes 2 applications.Illustrative example
Three rows became one, and the one that remains carries more information than the three did: who owns it, where it lives, whether it's reachable, and what fixing it is worth.
No scanners yet? Start there, free.
The Open Scan Pack generates CI templates for a stack of open-source scanners. No login, no repository access — everything runs in your own pipeline.