Vulnerability Management

Vulnerability Management is where Cert-IX consolidates the findings produced by your scans into a single, prioritized worklist. Each finding is tied to a known vulnerability — typically identified by a CVE — rated by severity, enriched with real-world exploitation signals, and tracked from first detection through to a verified fix. The goal is simple: help your team spend its effort on the vulnerabilities that actually put you at risk, in the right order.

This page explains where findings come from, how they are prioritized, and how they move through their lifecycle.

Where findings come from

Vulnerability Management does not scan on its own — it aggregates results from the scanning surfaces Cert-IX already provides. A single view can therefore reflect several complementary sources:

Source	What it contributes	Best for
Scan API engines	On-demand and API-driven scans (for example Trivy, Nuclei, Nikto, and OWASP ZAP) that surface CVEs in images, dependencies, and web-facing services	External and CI-driven checks
Bitscanner agent	Continuous vulnerability and CVE detection on internal networks and hosts	Assets behind the firewall
DepCheck (MCP)	Dependency vulnerability checks for codebases and AI coding agents, backed by the same advisory data	Software supply chain

Collecting internal-network findings

Findings from hosts behind your firewall require a scanner agent. Download Bitscanner from downloads.cert-ix.com and register it with your Tenant ID (found under Settings → Organization). See Scanner Agents for deployment steps.

Severity and prioritization

Every finding carries a severity rating derived from its CVSS score, using the four standard bands:

Severity	CVSS range	What it usually means
Critical	9.0–10.0	Severe exposure, often remote code execution or full compromise. Address urgently.
High	7.0–8.9	Significant risk. Prioritize promptly.
Medium	4.0–6.9	Moderate risk. Schedule remediation.
Low	0.1–3.9	Minor risk. Address as capacity allows.

Severity alone is not enough to decide what to fix first: a Medium issue that is being exploited today often outranks a High that isn't. Cert-IX layers real-world exploitation signals on top of the raw CVSS score:

• CISA KEV — whether the vulnerability appears on CISA's Known Exploited Vulnerabilities catalog, i.e. active, confirmed exploitation.
• EPSS — the Exploit Prediction Scoring System probability that a vulnerability will be exploited in the near term.
• Exposure — whether the affected asset is internet-facing or reachable from untrusted networks.
• Asset criticality — how important the affected system is to your operations.

Fix what's being exploited first

A finding flagged on the CISA KEV catalog or carrying a high EPSS score warrants attention ahead of a higher-CVSS issue with no evidence of exploitation. Exploited-in-the-wild vulnerabilities are the ones attackers are using right now.

The vulnerability lifecycle

Findings move through a defined set of states, so each one always has a clear current status and a clear next step:

1. Identified — a scan has detected the vulnerability.
2. Confirmed — it has been validated as a genuine issue rather than a false positive.
3. Assigned — an owner is responsible for remediating it.
4. In Progress — a fix is underway.
5. Pending Verification — the fix has been applied and is awaiting a re-scan.
6. Resolved — a follow-up scan confirms the vulnerability is gone.

A finding can also be marked risk-accepted when a fix isn't feasible and the residual risk is documented and owned instead.

Working with a finding

Opening a finding brings together everything needed to triage and act on it:

• CVE ID — the Common Vulnerabilities and Exposures identifier.
• Severity / CVSS — the score and its band.
• Exploitation — CISA KEV and EPSS indicators.
• Affected assets — the systems where the vulnerability was detected.
• Description — what the weakness is and its potential impact.
• Remediation — recommended guidance for resolving it.
• Status & history — the current lifecycle state and a timeline of changes.

Example finding

The fields below illustrate how a finding reads once collected. The values are a real, publicly documented vulnerability shown purely as an example:

Field	Value
CVE ID	CVE-2021-44228 ("Log4Shell")
Severity	Critical (CVSS 10.0)
Exploitation	Listed on CISA KEV; high EPSS
Affected asset	Service bundling Apache Log4j 2.x
Description	Unauthenticated remote code execution via JNDI lookups in logged strings
Remediation	Upgrade Log4j to a fixed release (2.17.1 or later)
Status	Confirmed → In Progress

Filtering and focusing

Large environments produce a lot of findings, so the list can be narrowed to the slice you care about — for example by severity, lifecycle status, affected asset or asset group, exploitation status (KEV / EPSS), or detection date. A filtered set can be exported for sharing or for raising tickets in your own tools.

Remediation

For each finding, Cert-IX pairs the vulnerability with remediation guidance. The right response depends on the issue:

Option	When to use it
Patch	Apply the vendor's security fix
Upgrade	Move to a newer, unaffected version
Configure	Change settings to remove the exposure
Mitigate	Apply a compensating control when a fix isn't yet available
Accept	Document and formally accept the residual risk

After remediating, run a verification scan against the affected asset. When the follow-up scan no longer reports the vulnerability, the finding moves to Resolved — closing the loop between detection and fix.

Setting remediation targets

Many teams assign a target remediation window to each severity so that nothing serious lingers. Common starting points are:

Severity	Typical target
Critical	1–2 days
High	~1 week
Medium	~30 days
Low	~90 days

note

These windows are illustrative examples that teams commonly adopt — not fixed platform guarantees. Choose targets that fit your own risk tolerance and regulatory obligations.

Best practices

• Scan continuously. Keep scanner agents deployed and run scans regularly so new vulnerabilities surface quickly.
• Prioritize by exploitation, not just severity. Clear KEV-listed and high-EPSS findings ahead of higher-scored issues with no evidence of exploitation.
• Always verify. Re-scan after remediation before moving a finding to Resolved.
• Own accepted risk. When you accept a risk, record who owns it and why, and revisit it periodically.

Learn more

• Analytics Overview — how Vulnerability Management fits alongside the other analytics views.
• Scanner Agents — deploy Bitscanner for internal-network vulnerability detection.
• Scan API Overview — run on-demand scans and pull findings programmatically.
• DepCheck (MCP) — dependency vulnerability checks for codebases and AI coding agents.