Skip to main content

Unified Vulnerability and VulnCheck Enrichment

What is UnifiedVulnerability​

JupiterOne will automatically create deduplicated entities for all Vulnerability objects in your database with a valid cveId property. These will produce a single representation of any open CVEs.

These entities only carry 2 properties from their sources Vulnerability entities: cveId and open status. All other properties on these entites are enriched directly from the VulnCheck EVI data sources.

These enrichments are updated every 24 hours to ensure the latest information is available for your vulnerability data in JupiterOne.

Why add External Enrichment​

A consistent piece of feedback JupiterOne has received concerns the lack of normalization across Vulnerability (CVE) data provided by various sources. One vendor will use certain language for priority such as high, medium, low; whilst another vendor will have CRITICAL, HIGH, MODERATE. We have also consistently seen outdated, missing, or incorrect intelligence data coming from these vendors.

JupiterOne wanted to provide customers with a standardized and extremely high quality real-time Vulnerability and Exposure data feed. We've partnered with VulnCheck and can now bring that data into JupiterOne for your vulnerability data.

What additional Enrichment is Available​

THe current version of UnifiedVulnerability enrichment is focussed primarily on CVSS, EPSS, and MITRE data. There is a lot more information available and we plan to continue to expand our capabilities in this area, as well as enhancing the user experience around Vulnerability Prioritization in general.

How to use UnifiedVulnerability?​

The simplest usage of UnifiedVulnerabilities is as an extension of existing use cases. Any query you have today that looks at a CVE entity can be extended to bring in the enrichment information.

An existing query fetching Hosts with vulnerabilities

FIND Vulnerability AS vuln
  THAT RELATES TO (Device|Host) AS host
RETURN host.displayName, host._type, vuln.id, vuln.severity

This query produces only very basic information about the state of that Vulnerability, and normalizing across the different vulnerability scanners is complex.

Updated query using UnifiedVulnerability

FIND UnifiedVulnerability AS vuln
  THAT IS Vulnerability
  THAT RELATES TO (Device|Host) AS host
RETURN host.displayName, host._type, vuln.*

This updated query now gives you access to all of the below properties for the vulnerabilities you already ingest into JupiterOne!

UnifiedVulnerability Explorer View​

UnifiedVulnerability also includes a new explorer view. To open the explorer view run the following query:

FIND UnifiedVulnerability

UnifiedVulnerability Explorer View

CVSS Properties (Common Vulnerability Scoring System)​

CVSS Score Properties​

  • cvssBasescore: The base CVSS score ranging from 0.0-10.0 that represents the intrinsic severity of a vulnerability. Higher scores indicate more severe vulnerabilities based on exploitability and impact metrics.

  • cvssBaseseverity: The qualitative severity rating derived from the base score, categorized as None (0), Low (0.1-3.9), Medium (4.0-6.9), High (7.0-8.9), or Critical (9.0-10.0).

  • cvssVersion: Indicates which version of CVSS is being used (e.g., 2.0, 3.0, 3.1, 4.0). Different versions have different scoring methodologies and metrics.

  • cvssVectorstring: The textual representation of CVSS metrics in a compressed format (e.g., "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H"). This string encodes all the individual metric values used to calculate the score.

  • cvssSource: Identifies the organization that provided the CVSS score (e.g., "nvd@nist.gov", vendor, or third-party source). Multiple sources may provide different scores for the same vulnerability.

CVSS Impact Metrics​

  • cvssImpactscore: The sub-score representing the impact component of CVSS, measuring the consequences of a successful exploit. This combines confidentiality, integrity, and availability impact ratings.

  • cvssConfidentialityimpact: Measures the impact to confidentiality if the vulnerability is exploited. Values include None (N), Low (L), or High (H), indicating data disclosure severity.

  • cvssIntegrityimpact: Measures the impact to data integrity if exploited. Values indicate whether and how severely data can be modified by an attacker.

  • cvssAvailabilityimpact: Measures the impact to system availability if exploited. Indicates potential for denial of service or system disruption.

CVSS Exploitability Metrics​

  • cvssExploitabilityscore: The sub-score representing how easy it is to exploit the vulnerability. Higher scores indicate easier exploitation based on attack complexity and required conditions.

  • cvssAttackvector: Describes how the vulnerability can be exploited - Network (N), Adjacent (A), Local (L), or Physical (P). Network attacks are typically most severe as they can be conducted remotely.

  • cvssAttackcomplexity: Indicates how difficult it is to exploit the vulnerability - Low (L) or High (H). Low complexity means reliable exploitation, while high requires specific conditions.

  • cvssPrivilegesrequired: Specifies the level of privileges an attacker must have - None (N), Low (L), or High (H). None means no authentication needed, increasing severity.

  • cvssUserinteraction: Indicates whether user interaction is required for exploitation - None (N) or Required (R). Vulnerabilities requiring no user interaction are typically more severe.

  • cvssScope: Indicates whether exploitation can affect resources beyond the vulnerable component - Unchanged (U) or Changed (C). Changed scope increases severity as impact extends beyond the vulnerable component.

CVSS Temporal Metrics​

  • cvssTemporalscore: A modified score that factors in the current state of exploit techniques, remediation availability, and confidence in the vulnerability details. This score decreases over time as patches become available.

  • cvssEnvironmentalscore: A customized score that considers the specific environment where the vulnerable system operates. Organizations can adjust this based on their security requirements and mitigations.

CVSS v2 Legacy Metrics​

  • cvssAccessvector: CVSS v2 metric for attack vector - Local (L), Adjacent Network (A), or Network (N). Replaced by cvssAttackvector in CVSS v3.

  • cvssAccesscomplexity: CVSS v2 metric for access complexity - High (H), Medium (M), or Low (L). Replaced by cvssAttackcomplexity in CVSS v3.

  • cvssAuthentication: CVSS v2 metric indicating authentication requirements - Multiple (M), Single (S), or None (N). Replaced by cvssPrivilegesrequired in CVSS v3.

  • cvssUserinteractionrequired: CVSS v2 boolean indicating if user interaction is needed. Replaced by cvssUserinteraction in CVSS v3.

  • cvssAcinsufinfo: CVSS v2 indicator for "Access Complexity: Insufficient Information". Used when complete access complexity details are unavailable.

  • cvssObtainallprivilege: CVSS v2 boolean indicating whether exploitation grants complete system control. Part of the impact assessment in v2.

  • cvssObtainuserprivilege: CVSS v2 boolean indicating whether exploitation grants user-level privileges. Part of the impact assessment in v2.

  • cvssObtainotherprivilege: CVSS v2 boolean indicating whether exploitation grants other types of privileges. Part of the impact assessment in v2.

EPSS Properties (Exploit Prediction Scoring System)​

  • epssScore: A probability score between 0 and 1 (0-100%) predicting the likelihood of exploitation in the next 30 days. Higher scores indicate greater probability of active exploitation based on threat intelligence and historical data.

  • epssPercentile: The percentile ranking showing what percentage of all CVEs have a lower EPSS score. For example, 90th percentile means this CVE is more likely to be exploited than 90% of all other CVEs.

  • epssLastModified: The timestamp of when the EPSS score was last updated. EPSS scores are recalculated daily as new threat intelligence becomes available.

CVE Core Properties​

  • id: The unique identifier for this vulnerability record in VulnCheck's system. This is VulnCheck's internal ID, distinct from the CVE ID.

  • cveId: The official CVE (Common Vulnerabilities and Exposures) identifier in the format CVE-YYYY-NNNNN. This is the industry-standard identifier for the vulnerability.

  • description: A detailed text description of the vulnerability, including affected components, attack vectors, and potential impacts. This helps security teams understand the nature of the threat.

  • sourceidentifier: The organization or entity that originally reported or coordinated the vulnerability disclosure. Common sources include vendors, researchers, or coordination centers like MITRE.

  • status: The current status of the CVE entry, such as "Analyzed", "Modified", or "Rejected". This indicates the maturity and validity of the vulnerability information.

  • vulnstatus: VulnCheck's assessment of the vulnerability's current state. This may include additional context beyond the standard CVE status.

Date Properties​

  • dateAdded: The date when this vulnerability was added to VulnCheck's database. This helps track when VulnCheck first became aware of the vulnerability.

  • published: The official publication date when the CVE was first publicly disclosed. This is typically when the vulnerability becomes public knowledge.

  • lastmodified: The date when the CVE record was last updated with new information. Changes could include score updates, new references, or additional details.

  • enrichedon: The date when VulnCheck last enriched this vulnerability with additional intelligence. VulnCheck continuously adds threat data, exploit information, and other context.

Exploitation Evidence Properties​

General Exploitation​

  • reportedExploited: Boolean indicating whether this vulnerability has been reported as exploited in the wild. True means active exploitation has been observed by security researchers or organizations.

  • reportedExploitedByThreatActors: Boolean indicating whether known threat actors have been observed using this vulnerability. This suggests targeted, sophisticated attacks.

  • reportedExploitedByBotnets: Boolean indicating whether botnets have weaponized this vulnerability. Botnet usage often indicates widespread, automated exploitation.

  • reportedExploitedByRansomware: Boolean indicating whether ransomware groups have used this vulnerability. Ransomware exploitation represents high business impact risk.

Exploit Maturity​

  • maxExploitMaturity: The highest level of exploit sophistication observed, ranging from proof-of-concept to weaponized exploits. Higher maturity indicates easier exploitation by less skilled attackers.

  • commercialExploitFound: Boolean indicating whether commercial penetration testing tools include exploits for this vulnerability. Commercial availability lowers the barrier for exploitation.

  • weaponizedExploitFound: Boolean indicating whether weaponized exploits exist that can be readily deployed. Weaponized exploits require minimal modification to use in attacks.

  • publicExploitFound: Boolean indicating whether public exploit code is available. Public exploits significantly increase the risk as anyone can access the code.

Exploit Counts​

  • countsExploits: The total number of known exploits for this vulnerability across all sources. Higher counts indicate more widespread exploitation capability.

  • countsBotnets: The number of distinct botnet families observed exploiting this vulnerability. Multiple botnets suggest profitable and reliable exploitation.

  • countsRansomwareFamilies: The number of different ransomware families using this vulnerability. Multiple families indicate high value for initial access or lateral movement.

  • countsThreatActors: The number of distinct threat actor groups observed exploiting this vulnerability. More actors suggest strategic value for targeted attacks.

MITRE ATT&CK Mapping Properties​

  • mitreTactics: List of MITRE ATT&CK tactics associated with this vulnerability (e.g., "Initial Access", "Privilege Escalation"). Tactics represent the attacker's tactical goals.

  • mitreTechniqueids: List of specific MITRE ATT&CK technique IDs (e.g., "T1190", "T1068"). These provide detailed attack patterns and procedures.

  • mitreTechniquenames: Human-readable names of the MITRE ATT&CK techniques. These describe how attackers use the vulnerability in their operations.

  • mitreTechniqueurls: Direct URLs to the MITRE ATT&CK framework pages for each technique. These provide comprehensive technique documentation and detection guidance.

  • mitreTechniquedomains: The ATT&CK domains where techniques apply (e.g., "enterprise-attack", "mobile-attack"). Different domains cover different technology platforms.

KEV Properties (Known Exploited Vulnerabilities)​

VulnCheck KEV​

  • invckev: Boolean indicating inclusion in VulnCheck's Known Exploited Vulnerabilities catalog. VulnCheck KEV contains 130% more vulnerabilities than CISA KEV.

  • vulncheckkevexploitadd: Date when the vulnerability was added to VulnCheck's KEV catalog. This tracks when VulnCheck identified active exploitation.

CISA KEV​

  • inkev: Boolean indicating inclusion in CISA's Known Exploited Vulnerabilities catalog. CISA KEV represents vulnerabilities actively exploited and requiring federal agency remediation.

  • cisaexploitadd: Date when CISA added this vulnerability to their KEV catalog. This is when CISA confirmed active exploitation.

  • cisaactiondue: The deadline by which US federal agencies must remediate this vulnerability. This date is typically 2-3 weeks after addition to KEV.

  • cisarequiredaction: CISA's mandated remediation action, typically "Apply updates per vendor instructions" or specific mitigation steps. Federal agencies must complete this action by the due date.

  • cisavulnerabilityname: CISA's descriptive name for the vulnerability, often more readable than the CVE ID. This helps identify the affected product and vulnerability type.

Timeline Properties​

  • timelineFirstExploitPublished: The earliest date when exploit code for this vulnerability was publicly released. This marks when exploitation became broadly feasible.

  • timelineMostRecentExploitPublished: The most recent date when new exploit code was published. Recent exploits may include improvements or target new platforms.

  • timelineFirstExploitPublishedWeaponizedOrHigher: The first date when weaponized or highly mature exploits appeared. This indicates when low-skill attackers could begin exploitation.

  • timelineNvdPublished: When NIST's National Vulnerability Database published this CVE. NVD publication typically includes CVSS scores and technical details.

  • timelineNvdLastModified: The most recent NVD update for this vulnerability. Updates may include score changes or additional information.

  • timelineFirstReportedThreatActor: The earliest date when a threat actor was observed exploiting this vulnerability. This marks the beginning of targeted attacks.

  • timelineMostRecentReportedThreatActor: The latest threat actor activity observed for this vulnerability. Recent activity suggests continued value for attackers.

  • timelineFirstReportedBotnet: When botnet exploitation was first detected. Botnet adoption indicates scalable, automated attacks.

  • timelineMostRecentReportedBotnet: The latest botnet activity for this vulnerability. Continued botnet use suggests ongoing mass exploitation.

  • timelineFirstReportedRansomware: When ransomware groups first used this vulnerability. Ransomware adoption indicates high value for initial access.

  • timelineMostRecentReportedRansomware: The latest ransomware activity observed. Recent ransomware use represents active business risk.

  • timelineVulncheckKevDateAdded: When VulnCheck added this to their KEV catalog. VulnCheck often identifies exploitation before other sources.

  • timelineVulncheckKevDateDue: VulnCheck's recommended remediation deadline. This may differ from CISA's timeline based on threat intelligence.

  • timelineCisaKevDateAdded: When CISA confirmed exploitation and added to KEV. This triggers mandatory federal remediation requirements.

  • timelineCisaKevDateDue: CISA's mandatory remediation deadline for federal agencies. Missing this deadline requires explanation and compensating controls.

Additional Properties​

CPE and Component Properties​

  • vulnerablecpes: List of Common Platform Enumeration (CPE) strings identifying affected software versions. CPEs use a structured naming scheme to precisely identify vulnerable products.

  • vcvulnerablecpes: VulnCheck's enhanced CPE list with additional coverage. VulnCheck generates CPEs for vulnerabilities missing official CPE data, improving vulnerability scanning accuracy.

  • categorizationTags: VulnCheck's tags for categorizing the vulnerability type, affected components, or attack patterns. Tags enable filtering and prioritization workflows.

Evaluation Properties​

  • evaluatorcomment: Comments from security evaluators providing additional context or clarification. These may include exploitation notes or remediation guidance.

  • evaluatorimpact: The evaluator's assessment of real-world impact. This may differ from CVSS impact based on practical considerations.

Other Properties​

  • open: Status indicating whether the vulnerability is still open/unpatched in tracked systems. This helps identify remediation gaps.

  • trendingGithub: Boolean indicating whether this vulnerability is trending in GitHub discussions or repositories. GitHub trends often correlate with active research or exploitation.

Contents