Vulnerability Assessment

A vulnerability assessment is a systematic review that identifies, classifies, and prioritizes security weaknesses across systems, applications, and infrastructure. It answers two questions in order: what is exposed, and how serious is each finding. In a vendor ecosystem it is the difference between trusting a third party's security claims and verifying them.

The hard part is scope, not effort. Assessment programs tend to cover the asset classes they were designed around, and the exposure keeps moving. Black Kite's 2026 Supply Chain Vulnerability Report reported 2,130 AI-related CVEs published in 2025, a 34.6% year-over-year rise and more than 200% growth since 2023, alongside over 3,000 publicly accessible and vulnerable AI components found online. An assessment scoped to last year's inventory will not find them.

What Does a Vulnerability Assessment Actually Cover?

It covers whatever layer of the environment is in scope, and scope is where most assessments are decided. The label describes a method rather than a target, so two assessments carrying the same name can examine entirely different things.

Network Vulnerability Assessment

Open ports, exposed services, unpatched network devices, weak protocols, and segmentation gaps.

Application and AppSec Assessment

Flaws in web and mobile applications, including injection, broken authentication, and insecure deserialization, usually paired with code and dependency review.

Host and Configuration Assessment

Operating system patch level, hardening baselines, local privilege issues, and endpoint agent coverage.

Cloud and Identity Assessment

Misconfigured storage, over-permissive roles, exposed management interfaces, and default credentials.

External Attack Surface Assessment 

Everything reachable from the internet, which overlaps with EASM and is the only layer observable without access to the target.

That final category is the one that matters most in third-party risk, because it's the only assessment you can run on a company you don't control.

What Are the Steps in a Vulnerability Assessment?

Discovery, scanning, validation, prioritization, remediation, and verification. Skipping any of the middle three is what produces reports nobody acts on.

• Discovery. Build the asset inventory. You cannot assess what you have not enumerated, and unknown assets are where most findings hide.
• Scanning. Compare observed software, versions, and configurations against known vulnerability data.
• Validation. Remove false positives and confirm each finding is genuinely present and reachable.
• Prioritization. Rank by exploitability and exposure rather than raw severity, using CVSS, EPSS, and KEV together.
• Remediation. Patch, reconfigure, or apply a compensating control, which is where patch management discipline determines the outcome.
• Verification. Rescan to confirm the fix landed. Assessments that stop at the report generate activity rather than risk reduction.

Prioritization is where most programs lose. A findings list sorted by severity alone puts theoretical criticals above confirmed exploitation, and a queue nobody trusts is a queue nobody works. The ranking has to survive a conversation with the person who has to do the patching.

How Is a Vulnerability Assessment Different From a Penetration Test?

A vulnerability assessment finds and ranks weaknesses. A penetration test proves which of them an attacker could actually use. One is breadth, the other is depth, and they answer different questions.

An assessment is broad, largely automated, repeatable, and safe to run frequently. It produces a list. A penetration test is narrow, manual, adversarial, and point-in-time. It produces a story about how far someone got and what they reached.

Neither replaces the other. Running only assessments means never learning whether a chain of medium findings adds up to a critical path. Running only penetration tests means an annual snapshot of an environment that changes weekly. Programs that mature in the right order assess continuously and test periodically.

How Is It Different From a Cyber Risk Assessment?

A vulnerability assessment measures technical weakness. A cyber risk assessment measures business consequences. The first is an input to the second.

A vulnerability assessment tells you a vendor runs an unpatched file transfer appliance exposed to the internet. A cyber risk assessment tells you that the vendor processes your payroll, that the appliance handles the file exchange, and what the loss would be if it failed. Vulnerability data without business context produces a queue nobody can defend to an executive. Business context without vulnerability data produces an opinion.

The distinction matters in vendor programs specifically, because the two are routinely conflated in questionnaires. A vendor answering "yes, we perform vulnerability assessments" has said nothing about scope, frequency, validation, or whether anything gets fixed.

Why Do Vulnerability Assessments Break Down Across a Vendor Ecosystem?

Because you can't scan a network you don't own. Every method that works internally  (authenticated scanning, agent telemetry, configuration review) requires access no third party will grant you. What remains is what the vendor chooses to tell you.

Vendor Remediation Runs Slower Than Enterprise

The results are visible in the data, and they don't improve with company size. Black Kite's 2026 Wholesale and Retail Cyber Risk Report examined 840 enterprises above $1B in revenue and found 76% of retail and 77% of wholesale anchor firms carrying at least one critical-level patch management vulnerability, with 66.6% of retailers exposed to a CVSS 8 or higher flaw. These are organizations that, by and large, report performing vulnerability assessments.

Worse, some findings indicate the assessment is already too late. The same study found 36% of retail firms and 32% of supply chain vendors carrying botnet infection findings, and 45% of retail firms showing active phishing URL findings. Those aren't weaknesses waiting to be exploited. They are signs of a compromise that a scheduled assessment cycle failed to catch.

Assessment Without Enforced Remediation Changes Nothing

The post-incident picture settles the point. Among ransomware victims rescanned after their attack, 62.5% still carried medium-or-higher patch vulnerabilities, and 58.9% still had misconfigured DMARC records. Every one of those findings was discoverable before the incident. Finding a weakness and closing it are separate programs, and only the second one reduces risk.

How Do You Assess Vulnerabilities You Can't Scan?

From the outside in, using evidence that can be observed without permission. Non-intrusive scanning collects what a company exposes to the internet, which is the same surface an attacker examines first, and it requires no agent, no credentials, and no vendor cooperation.

Outside-In Has Real Limits

That approach has a real limit worth stating plainly. An outside-in assessment cannot see internal segmentation, endpoint controls, or anything behind the perimeter. It is strongest exactly where third-party risk is highest, on the internet-facing systems attackers reach first, and weakest on internal controls. Serious programs combine it with documented evidence rather than choosing between them.

That combination is what Black Kite Assess is built around, pairing automated risk assessments of a vendor's external posture with parsed documentation and standards-based evidence. The Vulnerability Intelligence Brief™ adds the exploitability layer on top, weighing EPSS, CVSS, KEV, LEV, and observed exploitation to show which findings across a vendor population are genuinely reachable. Assessment stops being a list and becomes a queue.

See also: Tackle Third-Party CVEs Without Breaking the Bank