"Are we better than last quarter?" You should be able to answer that.

M.A.R.I.A. records risk over time and annotates what moved it — so you can see which decisions worked instead of guessing.

Almost every security tool only shows you now

Open findings today. Criticals today. A number that means nothing without something to compare it against.

So the questions that actually get asked in a planning meeting have no answer:

  • Did the work we did last quarter reduce anything?
  • When did this service become our biggest exposure?
  • We spent three sprints on remediation — what changed?
  • Which of our practices actually moves the needle?

Teams end up arguing from anecdote. And AppSec, one of the few functions that can genuinely prove its value with numbers, ends up defending its budget with feelings.

A continuous record, with causes attached

M.A.R.I.A. keeps a history of risk per application and across the portfolio, annotated with the events that changed it:

  • Risk over time — per application, per team, or across everything
  • Annotated events — releases, dependency upgrades, new findings, resolved findings, ownership changes
  • Cause attribution — every rise and every drop points to what produced it
  • Time to fix — by severity and by team, measured rather than estimated
  • Aging — what has been open longest, weighted by how much it actually matters

The timeline isn't a chart to admire. It's the artifact you take into a planning meeting when you need to argue for time.

Why it matters

A snapshot tells you where you are. A trend tells you whether what you're doing works.

  • A tech lead can show that the upgrade sprint dropped portfolio risk, and ask for the next one with evidence instead of conviction.
  • An AppSec engineer can prove that feedback at pull-request time cut mean time to fix.
  • A CTO can see whether the security investment produced a curve that goes down.

And when risk goes up — which it will, because you ship — you know which change did it, instead of discovering it during an incident.

A practical example

Six months of one application, with the events that moved the line:

payments-api ยท risk, last 6 months

100 โ”ค
 84 โ”ค                    โ•ญโ”€โ”€โ”€โ”€โ•ฎ
 70 โ”ค        โ•ญโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ•ฏ    โ•ฐโ”€โ”€โ•ฎ
 56 โ”ค   โ•ญโ”€โ”€โ”€โ”€โ•ฏ                   โ•ฐโ”€โ”€โ”€โ”€โ”€โ”€โ•ฎ
 42 โ”คโ”€โ”€โ”€โ•ฏ                               โ•ฐโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€
    โ””โ”€โ”€โ”€โ”€โ”ฌโ”€โ”€โ”€โ”€โ”€โ”€โ”ฌโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ฌโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ฌโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ฌโ”€โ”€โ”€โ”€โ”€โ”€โ”€
       Feb    Mar     Apr      May     Jun     Jul

Mar 04  +18  New payment provider SDK โ€” 3 vulnerable transitive deps
Apr 22  +12  /internal/debug exposed through new ingress rule
Jun 09  โˆ’31  Dependency upgrade sprint โ€” 47 findings closed
Jul 02  โˆ’11  Secret rotation + Gitleaks added to CI

Q2 โ†’ Q3: risk down 34%. Mean time to fix: 34 days โ†’ 6 days.

Illustrative example

"We reduced application risk by a third in a quarter, and here is exactly what did it" is a sentence you can say to a board. That sentence is the product.

Explore a timeline with six months behind it.

The demo organization has history, not just a snapshot.