Vulnerability Management

The Vulnerability Management module governs the lifecycle of vulnerabilities your organization is exposed to: from detection (or external disclosure) through assessment, patch requirement, remediation, and (sometimes) approved exception. It’s the governance layer above your scanners, your patch pipelines, and your incident response.

This module is not a scanner. It does not detect vulnerabilities itself. It is the register and posture layer that holds the vulnerabilities your security team is accountable for, the assessments performed on them, the patch requirements that emerged, and any exceptions when a patch can’t be applied.

When you would reach for this

You set up vulnerability management when:

• A regulator or framework requires a tracked vulnerability register with assessment and remediation evidence.
• Your security team wants vulnerabilities, assessments, and patch decisions in the same governance program as controls, risks, and findings.
• Penetration test results need to be governed with assessment records, not just stored as reports.
• Patch requirements need to be tracked with owners, due dates, and exception handling.
• Vulnerabilities affecting third-party software or services need explicit handling and risk decisions.

You don’t reach for this for the scanning itself (Tenable, Qualys, Snyk, Wiz, etc. detect vulnerabilities) or the patch deployment itself (your patch management pipeline). Vulnerability Management is the governance of what’s been detected, assessed, and addressed.

What lives in vulnerability management

Three primary record types (with related sub-records):

Vulnerability is one tracked vulnerability. It carries:

• A title and a stable key.
• A vulnerability kind (cve, internal-finding, disclosed-bug, configuration-weakness, architectural-weakness, etc.).
• A subject (the affected system, asset, application, or vendor service).
• A severity (free text, mapped from source-system severity into your organization’s vocabulary).
• A status walking through identified, under-assessment, requires-patch, patched, excepted, closed, archived.
• The source (which scanner, which disclosure, which assessment surfaced this).
• An owner.

Vulnerability assessment captures a structured evaluation of one or more vulnerabilities: scope, methodology, findings, exploitability assessment, recommended actions, conclusions.

Patch requirement captures the formal requirement to apply a fix: scope, urgency, due date, owner, dependencies, change management reference.

Related sub-records include patch exceptions (when a patch can’t be applied within the standard timeline) and penetration test records (a specific form of vulnerability assessment).

A worked example: a financial market infrastructure operator governs its vulnerability posture

A financial market infrastructure operator runs critical clearing and settlement systems. Security expectations are extreme: vulnerabilities detected anywhere in the technology stack must be assessed within hours, prioritized, and either patched within SLA or formally excepted with compensating controls. The CISO, Niamh, sets up Vulnerability Management like this.

Step 1: ingest from scanners. The team’s scanners (one for infrastructure, one for applications, one for dependency vulnerabilities, one for cloud configurations, plus an external pen-test program) feed vulnerabilities into the register. Each detected vulnerability becomes a record:

• Vulnerability kind: cve for known CVEs, internal-finding for internally-discovered weaknesses, disclosed-bug for vendor-disclosed bugs, configuration-weakness for misconfigurations.
• Subject: the affected asset or application from Assets or Cloud Governance.
• Severity: mapped from scanner severity into the operator’s canonical scale.
• Source: the scanner’s reference.

Step 2: triage. Each new vulnerability is triaged within hours:

• Confirmed real (not a false positive) or dismissed with rationale (false positive, duplicate of an existing vulnerability, not applicable to the deployed configuration).
• Severity adjusted if the canonical scale disagrees with the scanner’s default.
• Owner assigned.

Step 3: vulnerability assessment. For higher-severity vulnerabilities, a structured vulnerability assessment is performed:

• Scope: which specific systems, configurations, or data are exposed.
• Exploitability: under what conditions can this be exploited.
• Recommended action: patch, configuration change, compensating control, accept.

Step 4: patch requirements. Each vulnerability that requires patching becomes a patch requirement:

• The patch scope (which versions, which systems).
• The urgency tier (immediate, high, normal, low).
• The due date per the operator’s policy (e.g., immediate for critical exploited vulnerabilities, 30 days for high, 90 days for normal).
• The owner (the team responsible for applying).
• A linked change request for the deployment.

Step 5: exceptions. A small number of vulnerabilities cannot be patched within SLA (the patch breaks compatibility, the vendor hasn’t released a fix, the operator depends on a feature affected by the patch). Each becomes a documented exception with:

• The reason the patch can’t be applied.
• Compensating controls (network segmentation, additional monitoring, restricted access).
• The expiry date when the exception will be reconsidered.
• The approver who accepts the residual risk.

These exceptions live in Exceptions as well; the vulnerability record references them.

Step 6: penetration testing. Annual external penetration tests produce vulnerability assessments. Each test’s findings are recorded as vulnerabilities (kind pen-test-finding); the test itself is a vulnerability assessment record with the methodology snapshot.

Step 7: closing the loop. When a vulnerability is patched, the operator records the patch evidence (the change request, the verification scan that confirms remediation). The vulnerability status moves to patched. After verification, the vulnerability is closed.

After a year:

• The register is a governed, audited record of every vulnerability the operator has been exposed to.
• Open vulnerabilities are tracked against SLA with overdue items prominently surfaced.
• Patch requirements link to actual change records, providing the chain of evidence.
• Exceptions are explicit and bounded by expiry.
• An auditor (or a regulator) can be shown the full posture in minutes.

Vulnerability kinds

Kind is free text; use what fits your taxonomy.

What you’ll see in the product

Vulnerability Management lives under Governance → Vulnerability Management in the workspace.

Three top-level tabs: Vulnerabilities, Vulnerability Assessments, Patch Requirements.

Inside a vulnerability, you see the full record, the source scan or disclosure, the linked subject, the assessment history, the patch requirement (if any), the exception (if any), and the closure evidence.

Inside a vulnerability assessment, you see the scope, methodology, exploitability, recommended actions, and linked vulnerabilities.

Inside a patch requirement, you see scope, urgency, due date, the change request that delivers the patch, and the verification status.

Every change is captured in the workspace Audit Log.

Common workflows

Ingesting a scanner finding

1. The scanner pushes vulnerabilities to the register through the integration (typically using Findings for cross-source consistency, then a vulnerability record).
2. Triage assigns owner and adjusts severity.
3. Higher-severity items get a vulnerability assessment.
4. Patch requirement is created for items that require fixing.

Running a penetration test

1. Engage the test through Assurance as a professional-services engagement.
2. Findings from the test land as vulnerabilities of kind pen-test-finding.
3. The test itself is a vulnerability assessment record with the methodology snapshot.
4. Standard triage and patch requirement flow.

Patching

1. From the patch requirement, link to the change request that delivers the patch.
2. After deployment, verify remediation (rescan or other confirmation).
3. Move the patch requirement to complete and the vulnerability to patched.
4. After verification, close.

Granting a patch exception

1. Document why the patch can’t be applied within SLA.
2. Capture compensating controls.
3. Route to an approver authorized to accept residual risk.
4. Create the exception record linked to the vulnerability.
5. Set a review/expiry date.

Looking for the API?

See Vulnerability Management API reference for the v1 REST endpoints to read vulnerabilities, assessments, and patch requirements from an external system.

Related

• Findings - scanner-detected vulnerabilities typically land first as findings.
• Risks - high-impact vulnerabilities may also become risks.
• Exceptions - patch exceptions are recorded here.
• Change Management - patches are delivered through change requests.
• Assets - vulnerabilities are typically anchored on assets.
• Assurance - penetration tests are engaged here.