Home/Offers/Cybersecurity, Identity & Fraud/Vulnerability Prioritisation API

Cybersecurity, Identity & Fraud

Vulnerability Prioritisation API

Your scanner found eleven thousand findings this month. Your patching capacity is maybe four hundred. The whole problem is ordering, and severity scores alone do not order anything usefully.

Vulnerability management vendors
Managed security providers
Enterprise security teams
Cloud posture platforms

Discuss This Build See What It Returns

What your customers would see

example interface

MockupIllustrative mockup of the interface we would build. Figures shown are examples, not results from a live deployment.

The problem this solves

Every vulnerability management programme hits the same wall. Scanners are good at enumeration and produce more findings than any team can act on. The standard response is to sort by a published severity score and work downwards, which guarantees that effort goes to high-severity issues on isolated internal hosts while a medium-severity flaw on an internet-facing authentication service waits its turn.

Severity describes the vulnerability. What matters is the combination of three things the severity score knows nothing about: whether exploitation is actually happening in the wild, whether the affected instance is reachable by someone who would exploit it, and whether the asset matters. A flaw with public exploit code on a public-facing host holding customer data is a different problem from the identical flaw on a laptop in a locked cupboard.

The modelling here is less interesting than the data joining, which is where these projects usually fail. You need a current vulnerability catalogue, exploitation intelligence, your own asset inventory with ownership and criticality, network reachability, and compensating controls. Most organisations have all five in five different systems with no common identifier, and reconciling them is the actual work.

Who buys this

Vulnerability management vendors, Managed security providers, Enterprise security teams, Cloud posture platforms

Category: Cybersecurity, Identity & Fraud

What the API returns

What comes back

A prioritised ranking of findings with the reasoning behind each position
Exploitability assessment from public exploit availability and observed in-the-wild activity
Reachability analysis: whether the affected instance is exposed internally, externally or not at all
Asset criticality from your own classification, ownership and data sensitivity
Compensating-control adjustment where a mitigation genuinely reduces exposure
Remediation grouping, so one patch or configuration change closes many findings at once
Trend reporting on open risk, mean time to remediate and backlog composition
Explicit confidence and missing-input flags where the inventory data is incomplete

Endpoints

Method	Path	Returns
POST	/v1/findings/prioritise	Rank a batch of scanner findings for one estate
GET	/v1/findings/{id}	Full reasoning and inputs behind one ranked finding
POST	/v1/assets/sync	Push or refresh asset inventory, ownership and criticality
GET	/v1/vulnerabilities/{cve}	Catalogue entry with exploitation and advisory context
GET	/v1/remediation/groups	Findings grouped by the single action that resolves them
GET	/v1/trends	Open risk, remediation velocity and backlog composition over time

Request and response

illustrative

Request

{
  "estate_id": "est_clientco",
  "findings": [
    { "finding_id": "fnd_71204", "cve": "CVE-2026-31887",
      "asset_id": "asset_8812", "detected_at": "2026-10-19T02:14:00Z" },
    { "finding_id": "fnd_71205", "cve": "CVE-2026-20114",
      "asset_id": "asset_0441", "detected_at": "2026-10-19T02:14:00Z" }
  ],
  "capacity_hint": { "remediation_slots_this_cycle": 120 }
}

Response

{
  "estate_id": "est_clientco",
  "ranked_at": "2026-10-21T15:26:11Z",
  "findings_ranked": 11284,
  "within_capacity": 120,
  "top": [
    {
      "rank": 1,
      "finding_id": "fnd_71204",
      "cve": "CVE-2026-31887",
      "priority_score": 94,
      "base_severity": 7.5,
      "asset": { "id": "asset_8812", "name": "auth-gw-prod-02",
                 "criticality": "tier_1", "owner": "platform-team" },
      "exploitability": { "public_exploit": true, "observed_in_wild": true,
                          "first_observed": "2026-10-11" },
      "reachability": { "exposure": "internet_facing", "path_confirmed": true },
      "compensating_controls": [],
      "reasoning": "Active exploitation, internet-facing, tier 1 authentication service"
    },
    {
      "rank": 2,
      "finding_id": "fnd_69110",
      "cve": "CVE-2026-19042",
      "priority_score": 88,
      "base_severity": 9.8,
      "asset": { "id": "asset_0441", "name": "db-reporting-03",
                 "criticality": "tier_2", "owner": "data-team" },
      "exploitability": { "public_exploit": true, "observed_in_wild": false },
      "reachability": { "exposure": "internal_broad", "path_confirmed": true },
      "compensating_controls": ["network_segmentation_partial"],
      "reasoning": "Severity high and exploit public, but exposure is internal only"
    }
  ],
  "deprioritised_high_severity": 1842,
  "data_quality": {
    "assets_missing_criticality": 318,
    "findings_without_asset_match": 94
  }
}

Where the data comes from

Public vulnerability catalogues	Published advisories and identifiers, which give the base description and affected versions
Exploitation intelligence	Public exploit repositories and published in-the-wild observations; some commercial sources here are licensed and not redistributable
Vendor advisories	Often more precise than the central catalogue on affected configurations and available mitigations
Your asset inventory	Hosts, services, ownership, environment and data classification — the input that makes prioritisation specific to you
Your network topology and firewall policy	Needed for reachability; without it exposure has to be inferred and the API says so
Your scanner output	The findings themselves, ingested from whichever scanners you already run

On data licensing. Being allowed to read a dataset does not automatically mean you may redistribute it, resell it through an API, or train a model on it. Before any build starts we check the licence, terms and derived-data rules of every source, and we design around the ones that do not permit your intended use. Where a commercial licence is required, that cost is identified during discovery rather than discovered later.

The intelligence layer

The difference between a demo and a service is mostly in this section. These are the parts that keep the answer trustworthy once real traffic is hitting it.

Priority scoring as an explicit, auditable function of exploitability, reachability and asset criticality rather than an opaque model, because security teams have to defend the ordering
Reachability computed from topology and policy where available, inferred from network position where not, with the basis recorded per finding
Asset matching across identifier schemes — hostname, cloud resource id, MAC, agent id — which is where most of the integration effort actually lands
Exploitation signal weighted by recency and corroboration, so a single unverified report does not jump a finding to the top of the queue
Compensating-control modelling that only reduces priority where the control genuinely blocks the attack path, verified against the control's configuration rather than its name
Remediation grouping by patch, package or configuration change, since a team's real unit of work is an action and not a finding
Backtesting against your own historical incidents and exploited findings, which is the only honest way to show the ranking would have helped
Data-quality reporting as a first-class output: unmatched assets and missing criticality are returned, not quietly defaulted

What it changes for the business

Capacity spent where it counts

Ordering by exploitability and exposure puts the limited patching window on findings that can actually be used against you.

Defensible deprioritisation

A recorded reason for not patching a high-severity finding is what makes a risk acceptance survive an audit.

Fewer actions, same coverage

Remediation grouping collapses thousands of findings into a short list of changes.

Visible inventory gaps

Unmatched assets and missing criticality surface as findings in their own right, which is usually the real blocker.

How it fits into your product

How it embeds

Ingests findings from the scanners you already run rather than replacing them
Asset inventory sync from CMDB, cloud provider APIs or agent fleet, on a schedule or on change
Ranked output pushed into your ticketing system with the reasoning attached to the ticket
Capacity-aware output, so the response can be cut to the number of slots a cycle actually has
Deployment inside your infrastructure where asset and topology data cannot leave
Per-tenant estates for managed providers, with separate inventories and scoring policy

Included in every build

Authentication, scoped API keys and per-customer rate limiting
Input validation with predictable, documented error responses
Versioned endpoints so your integration never breaks without notice
Request and response logging for audit and dispute resolution
Latency, error-rate and usage monitoring with alerting
OpenAPI specification, sandbox environment and client examples
Backups, failover design and a documented recovery procedure
An agreed support arrangement once the service is live

How we would build it

about 20 weeks

Discovery and feasibility

Weeks 1–3

This one depends heavily on data access, so we start by proving the sources exist, can be licensed for your use, and actually carry the signal the model needs. If they do not, you find out here.

Architecture and baseline model

Weeks 4–6

A written architecture and a baseline model measured against a holdout period, so you know what accuracy you are buying before the full build starts.

Production build

Weeks 7–16

Data pipelines, model training and serving, historical archive, validation harness, API, security, monitoring and documentation.

Validation and integration

Weeks 17–20

Backtesting against held-out history, accuracy reporting your team can audit, integration support and an agreed retraining cadence.

Commercial models

There is no fixed price list, because the cost is driven by data complexity, integration count, model requirements, request volume and the support level you need. Scope is agreed in writing before development starts.

Fixed-scope prototype

A defined slice of the service, built and priced as one piece of work. The usual first step when the business case needs proving internally.

Fixed-price build

An agreed scope against a written architecture, delivered for an agreed price. Best when the requirements are already clear.

Build then retainer

We build the service, then operate and improve it under a monthly agreement covering monitoring, updates and model maintenance.

White-label product

The service runs under your brand, your domain and your pricing, with MLPivot invisible to your customers.

Questions buyers ask

Does this replace our scanner?

No. It consumes scanner output. Enumeration and prioritisation are different jobs and the scanners are good at the first one. If you are hoping to drop a scanner licence, this is not the build that does it.

What if we do not have an asset inventory?

Then prioritisation is much weaker, and we would say so before taking the work. Without criticality and ownership, the ranking collapses back to exploitability and inferred exposure — better than raw severity, well short of what this should be. In that situation the honest first project is inventory and ownership, and we would rather scope that than deliver a confident-looking ranking built on absent data.

Can you confirm whether something is actually exploitable in our environment?

Not with certainty, and not by testing. Reachability is computed from topology and policy, which tells you whether a path exists on paper. Whether exploitation would succeed depends on configuration detail, runtime protections and specifics no external analysis can settle. We model exposure; we do not attempt exploitation, and we would decline a scope that asked us to.

Is the exploitation intelligence redistributable?

Public exploit repositories and published advisories are. Several commercial exploitation feeds are explicitly not, and if your plan is to resell this ranking to your own customers that changes which sources we can use. We settle it during discovery, because finding out at launch is expensive.

How do you handle findings nobody will ever fix?

Honestly. Some findings sit on systems that cannot be patched for business reasons, and pretending they are in a queue is worse than recording them as accepted risk with a reason, an owner and a review date. The API supports that state explicitly rather than leaving them to rot at the bottom of a list.

All Cybersecurity, Identity & Fraud offers →

Want this built for your platform?

Tell us what your product does today and what you want another system to be able to ask it. We will come back with an approach, a scope and a price.

Discuss This Build Browse All Offers