How do I know if a CVE affects my systems?

Read the vendor advisory for affected versions and conditions, search your asset inventory and software bills of materials for those versions, confirm with a vulnerability scanner, and check configuration conditions directly. If your inventory cannot answer the question quickly, improving it is the most valuable follow-up.

Can a vulnerability scanner tell me if I am vulnerable?

Partly. Scanners reliably detect installed versions that match known vulnerabilities. They often cannot see configuration conditions, such as whether a vulnerable feature is enabled, and they may miss components embedded in applications or images. Use scanner results as a starting point and verify conditions from the vendor advisory directly.

What should I do if a CVE is being actively exploited?

Prioritise exposed systems, apply the fix or vendor workaround as an emergency change, and check whether systems were already compromised while vulnerable by reviewing logs and looking for indicators described in advisories. Preserve evidence before rebuilding, and treat any sign of exploitation as a security incident.

Where can I find information about a CVE?

The CVE record provides the identifier, summary, and references. The vendor or project advisory gives affected versions, conditions, and fixes. The National Vulnerability Database adds severity scores and product identifiers, and CISA's KEV catalog indicates known exploitation. Credible security reporting often adds indicators and exploitation details.

What is a software bill of materials?

A software bill of materials, or SBOM, is a list of the components and dependencies that make up a piece of software, including libraries and their versions. It lets teams check quickly whether a newly disclosed vulnerability in a component affects any of their applications or images, without inspecting each one by hand.

How fast should exploited vulnerabilities be patched?

As fast as practical for exposed systems, typically treated as emergency changes measured in days rather than weeks. Internal systems with no path from untrusted networks can follow normal cycles if compensating controls exist. Set explicit targets by exposure and exploitation status, and measure actual time to remediate against them.

How to Check Whether a CVE Affects You

Read the vendor advisory for affected products, versions, and conditions. Search your asset inventory and software bills of materials for those versions, confirm with a scanner, and check configuration conditions. Then weigh exposure and exploitation status, including CISA's KEV catalog, and look for signs of exploitation in logs before and after patching.

Step 1: read the CVE and the advisory

Start with the CVE record for a summary and references, then go to the vendor or project advisory. Advisories usually list exact affected and fixed versions, required configuration or features, available workarounds, and whether exploitation has been observed. CVE summaries are often brief and occasionally imprecise, so the advisory is the authoritative source for whether your version and configuration are in scope.

Note the product names and identifiers used, such as CPE names in the National Vulnerability Database, because they are what scanners and inventories match against.

Step 2: search your inventory

Look up every instance of the affected product and version: servers, appliances, containers, cloud services, and endpoints. For libraries and dependencies, search software bills of materials and dependency manifests across repositories and images, since vulnerable components are often embedded several layers deep.

If you cannot answer this quickly, that is the most important finding. Inventory gaps are why the same question takes days in some organisations and minutes in others.

Step 3: confirm with scanning and configuration checks

Vulnerability scanners and software composition analysis tools match installed versions against vulnerability databases. They are good at finding version matches and poor at seeing configuration conditions, such as whether a vulnerable feature is enabled or whether a module is loaded. Where the advisory lists conditions, check them directly on affected systems. Record both the version finding and the configuration finding, since a matching version with the vulnerable feature disabled may change urgency, though it rarely removes the need to patch.

Step 4: assess exposure and exploitation

Urgency depends on context:

Exposure. Is the affected system reachable from the internet or from untrusted networks?
Exploitation. Is the CVE in CISA's Known Exploited Vulnerabilities catalog, or does the vendor or credible reporting describe active exploitation? Is public exploit code available?
Criticality. What data and functions does the system support?
Severity. CVSS and vendor ratings, weighed alongside the factors above rather than on their own.

An internet-facing system with an actively exploited vulnerability should be treated as an emergency change.

Step 5: check for compromise

For vulnerabilities exploited in the wild, patching is not the end. If a system was exposed while vulnerable, check whether it was already exploited: review logs for the indicators and patterns described in advisories and security reporting, look for unexpected processes, accounts, files, or outbound connections, and preserve evidence before rebuilding. Many serious breaches began with a vulnerability that was patched after exploitation had already happened.

When you cannot patch quickly

Some systems cannot be patched immediately: vendor appliances awaiting a fix, systems with change freezes, or legacy software with no update. Apply the vendor's documented workaround where one exists, restrict network access to the affected service, add monitoring for exploitation patterns, and record the exception with an owner and an expiry date. An unpatched system with compensating controls and a deadline is manageable; one forgotten on an exceptions list is how long-running breaches start.

Step 6: remediate and record

Apply the fix or the vendor's workaround, verify that the version or configuration has changed, and rescan. Record what was affected, when it was fixed, and what checks were done for compromise. Track time to remediate for exploited vulnerabilities as a key metric; it is one of the clearest measures of exposure an organisation has.

Frequently asked questions

How do I know if a CVE affects my systems?: Read the vendor advisory for affected versions and conditions, search your asset inventory and software bills of materials for those versions, confirm with a vulnerability scanner, and check configuration conditions directly. If your inventory cannot answer the question quickly, improving it is the most valuable follow-up.
Can a vulnerability scanner tell me if I am vulnerable?: Partly. Scanners reliably detect installed versions that match known vulnerabilities. They often cannot see configuration conditions, such as whether a vulnerable feature is enabled, and they may miss components embedded in applications or images. Use scanner results as a starting point and verify conditions from the vendor advisory directly.
What should I do if a CVE is being actively exploited?: Prioritise exposed systems, apply the fix or vendor workaround as an emergency change, and check whether systems were already compromised while vulnerable by reviewing logs and looking for indicators described in advisories. Preserve evidence before rebuilding, and treat any sign of exploitation as a security incident.
Where can I find information about a CVE?: The CVE record provides the identifier, summary, and references. The vendor or project advisory gives affected versions, conditions, and fixes. The National Vulnerability Database adds severity scores and product identifiers, and CISA's KEV catalog indicates known exploitation. Credible security reporting often adds indicators and exploitation details.
What is a software bill of materials?: A software bill of materials, or SBOM, is a list of the components and dependencies that make up a piece of software, including libraries and their versions. It lets teams check quickly whether a newly disclosed vulnerability in a component affects any of their applications or images, without inspecting each one by hand.
How fast should exploited vulnerabilities be patched?: As fast as practical for exposed systems, typically treated as emergency changes measured in days rather than weeks. Internal systems with no path from untrusted networks can follow normal cycles if compensating controls exist. Set explicit targets by exposure and exploitation status, and measure actual time to remediate against them.