Every pull request changes your risk. Most teams find out months later.
M.A.R.I.A. comments on the PR with the risk delta: what the change introduces, what it removes, and what needs a decision — while the author still has the context in their head.
Findings arrive long after the decision
Security findings arrive on a schedule that has nothing to do with engineering. A dependency added on Monday shows up in a report three weeks later, assigned to whoever is on rotation, about code they didn't write, in a service they may not know.
By then the fix is archaeology. The author has moved on, the context is gone, and the change is buried under forty commits. The cheapest moment to fix a security problem — the five minutes before merge, while someone is already thinking about that exact code — is the one moment nobody uses.
The reverse is invisible too. When a team does remove risk, nothing records it. Security work looks like pure cost, because only the failures ever get reported.
Risk impact, on the pull request
M.A.R.I.A. evaluates each pull request against the application's current risk baseline and comments directly on it:
- What this PR adds — new dependencies with known vulnerabilities, new secrets, new exposed endpoints, new code in already-risky paths
- What this PR removes — upgrades, deletions, fixes, findings that close
- The net delta — one number: this change moves risk from X to Y
- What needs a human — the two or three items worth a reviewer's attention, not the full list
It's a comment, not a gate. A security tool that starts blocking merges on day one is a security tool that gets disabled in week two.
Why it matters
This is the point where AppSec either enters engineering culture or doesn't.
- The developer gets feedback in the tool they're already in, about code they wrote ten minutes ago, in the review they're already reading.
- The reviewer gets a security opinion without having to be a security specialist.
- The AppSec engineer stops being the person who shows up afterwards with bad news.
- Risk stops being a monthly report and becomes a property of the change.
The point isn't to catch more. It's to catch it when fixing costs five minutes instead of five days.
A practical example
A pull request that adds a feature, upgrades one dependency, and quietly introduces a bigger problem than it solves:
🔎 M.A.R.I.A. — risk impact of this pull request
payments-api Risk 41 → 58 (+17, High)
▲ Added
· jsonwebtoken 8.5.1 — CVE-2022-23529, critical, fix in 9.0.0
· New public route POST /api/v1/refund — no rate limiting detected
▼ Removed
· spring-core upgraded 6.1.4 → 6.1.6 — closes CVE-2025-31324 (−23)
⚑ Needs a decision
jsonwebtoken 8.5.1 is 3 major versions behind and sits in the auth path.
Upgrading to 9.0.0 would make this PR a net −6 instead of +17.
Not blocking. Baseline updates on merge.Illustrative example
Note what the developer receives: a number, a reason, a specific action, and the outcome of taking it — in the place they already are. Nobody had to open a dashboard, and the upgrade this PR did ship gets credited instead of ignored.
See what your team would actually receive.
The demo organization has pull requests with real deltas behind them.