Cloudflare announced a new service last week called Vulnerability Discovery and Remediation. The pitch is simple: your scanner found thousands of vulnerabilities. Which one do you fix first?
Their answer is context. Specifically, production context: which routes are active, what traffic they carry, and what security controls are already in place. Feed that context to AI, and the AI can tell you which findings actually matter for your environment.
That is not a new idea. It is the idea we have been building around for medical devices for years.
The only difference is the domain.
The Scanner Problem Is Universal
Cloudflare’s opening line could have come from any product security team at a medical device manufacturer: “Your scanner just flagged 4,000 new vulnerabilities, 78 of them critical. Which one do you fix first?”
Every SCA tool on the market gives you the same output: a CVE, a CVSS score, a red flag, and a generic recommendation to patch immediately.
The scanner doesn’t know anything about your product. It doesn’t know whether the vulnerable function is reachable. It doesn’t know what controls you already have in place. It doesn’t know whether the component sits behind a trust boundary or runs with full system privileges.
Cloudflare solved this for web applications by connecting scanner findings to production traffic data, WAF rules, and route activity. The AI evaluates each vulnerability against what’s actually happening on the network.
We solved it for medical devices by connecting scanner findings to the product’s architecture, threat model, trust boundaries, and design controls. The AI evaluates each vulnerability against how the product was actually designed and secured.
This is not a case of one company inventing a new idea. It is a case of the market finally catching up to a principle that already makes sense in product security: generic severity is not the same thing as real-world risk.
Context Is the Only Thing That Matters
Cloudflare can tell you that a vulnerable route is actively being probed and has no WAF protection. That’s valuable runtime context for a web application.
Product Security Hub can tell you that a CVSS 8.8 vulnerability on setuptools is actually low exploitability because the component runs behind a STIG-hardened trust boundary, the vulnerable function isn’t in the execute path, AppLocker restricts execution to signed binaries, and the environment enforces TLS 1.3 with certificate pinning. Post-mitigation CVSS: 2.1.
Same CVE. Same CVSS score from the scanner. Completely different risk decision once you add context.
This is what evidence-based prioritization looks like. Not overriding the CVSS score with a gut feeling. It is evaluating the finding against the documented truth of your product’s security architecture and arriving at a defensible, traceable risk determination.
That is the actual job of product security.
Where Medical Devices Go Further
Cloudflare’s workflow ends with a proposed patch and a WAF rule. For web applications, that’s usually sufficient. Push a code fix, deploy a rule, move on.
Medical devices don’t work that way.
You can’t push a patch to an implanted cardiac device on the same timeline you’d patch a web server. Your firmware update process might take months. The device might use Just Works Bluetooth pairing because there’s no display for numeric comparison. The component might be locked down by design and the vulnerability is technically present but physically unreachable.
These situations require something a scanner and a patch can’t provide: documented residual risk with justification.
That is where medical devices are different, and honestly where the real work is.
When a vulnerability is triaged as low exploitability, Product Security Hub doesn’t just mark it and move on. It creates a residual risk record that documents the post-mitigation CVSS score, the specific controls that reduce the risk, the exploitability assessment with reasoning, and the justification for acceptance. That record links back to the threat that identified the attack vector, the requirements that address it, and the component it affects.
That chain (vulnerability to threat to requirement to residual risk) is what the FDA wants to see in a premarket submission. No scanner produces it. No WAF rule provides it. It requires a connected product security knowledge base where architecture, threats, controls, and vulnerabilities all live in one system.
The Pipeline
Cloudflare described their workflow as: collect production context, analyze code, validate findings, prioritize, propose mitigations, human reviews.
PSH’s pipeline is similar, but it extends further:
Scan the SBOM against vulnerability databases. Pull the product’s architecture, threat model, trust boundaries, and design controls. AI triages every vulnerability against that context. For affected vulnerabilities without documented threats, AI drafts new threat records tied to the specific component and attack vector. For affected vulnerabilities without documented residual risks, AI drafts risk records with post-mitigation scores and mitigation details. Everything goes to a review screen. The human reviews, adjusts, and approves.
One scan cycle. Triage, threats, and risks. All grounded in the product’s documented data. All traceable. All auditable.
Because the AI costs pennies per run (under a dollar for 200 vulnerabilities), this pipeline can run nightly. The security lead wakes up, opens PSH, and reviews the overnight results. No manual cross-referencing. No spreadsheets. No four-tool workflow.
What This Means
When a $30 billion infrastructure company builds “AI vulnerability triage with production context” for web applications, it validates the approach. That is not a trend to chase. It is a market signal.
Scanners will keep finding more vulnerabilities. AI models will keep getting better at analyzing them. The differentiator is context. Not generic context. Your product’s context: your architecture, your threat model, your controls, your trust boundaries, and the evidence that shows why a risk is or is not relevant.
The companies that document their product security completely and connect it in one system will get more value from every AI tool that touches their data. The companies that scatter their security data across spreadsheets and disconnected tools will keep manually triaging every CVE, one at a time, forever.
This is the lesson. Build the knowledge base first. The AI will follow.