Vulnerability Management

The Vulnerability Management endpoints expose the governed vulnerability register, related assessments, and patch requirements.

This is a read-only surface in v1. Creating, updating, and closing vulnerability records happens in the Novantra UI (see the Vulnerability Management user guide).

For shared conventions (auth, errors, pagination, ID format), read v1 conventions first.

Scope required

Endpoints

List vulnerabilities

GET /api/v1/vulnerability-management/vulnerabilities
Authorization: Bearer <access-token>

Query parameters:

Response:

{
  "vulnerabilities": [
    {
      "id": "vuln_01HXY...",
      "vulnerabilityKey": "cve-2026-12345-affecting-clearing-system",
      "vulnerabilityKind": "cve",
      "title": "CVE-2026-12345 in dependency X affecting clearing system",
      "severity": "high",
      "status": "requires-patch",
      "subjectModuleKey": "assets",
      "subjectResourceType": "asset",
      "subjectResourceId": "asset_01HXY...",
      "ownerResponsibilityId": "ra_01HXY...",
      "createdAt": "2026-05-15T08:21:43.000Z",
      "updatedAt": "2026-05-25T14:08:33.000Z"
    }
  ],
  "pagination": {}
}

Get one vulnerability

GET /api/v1/vulnerability-management/vulnerabilities/:vulnerabilityId
Authorization: Bearer <access-token>

Returns the single-vulnerability shape.

List vulnerability assessments

GET /api/v1/vulnerability-management/vulnerability-assessments
Authorization: Bearer <access-token>

Structured evaluations of one or more vulnerabilities (scope, methodology, exploitability, recommended actions).

List patch requirements

GET /api/v1/vulnerability-management/patch-requirements
Authorization: Bearer <access-token>

Formal patch requirements with owner, urgency, due date.

Field notes

vulnerabilityKind

Free text. Common values: cve, internal-finding, disclosed-bug, pen-test-finding, configuration-weakness, architectural-weakness.

subjectModuleKey, subjectResourceType, subjectResourceId

The affected governed object. Typically an asset, but can be a cloud-service record, an application, or a vendor service.

severity

Free text. Map your scanner’s severity into your organization’s canonical scale.

Snapshots

Each record carries rich encrypted snapshots in the in-product UI (exploitability detail, patch dependencies, exception rationale, evidence). In v1 these structured snapshots are not exposed in the API surface; reads return the durable identifying fields.

Real-case integration: feeding open vulnerabilities into a remediation backlog

A platform engineering team maintains a backlog of remediation work prioritized by vulnerability severity and SLA urgency. They want the backlog automatically refreshed from the governed vulnerability register: any vulnerability with status: requires-patch should appear as a backlog item, ordered by severity and due date.

The integration:

1. Calls GET /api/v1/vulnerability-management/vulnerabilities?status=requires-patch to pull active items.
2. Joins each vulnerability to its patch requirement via the linked records (or pulls patch requirements directly with GET /api/v1/vulnerability-management/patch-requirements?status=open).
3. Translates each into a backlog item in the engineering team’s task tracker, with the vulnerability ID and patch requirement ID as the stable references.
4. On reconcile (daily), removes backlog items whose vulnerability transitioned to patched or closed.

The service account holds vulnerability-management:read. The integration runs daily; cursor pagination handles large registers.

A complementary pattern: a CI/CD pipeline that blocks merges of changes affecting subjects with an open critical vulnerability, reading the register at merge time.

Related

• Vulnerability Management user guide - what the module does and when to reach for it.
• v1 conventions - shared request and response patterns.
• Authentication - service accounts and scopes.
• Findings - scanner-detected vulnerabilities often arrive first as findings.