Glossary

RBVM Glossary

Plain-English definitions of the vulnerability management, threat-modelling, and EU cybersecurity-regulation terms used across this site and inside the Centraleyezer platform.

  • Risk-Based Vulnerability Management (RBVM)

    A vulnerability management approach that prioritises remediation by the actual business risk each finding poses, rather than by raw severity. RBVM combines the technical attributes of the vulnerability with the asset it affects, the surrounding network, the threat landscape, and the team that will fix it.

    See also: Why RBVM ยท Platform

  • Contextual Risk Score

    Centraleyezer's per-finding score that combines six factors: DREAD, asset criticality, network exposure, exploitability in the asset's environment, CTI signals, and a Human-AI reaction loop. Unlike CVSS, it describes risk in your environment, not in the abstract.

    See also: Why RBVM

  • DREAD

    A structured threat-modelling severity score across five dimensions โ€” Damage, Reproducibility, Exploitability, Affected users, Discoverability. Centraleyezer uses DREAD as the inherent-severity factor in its contextual risk score.

  • Asset Criticality

    The business importance of an asset (low, moderate, important, critical) โ€” set per asset by the people who own it. The same vulnerability on a payment gateway scores higher than on a developer sandbox because the asset criticality differs.

  • Network Exposure

    Where an asset lives in the network โ€” internet-facing, DMZ, internal, or fully isolated. Exposure elevates the risk of every finding the asset carries because it determines whether attackers can reach it.

  • Exploitability (in your environment)

    How practical it would be to weaponise a finding given the asset's actual configuration, version, and compensating controls โ€” distinct from generic, internet-wide exploitation probability metrics like EPSS.

  • CTI โ€” Cyber Threat Intelligence

    External intelligence about the finding and the technology stack: relevant active campaigns, threat actors, and exploitation chatter from feeds tuned to what matters to your organisation. CTI signals raise or lower contextual risk based on what attackers are actually doing right now.

  • Human-AI Reaction Loop

    A factor unique to Centraleyezer's contextual scoring: the platform learns from how each asset owner actually responds to findings (acknowledgement time, remediation time, risk-acceptance patterns). Slow-responding owners raise the operational risk of their assets; fast-responding owners lower it.

  • Asset Inventory

    The authoritative register of every asset Centraleyezer is monitoring โ€” IPs, websites, applications, custom assets โ€” with criticality ratings, owners, and group-based access control. The starting point for any audit-defensible vulnerability programme.

  • CVSS โ€” Common Vulnerability Scoring System

    An industry-standard 0โ€“10 score for the technical severity of a CVE in the abstract. Centraleyezer ingests CVSS data for traceability and reporting but does not use it as a scoring input โ€” CVSS describes the vulnerability, not the risk in your environment.

  • EPSS โ€” Exploit Prediction Scoring System

    A FIRST.org probability score (0.0โ€“1.0) that estimates the likelihood a CVE will be exploited in the wild within 30 days. Useful for industry-wide triage; Centraleyezer does not use it as a scoring input because it is internet-scale, not environment-specific.

  • CISA KEV โ€” Known Exploited Vulnerabilities

    A catalogue maintained by the US Cybersecurity and Infrastructure Security Agency listing CVEs confirmed exploited in the wild. Centraleyezer ingests KEV status as metadata but does not use it as a scoring input โ€” KEV does not describe whether the asset in question is exposed or exploitable in your environment.

  • NIS2 Directive

    EU Directive 2022/2555 on the security of network and information systems. Article 21(2)(m) explicitly requires structured vulnerability handling and disclosure as one of ten minimum security measures for essential and important entities.

    See also: NIS2 page

  • DORA โ€” Digital Operational Resilience Act

    EU Regulation 2022/2554, applicable from January 2025, governing ICT risk management for financial entities. Article 9(4)(b) mandates documented vulnerability and patch-management policies with risk-based prioritisation.

    See also: DORA page

  • ISO 27001 โ€” Annex A.8.8

    The ISO 27001:2022 control on Management of Technical Vulnerabilities. One of the most consistently audited Annex A controls; certification audits sample end-to-end vulnerability records to verify the control is operationally effective.

    See also: ISO 27001 page

  • PCI-DSS โ€” Requirement 6

    The PCI-DSS v4.0 requirement covering bespoke and custom software security, vulnerability management, and patching SLAs (critical: 1 month; high: 3 months) for the cardholder data environment.

    See also: PCI-DSS page

  • CRA โ€” EU Cyber Resilience Act

    EU Regulation imposing cybersecurity requirements on products with digital elements throughout their lifecycle, including vulnerability tracking, disclosure, ENISA notification within 24/72 hours, and SBOM obligations.

    See also: CRA page

  • UAE IAS โ€” Information Assurance Standards

    The foundational UAE national cyber-security framework, issued by the Signals Intelligence Agency (formerly NESA), applicable to federal entities and Critical Information Infrastructure operators. Includes mandatory vulnerability assessment (T7.5), penetration testing, and patch-management (T7.4) controls.

    See also: UAE IAS page

  • CBUAE โ€” Central Bank of the UAE

    The UAE banking regulator. Its binding cyber-security regulations on licensed banks, exchange houses, finance companies, and payment-service providers explicitly require vulnerability and threat management, annual / event-driven penetration testing, and board-level cyber-risk reporting.

    See also: CBUAE page

  • MSSP โ€” Managed Security Service Provider

    A service provider that manages vulnerability management (and other security functions) on behalf of multiple client organisations. Centraleyezer's MSSP edition provides true multi-tenancy with per-client isolation and a reseller API for licence/deployment automation.

    See also: Partners ยท Pricing โ€” MSSP

  • SLA โ€” Service Level Agreement

    In vulnerability management, the documented timeframes by which findings of each severity must be remediated. Centraleyezer enforces SLAs per severity tier with automatic escalation when SLAs approach.

  • Risk Acceptance

    A formal record that a finding will not be remediated within SLA, with a documented reason, named approver, compensating controls, and review date. Required for ISO 27001 and NIS2 audit-defensibility.

  • CVE โ€” Common Vulnerabilities and Exposures

    A standardised identifier for a specific publicly-disclosed vulnerability (e.g. CVE-2024-3094). Centraleyezer ingests CVE data alongside CWE/OWASP correlation for full traceability of every finding.

  • Self-Hosted vs SaaS

    Centraleyezer offers both: SaaS (capped at 10 GB per deployment for database and files combined) and self-hosted Enterprise / MSSP (Docker container, runs in your own cloud or on-prem; air-gap capable).

    See also: Pricing

  • CVSS vs EPSS

    Two complementary scores often confused. CVSS rates the technical severity of a CVE in the abstract (0โ€“10). EPSS estimates the probability that a CVE will be exploited in the wild within 30 days (0.0โ€“1.0). Both describe the vulnerability at internet scale, not in your environment โ€” neither is sufficient for prioritisation on its own.

    See also: Why CVSS isn't enough

  • Vulnerability Scanning vs Vulnerability Management

    Scanning is the discovery step โ€” Nessus, Qualys, Tenable, Rapid7, OpenVAS, Burp etc. produce a list of findings. Vulnerability management is everything that happens next: deduplication, contextual risk scoring, ownership, remediation SLAs, risk acceptance, and audit evidence. Centraleyezer is the management layer above your scanners.

    See also: Why RBVM ยท Platform

  • Tenable Alternatives

    Teams looking for a Tenable alternative usually want either a true RBVM layer above scanners (Centraleyezer) or a different scanner (Qualys, Rapid7, OpenVAS). Centraleyezer ingests Tenable.io and Tenable.sc output and adds contextual risk scoring, NIS2/DORA evidence, and MSSP multi-tenancy that Tenable's stack does not natively provide.

    See also: Why Centraleyezer ยท Platform

  • Qualys Alternatives

    Qualys VMDR is a strong scanner-and-asset platform but mixes scanning, scoring, and reporting in a single SaaS. Teams that want to keep their existing scanner mix and add a contextual scoring + compliance evidence layer use Centraleyezer. Centraleyezer ingests Qualys VMDR output natively.

    See also: Why Centraleyezer

  • Rapid7 Alternatives

    Rapid7 InsightVM ships its own risk score (Real Risk) but it is still scanner-internal โ€” based on the asset and CVE attributes Rapid7 collects, not on your team's response patterns or your network's exposure. Centraleyezer ingests Rapid7 InsightVM output and re-scores findings using DREAD, asset criticality, network exposure, exploitability, CTI, and a Human-AI reaction loop.

    See also: Why Centraleyezer

  • Exposure-Based Prioritisation

    A prioritisation approach that weights each finding by how reachable the affected asset actually is โ€” internet-facing, DMZ, internal, isolated. Exposure is one of the six factors in Centraleyezer's contextual risk score; on its own it is necessary but not sufficient (an exposed asset with a high-effort, low-impact bug is not a top-of-queue item).

    See also: Why RBVM

  • Patch Management vs Vulnerability Management

    Patch management is the operational practice of applying vendor patches across an estate (WSUS, Red Hat Satellite, Ivanti, Intune). Vulnerability management is the broader discipline that decides which patches matter most given risk, tracks compensating controls, and generates audit evidence. Patch management is one โ€” important โ€” remediation tool inside a vulnerability management programme.

    See also: Platform

  • MTTR / MTTD

    Mean Time To Remediate (MTTR) and Mean Time To Detect (MTTD) โ€” the headline operational metrics for a vulnerability management programme. Centraleyezer measures both per-team and per-asset, and feeds the data back into the contextual risk score (a slow-remediating team's findings are operationally riskier than a fast team's findings, even at the same CVSS score).

  • Scanner vs RBVM Platform

    A scanner finds vulnerabilities; an RBVM platform decides which ones matter. The two are complementary, not competitive. Centraleyezer is an RBVM platform that ingests output from 16+ scanners (Nessus, Tenable, Qualys, Rapid7, Burp, Acunetix, Trivy, Wazuh, AWS Inspector, OpenVAS, and more) and adds contextual scoring, compliance evidence, and remediation tracking on top.

    See also: Why Centraleyezer ยท Platform

Glossary โ€” Risk-Based Vulnerability Management Terms | Centraleyezer