A scanner tells you what it found. M.A.R.I.A. tells you what it knows.
Every finding, separated into what we know, what we infer, what we don't know, and where sources disagree — each line carrying its source, its date, and its confidence.
A raw finding is a claim with no epistemics
A scanner hands you a rule ID, a severity, a file and a line. What it doesn't tell you is how sure it is, where each piece of that came from, whether another tool disagrees, or whether the vulnerable code is even reachable. So a developer has to reconstruct all of that by hand — and usually doesn't.
The deeper failure is honesty. Most tools present a guess and a fact in the same font. "CVSS 9.8" (a fact) and "this is exploitable" (very often a guess) look identical. When a "critical" turns out to be unreachable twice in a row, the developer stops believing the fourth one — and they're right to.
Communication designed on Grice's maxims
There's a well-known model of what makes cooperative communication actually work — the philosopher Paul Grice's four maxims. M.A.R.I.A. builds the finding around them:
- Quality — don't say what you lack evidence for. A missing signal is shown as unknown, never quietly rendered as "no".
- Quantity — enough, and no more. Sections that are empty simply don't appear; the technical evidence is one expand away, not dumped on top.
- Relevance — lead with why this matters here: the exposure, the data, the reachability of this specific application.
- Manner — an action-oriented title, not a rule ID. "Update lodash 4.17.15 → 4.17.21 in payments-api", not "[CVE-2021-23337] Prototype Pollution".
Four buckets, and each line shows its source
Every finding is split into four honest categories, and every contextual claim carries its provenance — where it came from, when, and how confident the system is:
- What we know — facts drawn one-to-one from attributed evidence: the tool, its version, a vendor-confirmed fix version, a direct vs. transitive dependency.
- What we infer — M.A.R.I.A.'s own conclusions from its deterministic policies, each labelled as an inference with its basis and confidence, never dressed up as fact.
- What we don't know — every relevant missing signal, stated out loud. Reachability with no data is "unknown", not "not reachable".
- Where sources disagree — when two scanners conflict, both signals are shown with their source and date, and the resolution rule that was applied is named. Nothing is silently downgraded.
Fact, inference and recommendation are visually distinct, and the AI — where it's used at all — only ever explains an object that determinism already decided. It never sees your source code, and never asserts exploitability without evidence. Those are red lines in the code, not preferences.
A checkbox is not a fix
Most tools treat "ticket closed" as "risk gone". M.A.R.I.A. separates the two. A finding carries acceptance criteria chosen by template for its category, a definition of done, and an explicit method of proof — and closing the loop means the proof happened:
- Ticking a box in Jira means declared, and nothing more.
- Verified means the stated verification actually ran — most often, the same scanner re-scanned and the finding is genuinely gone.
- A finding only closes when its required criteria are verified and it's absent from the latest scan — or it carries a formal, accountable risk acceptance.
- If it reappears, it reopens itself, the "gone in next scan" criterion flips to failed, and the history is preserved.
This is what turns the audit trail from a liability into a defense: every deferral is recorded, motivated, and reversible.
A practical example
The same CVE a scanner would hand over as one flat row, rebuilt as a finding you can act on:
Update lodash 4.17.19 → 4.17.21 in checkout-api [High]
WHY IT MATTERS HERE
Direct dependency in an internet-facing service handling orders.
WHAT WE KNOW (fact · source · date)
· Fix available: 4.17.21 — snyk · 2026-07-14
· Direct dependency — SBOM (syft) · 2026-07-14
· EPSS 0.62 — first.org · 2026-07-13
WHAT WE INFER (maria policy · confidence)
· Actionability 73/100 — ActionabilityPolicy v3 · High
(fix available +15, direct dep +3, EPSS +8)
WHAT WE DON'T KNOW
· Reachability — no data → treated as unknown, not "safe"
NEXT ACTION
Bump to 4.17.21 (patch, no API change expected)
Proof: the SCA scan stops reporting CVE-2024-XXXX in this repo
Owner (accountable): @checkout-team · Champion: @squad-championIllustrative example
Notice what never happens: reachability isn't guessed, the fix version is attributed to the tool that confirmed it, and the priority number shows its own arithmetic. A developer can act in eight seconds, and an auditor can trace every line to its source.
Why it matters — and why it sells
Trust is the scarcest resource in AppSec. A developer who's been burned by false criticals discounts the whole tool. Transparency — separating what's known from what's guessed, and showing the source of both — is how you earn the trust back. It's also, bluntly, something no scanner and almost no ASPM bothers to do.
And it compounds: a finding that's honest about its own uncertainty is a finding a developer will open a second time.
Open a real finding in the demo.
See the four buckets, the provenance, and the proof-of-fix on live data.