Why Vulnerability Scanning Isn't Vulnerability Management

Vulnerability scanning is the process of identifying known vulnerabilities in your systems. Vulnerability management is the broader process of finding, assessing, prioritising, remediating and continuously monitoring those vulnerabilities.

The distinction matters.

Running a vulnerability scan and receiving a report is useful, but it is not the same as managing the vulnerabilities the scan discovers.

A scanner can tell you that a server is running vulnerable software. It cannot decide whether that vulnerability presents a significant risk to your business, ensure somebody fixes it, or confirm that the fix was successful.

That is where vulnerability management comes in.

What does vulnerability scanning actually do?

A vulnerability scanner examines systems, applications and network services for known security weaknesses.

Depending on the technology being used, a scan may:

• Identify systems and software
• Detect known vulnerabilities
• Match software versions against vulnerability databases
• Assign severity or risk ratings
• Identify missing patches or insecure configurations
• Produce a report of its findings
• Provide a point-in-time view of your security posture

This is valuable information.

But there is an important limitation:

A vulnerability scanner doesn't fix anything.

If a scan identifies 20 vulnerabilities, you still have 20 vulnerabilities.

The scan has identified the problem. It has not managed the problem.

What does vulnerability management add?

Vulnerability management takes the results of scanning and turns them into an ongoing security process.

A typical vulnerability management lifecycle looks like this:

Discover → Scan → Assess → Prioritise → Remediate → Verify → Monitor → Repeat

Each stage has a purpose.

Discover

You need to know what assets you have before you can properly assess them.

That includes servers, workstations, network devices, cloud infrastructure, applications and internet-facing services.

An unknown asset cannot be properly managed.

Scan

Regular vulnerability scanning identifies known vulnerabilities across those assets.

This provides the technical evidence needed to understand where weaknesses exist.

Assess

Not every vulnerability represents the same level of risk to your organisation.

A vulnerability rated "Critical" by a scanner deserves attention, but the scanner's severity rating is only part of the picture.

You also need to understand the context.

Prioritise

Vulnerabilities should be prioritised according to the actual risk they present.

Factors can include:

• Severity
• Exploitability
• Whether exploitation is known to be occurring
• Internet exposure
• The importance of the affected asset
• Availability of a security fix
• Compensating controls
• Potential business impact

For example, a critical vulnerability on an isolated test server may present less immediate risk than a high-severity vulnerability affecting an internet-facing production system.

The objective isn't simply to produce a list of vulnerabilities.

It is to determine what needs to be fixed first.

Remediate

Remediation might involve:

• Installing a security patch
• Upgrading software
• Removing vulnerable software
• Changing a configuration
• Restricting network access
• Replacing an unsupported system
• Applying another appropriate mitigation

The right response depends on the vulnerability and the environment.

Verify

Fixing a vulnerability isn't necessarily the end of the process.

A follow-up scan can confirm whether the vulnerability has actually been remediated.

This is important because remediation can fail. A patch may not have installed correctly, a vulnerable version may still be present, or the original finding may have been caused by a configuration that hasn't actually changed.

Monitor

Once you've fixed today's vulnerabilities, tomorrow's vulnerabilities can still arrive.

New vulnerabilities are disclosed. Software is installed and updated. Systems are exposed to the internet. Configurations change.

That's why vulnerability management needs to be an ongoing process.

Why a single annual scan isn't enough

Imagine a business carries out a vulnerability assessment in January and receives a clean report.

That is useful.

But what happens afterwards?

In February, someone installs a new application containing a vulnerable component.

In March, a new internet-facing service is deployed.

In April, a critical vulnerability is disclosed in software already installed within the organisation.

In May, a firewall rule is changed and a previously inaccessible service becomes internet-facing.

The January scan doesn't know about any of those changes.

This is the fundamental problem with treating vulnerability scanning as a once-a-year exercise.

Your security posture changes throughout the year. Your vulnerability assessment should too.

An annual assessment can provide an important snapshot. It cannot provide continuous visibility into a changing environment.

Vulnerability management isn't "patch everything immediately"

Effective vulnerability management isn't about blindly fixing every finding as quickly as possible.

Organisations have limited resources.

There may be hundreds or thousands of vulnerabilities across an environment, and treating all of them as equally urgent isn't practical.

Instead, vulnerabilities should be prioritised according to risk.

Consider two examples.

Example 1: A critical vulnerability exists on an isolated development server with no sensitive information and no internet connectivity.

Example 2: A high-severity vulnerability affects an internet-facing production server handling sensitive customer information.

The scanner may rank the first vulnerability more severely.

The business may reasonably decide that the second vulnerability requires more immediate attention.

This is why vulnerability management involves more than simply reading the severity column in a scanner report.

The goal is to understand risk in context.

What does good vulnerability management look like?

A practical vulnerability management process can be thought of as six stages.

1. Continuous discovery

Maintain an accurate understanding of the systems and services that exist within your environment.

2. Regular scanning

Scan those systems regularly to identify known vulnerabilities and configuration weaknesses.

3. Risk-based prioritisation

Determine which vulnerabilities represent the greatest risk to the organisation.

4. Remediation

Patch, upgrade, reconfigure, remove or otherwise mitigate the identified weaknesses.

5. Verification

Scan again to confirm that remediation has actually worked.

6. Continuous monitoring

Continue monitoring because the environment and threat landscape are constantly changing.

Then the process starts again.

Discover → Scan → Assess → Prioritise → Remediate → Verify → Monitor → Repeat

That final step is important.

Vulnerability management isn't a project that you complete once.

It is an ongoing security process.

How often should vulnerability scans be performed?

There isn't a single frequency that is appropriate for every organisation.

The right approach depends on factors such as the size and complexity of the environment, the rate of change, internet exposure, regulatory requirements and the organisation's risk profile.

Different approaches provide different levels of visibility.

Annual vulnerability assessment

An annual assessment can provide a useful snapshot and may be appropriate for certain compliance or assurance requirements.

The limitation is obvious: it can leave a large gap between assessments.

Quarterly scanning

Quarterly scanning provides more regular visibility and may be appropriate for organisations with relatively stable environments.

However, significant changes or newly disclosed vulnerabilities can still occur between scans.

Monthly scanning

Monthly scanning provides substantially better visibility and allows vulnerabilities to be identified and addressed more regularly.

For many organisations, this represents a useful balance between coverage and operational overhead.

Continuous or agent-based monitoring

Agent-based vulnerability monitoring can provide much more frequent visibility, particularly across endpoints and servers.

Changes can be detected without waiting for the next scheduled network scan.

This can be particularly useful for organisations that have frequently changing environments or want to maintain a continuous view of their vulnerability posture.

Continuous scanning isn't necessarily required for every organisation.

The important point is that the frequency of assessment should reflect the risk and rate of change within the environment.

Vulnerability management and Cyber Essentials Plus

Vulnerability management is not the same thing as Cyber Essentials Plus.

Cyber Essentials Plus is an independent assessment against the Cyber Essentials technical requirements, including a vulnerability assessment of the systems within scope.

However, the principles behind vulnerability management can help organisations remain prepared for their next assessment.

If vulnerabilities are only considered when an assessment is due, there is a risk that problems will be discovered at the worst possible time.

Regular monitoring provides an opportunity to identify and remediate issues throughout the year.

Instead of:

Assessment → Find problems → Panic → Remediate

you can work towards:

Monitor → Identify → Prioritise → Remediate → Verify → Maintain readiness

For organisations that need to maintain Cyber Essentials Plus certification, this can provide a much more predictable approach to security readiness.

Vulnerability management vs penetration testing

Vulnerability management and penetration testing are sometimes treated as alternatives.

They aren't.

They answer different questions.

A vulnerability scanner might identify an outdated web server.

A penetration tester may be able to demonstrate how that weakness can be combined with another issue to gain access to sensitive information.

Conversely, a penetration test is not designed to provide continuous visibility across every asset in an organisation.

Vulnerability management and penetration testing complement each other. They aren't alternatives.

A mature security programme can use vulnerability management to maintain ongoing visibility and penetration testing to provide deeper, expert-led assurance at appropriate intervals.

What happens if you only scan?

Suppose your scanner reports no critical vulnerabilities.

Is your organisation secure?

No.

A clean vulnerability report is useful evidence that the scanner did not identify vulnerabilities within the scope, configuration and capabilities of the assessment.

It isn't proof that the organisation is secure.

Vulnerability scanners have limitations. They primarily identify known weaknesses, and not every security problem can be detected automatically.

A clean scan doesn't tell you that your applications are logically secure.

It doesn't prove that access controls cannot be bypassed.

It doesn't demonstrate that your security controls would withstand a determined attacker.

And it doesn't mean that a new vulnerability won't be introduced tomorrow.

That's why vulnerability scanning should be considered one component of a broader vulnerability management process.

From vulnerability scanning to vulnerability management

The difference can be summed up simply:

Vulnerability scanning tells you what might be wrong.

Vulnerability management makes sure you do something about it.

Scanning provides visibility.

Management provides a process.

When the two are combined with appropriate prioritisation, remediation and verification, organisations can move away from treating vulnerabilities as an annual report and towards managing them as an ongoing business risk.

For organisations preparing for Cyber Essentials Plus, this approach has an additional benefit: problems are more likely to be identified and addressed before the next assessment rather than immediately beforehand.

Your security posture doesn't stand still.

Your vulnerability management shouldn't either.