From everything published, to the few things that matter to you
Regulatory and product security intelligence arrives all day, from dozens of places, in no particular order and mostly about somebody else. GrapeBeaver reads it for you and tells you which of it impacts your organization, your products, and the policies and guidance you have already written.
We read the whole picture, not a handful of feeds
Regulators are the anchor — the FDA, CISA, the UK MHRA, EU MDR/IVDR, Health Canada and IMDRF. But the thing that changes your quarter is rarely announced by a regulator first. It shows up in a standards body's draft, a notified body's position, a sector council's guidance, a manufacturer's own bulletin, or the trade press covering what nobody has published yet.
So we read all of it, every day, and we keep looking for more. Finding publishers worth watching is a standing job rather than a finished list: each candidate is checked before it goes in, and when one earns its place it is added for every subscriber at once. You get a wider picture than you could reasonably assemble yourself, and it gets wider without you doing anything.
Read once, no matter how many places carry it. One advisory cross-posted by three publishers reaches you as one item, with every source that carried it noted. You are never reading the same thing twice to work out whether it is the same thing.
Every item is assessed, and a person signs it off
Each advisory gets one plain summary of what happened and what it asks of you, and a 0–100 score for how serious it is — how exploitable, weighed against what happens clinically if it is. The reasoning sits beside the score, so you can check it against the source rather than take it on trust.
Nothing reaches your inbox unreviewed. A person reads the assessment against the original, corrects it where it needs correcting, and approves it. GrapeBeaver is built and run by product security professionals, and that review is the reason a summary here is worth reading instead of skimming.
Then it is matched to you — and told apart
Tell us what you make, upload an SBOM, add your policies and standards, and say what your organization actually does — places devices on the EU market, reports incidents to a regulator, services devices in the field. Every published advisory is then checked against all of it, and your feed shows the ones that reach you and the reason each one did.
And it never overstates the connection. There is a real difference between "this advisory names a component you ship" and "this is the kind of thing that bears on products like yours", and losing that difference is how an intelligence tool becomes one nobody believes. Both are worth knowing, both appear, and the row tells you plainly which one you are looking at. You will not be told a product is affected on the strength of a category.
What you actually use, day to day
A daily briefing. One page each morning: what moved, what it means for you, what is still open, and what is due. Written once a day and read by everyone on your team, so nobody is briefing anybody else.
A news feed you can work to zero. One row per advisory, with what it impacts and why. Decide it in place — impacted, informed, remediated, not applicable — and it clears. Your answer is the organization's, so a colleague is not deciding the same thing again on Tuesday.
An obligations calendar. Every date an advisory or regulation states, in one place, with the ones that are genuinely your deadline marked apart from the ones that are worth knowing about. Send any of them to your own calendar in a click.
Component support status. Every component in every SBOM you upload, resolved against published end-of-life dates, release history and repository activity — with the date each answer was checked and where it came from. The question a submission asks and a scanner does not answer.
A digest, on your cadence. Daily or weekly, at an hour you choose, with a severity floor you set. It arrives even on a quiet week — carrying what is still open and what is coming — so silence never has to mean "nothing happened" or "something broke".
What the severity badges mean
Four levels, and the scale is published so you can disagree with a score on the evidence. Amber and red appear nowhere else in the product — when you see one, it means something.
| Badge | Score | When |
|---|---|---|
| Critical | 85–100 | Remotely exploitable without authentication, with plausible direct patient-safety impact. |
| High | 65–84 | Remotely exploitable or high impact, with a credible clinical or regulatory consequence. Class I recalls. |
| Medium | 40–64 | Requires adjacent access, authentication, or user interaction. Class II recalls. |
| Low | 0–39 | Informational or guidance-only; requires physical access; no clinical pathway. |
Bringing your inventory in
Upload what your tooling already produces: CycloneDX, SPDX or ISO 19770-2 SWID tags — the three formats NTIA recognises — or a plain CSV, for teams whose device list lives in a spreadsheet. Nested component trees are read all the way down, because a flaw in a dependency of a dependency reaches your patients exactly as surely as one at the top. Where your SBOM carries package identifiers, we use them, and the match becomes a certainty rather than an inference.
Connecting it to the rest of your work
An API gives your GRC or ticketing system read access to advisories, your registered products, what matched them and the assessments written against them — and lets it write a decision back, so closing something there closes it here. Keys are issued and revoked from your own settings and never reach beyond your organization. Included with Business.
curl -H "Authorization: Api-Key gb_your_key_here" \ https://grapebeaver.io/api/v1/matches/?open_only=true