Vulnerability Management

The Vulnerability Management module is the governed register for vulnerability posture. It records what your organization is accountable for, how those items were assessed, what patch requirements exist, which penetration tests support the evidence, and which patch exceptions were approved.

This module is not a scanner, package manager, patch pipeline, incident response system, or raw evidence store. External scanners, penetration-test providers, change tools, and evidence systems remain the systems of work; this module keeps the governance record and safe references to evidence.

What Lives Here

Vulnerability Management has five workspace tabs:

Vulnerabilities record the vulnerability key, kind, source, subject, status, encrypted vulnerability snapshot, affected scope, exploitability, and source reference.
Assessments record structured vulnerability assessment posture, scope, source references, and evidence claim refs.
Penetration tests record engagement scope, result posture, tested date, and evidence claim refs. They do not run tests or store raw reports.
Patch requirements record what fix is required, due dates, trusted-source posture, verification posture, and optional links to vulnerability records or change-management subjects.
Patch exceptions record why a patch is delayed or excepted, compensating controls, effective dates, evidence claim refs, and approval status.

All snapshot fields are encrypted at rest. Routing selectors such as keys, status, kind, and safe subject refs remain searchable metadata.

Common Workflows

Record A Vulnerability

Create a vulnerability record when a scanner, assessment, vendor disclosure, or manual review identifies exposure. Use the subject reference to point at the affected system, asset, application, cloud service, or another governed subject.

Lifecycle actions such as triage, remediation, verification, closure, accepted-risk handling, and false-positive handling evaluate the record’s persisted review and lifecycle refs before status changes. Accepted-risk handling requires an approved Risk Acceptance decision instead of a local flag.

Record An Assessment Or Penetration Test

Use Assessments for broad vulnerability evaluation work. Use Penetration tests for a specific test engagement and result posture. Store summaries, scope, and safe evidence refs here; keep full raw reports in the governed evidence or document system that owns them.

Track Patch Requirements

Create a patch requirement when a vulnerability needs a fix. Record the trusted source, due date, and verification state. Link to change-management using safe subject refs where a change request owns the deployment.

Approve A Patch Exception

Create a patch exception when the patch cannot be applied within the normal timeline. Record the reason, compensating controls, effective dates, and evidence refs. Approval uses the authenticated member performing the action; the request body does not supply or override the approver identity.

What You See In The Product

Vulnerability Management lives under Governance -> Vulnerability Management. The list console has five tabs: Vulnerabilities, Assessments, Penetration tests, Patch requirements, and Patch exceptions. Each record has a detail page with editable metadata, encrypted snapshots, governance refs, archive actions, and workflow actions where applicable.

Patch exception detail pages include an Approve exception action for authorized reviewers. Every create, update, archive, and approval route records workspace audit metadata.

Boundaries

Vulnerability Management does not:

run scanner integrations or penetration tests;
apply patches or deploy fixes;
store raw scanner payloads, raw reports, binaries, logs, or exploit details;
own the formal accepted-risk decision;
own the central exception register;
expose a public v1 API from this module guide.