How Vulnerability Management fits into TENSOR — module boundaries, tenant isolation, entities, integrations, background jobs, feature flags, data protection and the audit trail.

How the module fits into TENSOR

Vulnerability Management is a narrow module with a clear boundary. It owns findings and the policy snapshot that sets a due date; with the planned import and remediation capabilities it also owns scan runs and their coverage, observations and remediation groups. Everything else stays with the module that already owns it, and Vulnerability Management works with those modules through their public interfaces.

Module	Owns	Relationship to vulnerability work
CMDB	CIs, relationships, criticality, service impact, asset identifiers	Provides the CI a finding belongs to and the services it affects. Shows open CVEs and suggested patches on each CI.
Integrations	Scanner credentials, polling schedules, vendor parsers	Delivers normalized scan batches from the Tenable, Qualys and Rapid7 adapter. A Nessus file parser is Planned — not yet available.
Feed mirror	Public vulnerability and end-of-life feeds, mirrored into EU storage	Supplies NVD and other feed data for correlation without scan-time calls to US origins.
Patch Management	Patch catalogue, per-CI patch state, advisory ingestion	Suggests the patch that closes a CVE; deploys it as a Change.
Change	Approval, CAB, scheduling, freeze windows, SoD	Governs every patch deployment.
SLA	Business-calendar clocks	Supplies calendars; Vulnerability Management stores the policy that selected a due date.
Exceptions	The single platform store for risk acceptances	Will hold vulnerability risk acceptances with expiry, SoD and compensating control. The store is available; vulnerability subject kinds are reserved but not yet active.
Reporting	Sealed artifacts, retention and access	Produces critical-CVE and DORA RTS Art. 10 evidence reports.
Audit	The append-only, hash-chained record	Receives one event for every change to a finding, patch or acceptance.
Pseudonymization	Masked identity projections, Works Council views	Masks the people named on findings in restricted views.

Tenant isolation

Each tenant's data lives in its own database schema. Every read and every change runs inside a tenant transaction that is bound to your session, and the server additionally checks that the tenant you ask for is the one you are signed in to. A finding ID from another tenant returns nothing, not even an error that would reveal that it exists.

Core entities

These entities are in use on the current release:

Entity	What it holds	Relationships
Vulnerability finding	Title, severity, CVSS score, references, state, disposition, first and last seen, due date, policy snapshot, closure details, reopen counter	Optional link to one CI; optional recommended patch
Patch	Vendor, product, KB article, CVEs closed, severity, release date, source, supersession	Has one status row per CI
Patch status per CI	Not applicable, Missing, In progress, Installed, Failed or Deferred; failure reason; deploying Change	Links one patch to one CI
Change request	The governed deployment	Created from a patch
Report	Sealed evidence artifact with content hash	Bound to the audit chain head at generation time

The following entities belong to capabilities that are Planned — not yet available:

Entity	What it will hold	Relationships
Scan run	Source, file hash, scanner times, parser version, coverage kind, counts	Has many scan assets and observations
Scan asset	Normalized host identifiers, coverage state, match state, matched CI	Belongs to one scan run; may match one CI
Observation	Normalized evidence of presence, with a SHA-256 hash	Links a scan run, a scan asset and a finding; never changed after commit
Remediation group	Name, state, strategy, owner or team, recommended patch, linked Change, due date	Has effective-dated memberships of findings; a finding has at most one active group
Risk acceptance (exception)	Rationale, compensating control, expiry, requester, approver, state	Refers to one finding or group; lives in the shared exceptions store

Integrations with other modules

CMDB — matching of scanned assets to CIs, the CI CVEs panel with Suggested patches, open-CVE counts in impact and topology views, and the critical-function flag that drives DORA detection. See CVEs and lifecycle risk and Reconciliation.
Scanner integrations — a single adapter serves Tenable.io (primary), Qualys VMDR and Rapid7 InsightVM. It pulls assets and vulnerabilities on a schedule into the CMDB CVE workflow and can push a non-destructive "remediated" status back when the closing Change ships, so the next scan reconciles.
Discovery — software found by Discovery is correlated against the mirrored vulnerability feeds (CPE to CVE), with the matching evidence stored.
Patch and Change — a patch deployment creates a Change with all CIs that miss the patch; per-CI outcomes flow back into patch status.
Notifications — a critical CVE on a critical-function CI raises a detection event; a known issue on a patch alerts the change managers of affected pending Changes. There is deliberately no notification per individual finding.
Reporting and audit — evidence reports are sealed through the standard reporting path and bound to the audit chain.

Automation and background jobs

Job	Schedule	What it does
Patch source ingestion	Daily at 06:00	Fetches advisories from each enabled patch source, parses them, creates or updates patches and records the outcome per source. Errors are recorded on the source, never silently dropped. Today the Microsoft Update Catalog is the source with a working parser.
Known-issue feed	Daily (when `patch_known_issues` is on)	Reads your known-issue feed, marks affected patches and sends affected pending Changes back for a decision.
Feed mirror refresh	Daily	Refreshes the EU mirror of public vulnerability and end-of-life feeds and reports each feed as fresh, stale or missing.
Exception expiry	Every five minutes	Marks expired risk acceptances in the shared exceptions store and returns their subjects to active work.
Audit chain verification	Daily	Verifies that the hash chain of the audit log is intact.

An import staging clean-up job, which removes stale staged imports that were never committed, belongs to the Nessus import and is Planned — not yet available.

Feature flags

Flag	Default	Switches on
`vulnerability_management`	Off	The Vulnerabilities workspace, its navigation entry and all its read and write paths. Reversible at any time.
`cve_detection_ui`	Off (on in the financial-services and critical-infrastructure bundles)	CVE recording on CIs. Tenants that have it on automatically get `vulnerability_management` too. Becomes sticky with the first CVE entered on a CI.
`dora_detection_workflow`	Off	DORA-specific behaviour: the critical-CVE detection event and the DORA RTS Art. 10 remediation evidence. Becomes sticky with the first detection event.
`patch_known_issues`	Off	The known-issue feed, the Known issue and Caution marks on patches and the related Change handling. Reversible.
`compliance_module`	Off	The shared exceptions store used for risk acceptance.

Sticky flags

A sticky flag cannot simply be switched off once it has produced a regulated artifact. Switching it off requires a reason and approval by a second person.

All flags are listed in the toggle catalogue.

Data protection

Every column is classified for personal data at schema level. The people who recorded, closed or approved something are classified as identifying; free-text titles and rationales as free text; technical identifiers, hashes and counts as non-personal.
Raw plugin output, banners, paths or file bytes never enter the database, the audit log, application logs, attachment storage or reports. Retrieve raw forensic output from your scanner under its own retention rules. For the planned Nessus import, uploaded files are to be streamed, hashed and parsed, then discarded.
List and detail views respect your view context (standard, pseudonymized or minimized), so restricted and Works Council views show masked identities.
TENSOR does not rank individual employees by remediation performance. Aggregated, pseudonymized program statistics for supervisors and the Works Council are part of the program rollups, which are Planned — not yet available.

Audit trail

Every change to a finding, patch, patch status, deployment outcome, known-issue setting or risk acceptance writes exactly one audit event in the same transaction as the change. The audit log is append-only at database level and hash-chained per tenant; a daily verifier checks the chain. Audit payloads contain IDs, states, counts, hashes and reason codes, never raw scanner output or free-text rationales. Records written by a feed are attributed to the source (system actor), with the person who triggered the run noted separately.

Technical detail for IT administrators

Finding identity. A finding is unique per tenant by (source_kind, source_instance_key, source_asset_key, source_finding_key, port_key, protocol_key). Manual findings use manual as source kind and instance. -1 and an empty string mean "no port" and "no protocol", so database uniqueness cannot be bypassed with NULL values. A CVE is an attribute, never part of the identity.
Concurrency. Findings carry a version number. A change submitted against an outdated version is refused with "The finding changed. Refresh and retry."
Scale. Lists use keyset pagination with a lean row shape and are tested against a 100,000-finding fixture.
Legacy cutover. CVE data that used to live directly on CIs is backfilled into findings with source kind legacy_cmdb. The environment variable VMX_CVE_READ_SOURCE selects the read source per request: legacy (default), dual (reads both, returns legacy, records differences) or vm. Rollback is a variable change, not a restart.
Scanner parsing (Planned). The Nessus parser, which arrives with the planned Nessus import, disables XML external entities and entity expansion and enforces size, host and observation limits before allocating memory.

How it works