Shield · flaws attackers already use
A flaw just landed on CISA's exploited list. Your patch ships Monday.
Same loop as a researcher's report, second trigger: no researcher, no bounty. The case file records the response time, the control, the evidence and the retirement, and signs a digest of the evidence. Every step says whether it ran live, locally, recorded or simulated.
The problem
CISA adds a flaw to its Known Exploited Vulnerabilities list: attackers are already using it. A five-person SaaS can't tell today whether it's affected, and the patch needs a build, a regression run and a deploy.
What Bountyloop does
Matches the entry to what you run (lockfile + OSV), looks for the flawed path in code (Semgrep, evidence not proof) and at the edge (one harmless test request), then applies ONE pre-approved, reversible edge control from a catalog and checks customers can still work.
Why it matters
The window between “exploited in the wild” and “patch deployed” is where small teams get breached. The control is checked against a real customer journey, and removed once the patched version is reported and re-checked.
How it’s used
In a pilot: Bountyloop reads your lockfile and drives the Worker in front of your app. This desk polls KEV every 60 seconds while it’s open; the patch check runs on demand. You’re interrupted only for a drastic action or a case it couldn’t contain safely.
Exposed routes on Tallowbrook
—
reachable in code AND reached anonymously
Contained
—
Patched + retired
—
Customer journey
—
scripted sign in → send an invoice
Mode
Every fact is labelled LIVE LOCAL SIMULATED RECORDED REPLAY DECLARED. Edge: —. The test request is anonymous, with a marker body and no exploit payload: a blocked test request shows the control is enforced, not that every exploit variant is blocked; Tallowbrook's Worker emulates its server-function endpoints and runs no React decoder.