Vulnerability management that does not stop at the list of findings

Start with what anyone on the internet can see about you – and work your way inwards from there.

You have a result. What does it mean?

The quick check shows what is visible from outside. Below you will find how to read the terminology behind it – and how a list of findings turns into vulnerability management that actually changes something.

Fundamentals

What a vulnerability is

A vulnerability is a flaw or misconfiguration in software, hardware or a procedure that can be abused. It is not the attack but the opportunity for one: the unlocked door, not the break-in.

Three terms get mixed up in everyday use even though they mean different things. Telling them apart is the first step into vulnerability management.

Vulnerability: The gap itself: a coding error, a missing patch, an over-broad permission, an exposed service.
Threat: Who or what might exploit the gap – from automated mass exploitation to a targeted attack.
Risk: The combination of both, weighted by what is at stake. Only this supports meaningful prioritisation.

That is why asking how many vulnerabilities you have leads nowhere. The useful question is which gap is reachable from outside, can be exploited with available means, and hits something that hurts.

Terminology

CVE, CVSS and the OWASP Top 10

Three acronyms appear in practically every test report. They describe different things – confuse them and you prioritise wrongly.

CVE – the identifier

A CVE (Common Vulnerabilities and Exposures) is the globally unique number of a specific vulnerability in a specific product. CVE-2021-44228 denotes Log4Shell and nothing else. CVEs are assigned by accredited bodies known as CNAs, many of which are vendors themselves. The number proves that something has been documented – not how dangerous it is for you.

CVSS – technical severity

CVSS (Common Vulnerability Scoring System) rates on a scale from 0 to 10 how severe a flaw is in technical terms: exploitable over the network or only locally, with or without privileges, with or without user interaction. The base score describes the vulnerability in a vacuum and knows nothing about your environment.

OWASP Top 10 – the classes of flaw

Where CVE and CVSS describe individual cases, the OWASP Top 10 categorises the most common classes of flaw in web applications. It is vendor neutral and revised periodically; the current edition is 2025. In-house code has no CVE number – there, the class of flaw is the only usable handle.

CVE, CVSS and the OWASP Top 10 compared
Term	What it describes	Who maintains it	What it does not tell you
CVE	A single documented vulnerability in a product	MITRE with accredited CNAs	Whether you are affected and how urgent it is
CVSS	Technical severity on a scale from 0 to 10	FIRST	Whether the flaw is reachable in your environment at all
OWASP Top 10	The most common classes of flaw in web applications	Open Worldwide Application Security Project	Whether your specific application is affected

Prioritisation

Why the score alone does not decide

Three questions determine actual urgency. The CVSS base score answers none of them.

Is the system reachable?

A flaw in a service that only listens on the internal network is a different matter from the same flaw on a server anyone can reach from the internet.

Can it be exploited?

There is a world of difference between theoretically conceivable and publicly available exploit code. EPSS estimates the probability of exploitation; the KEV catalogue maintained by the US agency CISA lists vulnerabilities observed being exploited in the wild.

What sits behind it?

A test system without real data and a customer portal holding contract records do not warrant the same protection, even if they run identical software.

A CVSS of 9.8 on a decommissioned test system is less urgent than a 6.5 on the portal where your customers view their contracts. Working strictly down the score list invests effort in the wrong place.

Prioritisation with EPSS and KEV in detail

Reference frame

The OWASP Top 10 2025 at a glance

The ten categories of the current edition. Not a test catalogue but a map of the flaws that occur most often, and most consequentially, in web applications.

A01 Broken Access Control: Access control that can be bypassed: other people's records via manipulated identifiers, functions without a permission check.
A02 Security Misconfiguration: Default passwords, exposed admin interfaces, talkative error messages, missing security headers.
A03 Software Supply Chain Failures: Risks from third-party code and the supply chain: dependencies, build tooling, update channels.
A04 Cryptographic Failures: Missing or weak encryption, outdated algorithms, unprotected transmission of data worth protecting.
A05 Injection: Input executed as a command – in the database, on the command line, or as a script in the user's browser.
A06 Insecure Design: Gaps baked into the design itself, which cleaner implementation cannot close.
A07 Authentication Failures: Weak sign-in: guessing attacks without a brake, insecure session handling, missing multi-factor authentication.
A08 Software or Data Integrity Failures: Unverified updates, data and components – nobody notices that something was altered in transit.
A09 Security Logging and Alerting Failures: Without logging and alerting an attack goes unnoticed until someone else points it out.
A10 Mishandling of Exceptional Conditions: Error cases handled badly: systems that drop into an unsafe mode when something goes wrong.

Categories per OWASP Top 10:2025, retrieved in August 2026. The names are given in the original English, because that is how reports and tools label them.

Process

Identify, assess, remediate, evidence

A scan is a measurement at a point in time and ends with a list. Vulnerability management is the process around it – cyclical, because everything underneath it moves.

Identify

You can only protect what you know about. The most common entry point is not the exotic flaw but the forgotten system.

Assess

Identifier, technical severity, reachability, exploitability and protection requirement come together. The result is a ranking.

Remediate

Ordered by impact per effort, with ownership and a deadline. Where nothing can be done, a compensating control takes its place.

Evidence

Effectiveness is verified, not assumed. That verification is also the basis for audits.

ISO 27001 requires a managed approach to technical vulnerabilities, and NIS2 holds management expressly accountable. In both cases the evidence is not the list of findings but the demonstrable process, with responsibilities, deadlines and a check on effectiveness.

Our role

Our vulnerability management services

SECURITYSQUAD is a provider of information security services certified to ISO 27001 on the basis of IT-Grundschutz. We work vendor neutrally and take on the cycle in whole or in part – from the first inventory through to the evidence your auditors ask for.

Continuous external monitoring

We check your externally reachable systems continuously rather than in campaigns, and report deviations as they arise: expiring certificates, orphaned DNS records, newly exposed services.

Start the quick check

Assessment and prioritisation

We turn lists of findings into a ranking – what is reachable, what is exploitable, what sits behind it. The result is a plan ordered by impact per effort, not a table sorted by score.

View the Cyber Risk Check

Remediation and technical hardening

Security architecture, network and client security: the implementation, once findings turn into measures. Where a gap cannot be closed, we design the compensating control.

View technical hardening

Evidence and audit preparation

Vulnerability management is a requirement of ISO 27001. We anchor the process in the ISMS, document decisions and deadlines, and prepare you for the audit.

View our certification

Detection in operation with GUARDIANVIEW

Between two test runs a periodic measurement is inevitably blind. Our managed SIEM detects attacks while they are happening.

View GUARDIANVIEW

Accountability as your external ISO

We provide your information security officer and take responsibility for the process, instead of leaving you with a list of findings.

Meet your external ISO

Asked often

Frequently asked questions about vulnerabilities

What is the difference between a vulnerability scan and vulnerability management?

A scan is a measurement at a point in time and ends with a list. Vulnerability management is the process around it: who learns of a finding, who decides how urgent it is, who implements the fix, by when, and how effectiveness is evidenced. Without that process, reports accumulate while the security posture stays the same.

What does CVE mean, and how does it differ from CVSS?

A CVE is the unique identifier of a specific vulnerability in a specific product – a number, not a judgement. CVSS rates its technical severity on a scale from 0 to 10. The CVE says what is being discussed; CVSS says how severe it is technically. Neither tells you whether it is urgent for you.

Is a free external security check legal?

As long as only publicly published data is retrieved – DNS records, the TLS certificate, the home page, standardised well-known paths – this is technically no different from a browser visit, and no declaration of consent is required. Active tests are another matter: they interact with systems and, in Germany, fall under sections 202a ff. of the Criminal Code.

How often should you test for vulnerabilities?

Continuously rather than in campaigns. Configurations drift, certificates expire, DNS records are orphaned, new vulnerabilities appear daily. For externally reachable systems, continuous monitoring has proven effective, supplemented by an in-depth review after major changes.

Does the quick check replace a penetration test?

No. The quick check is passive and shows what is visible from outside without any interaction. A penetration test actively examines whether the remaining attack surface can genuinely be exploited. It is carried out solely under written engagement and becomes worthwhile once the passively visible points have been dealt with.

Have your findings put in context

You have the report and want the results assessed, prioritised, or an in-depth test commissioned? We will take the time.

Arrange a conversation