Guidance on selecting, deploying, and using automated vulnerability scanning tools for organisations of every size.
- Introduction
- Audience and structure
- Advantages of vulnerability scanning
- Relationship to manual testing
- 1. Evaluate the existing vulnerability management programme
- 2. Identify the assets
- 3. Choose an appropriate type of vulnerability scanner
- 4. Choose a deployment model
- 5. Decide which assets to scan and when
- Additional considerations
Introduction
Vulnerability scanning is a broad concept that refers to the automated identification of weaknesses within an organisation’s security programme. These weaknesses may relate to areas such as patch management, system hardening practices, and the software development lifecycle (SDLC). Products and services that perform this type of scanning are also commonly referred to as vulnerability assessment systems (VASs).
When incorporated into an effective vulnerability management programme (VMP), vulnerability scanning can provide a cost-effective way to automatically identify security weaknesses across organisational networks. However, the vulnerability scanning market covers many specialised areas and offers a wide variety of products and services. These differ in areas such as deployment model, functionality, and licensing costs. As a result, selecting the most suitable vulnerability scanning solution can be challenging.
This guidance is intended to help a broad range of organisations identify and select an appropriate vulnerability scanning solution.
Audience and structure
This guidance is intended for SMEs, large enterprises, and public sector organisations seeking to:
- understand the fundamentals of vulnerability scanning and its role within a VMP
- determine when vulnerability scanning should be used and how it can be applied effectively
- establish the key criteria for evaluating and purchasing a vulnerability scanning solution
The guidance is organised into several stages. It starts by assessing the current vulnerability management environment, then considers the appropriate type of scanner and deployment model. It also addresses which assets should be scanned and how frequently scanning should take place, before concluding with additional evaluation criteria.
Advantages of vulnerability scanning
Organisations can gain several important benefits from vulnerability scanning:
- automation: scans can be scheduled, launched on demand, or triggered by specific events, such as a new software build or the deployment of a server. This makes it possible to maintain a current view of the organisation’s vulnerability landscape.
- speed: vulnerability scanners can typically perform hundreds or thousands of checks much faster than would be practical through manual testing.
- cost-effectiveness: the combination of automation and speed makes vulnerability scanning considerably more economical than performing equivalent checks manually.
- scalability: modern cloud-based architectures allow scanning resources to scale up or down. This enables both small and large environments to be assessed within broadly comparable timeframes.
- compliance: many scanning platforms provide dedicated checks for widely used information security standards as well as organisation-specific security baselines.
- accuracy: scanners can perform purpose-built checks to verify whether vulnerabilities are actually present. This can produce more dependable findings than relying only on information contained in software asset management systems.
Most importantly, vulnerability scanning enables organisations to keep pace with individuals and groups attempting to compromise systems. Many attackers use comparable tools and techniques to identify security weaknesses.
Relationship to manual testing
Automated vulnerability scanning does not provide the same breadth or depth of assessment as manual security testing methods such as penetration testing.
Instead, automated scanning should be regarded as a cost-effective method for identifying and managing common security problems without requiring specialist security testers for every assessment.
Regular vulnerability scanning can also eliminate much of the easily identifiable “low-hanging fruit.” This allows penetration testing engagements to concentrate more efficiently on complex weaknesses that require human expertise.
1. Evaluate the existing vulnerability management programme
Vulnerability scanning only reduces organisational risk effectively when it forms part of a broader vulnerability management programme (VMP).
VMPs typically include the following processes:
- System discovery: identifying assets owned by the organisation
- Asset classification: grouping or categorising assets according to shared characteristics
- Vulnerability detection: identifying and validating vulnerabilities affecting those assets
- Vulnerability triage: prioritising vulnerabilities according to technical and business considerations
- Vulnerability remediation: providing guidance on resolving identified issues and confirming that remediation has been successful
- Vulnerability disclosure: establishing a mechanism through which security researchers can report relevant vulnerabilities.
Supporting a VMP
Vulnerability scanning platforms often include capabilities that support or integrate with different stages of a VMP. Examples include:
- discovering systems by regularly checking IP address ranges for new hosts or identifying newly deployed web applications
- comparing discovered systems with existing asset management records
- customising vulnerability reports so that findings reflect organisational or business priorities
- supporting remediation by rescanning individual vulnerabilities and confirming when they have been successfully resolved
- integrating with systems such as bug trackers and source code repositories to coordinate and automate workflows
- providing a secure authenticated portal through which authorised users can access, review, and collaboratively manage vulnerabilities
Determining required features
The importance of these capabilities when selecting a vulnerability scanning solution depends heavily on the maturity of the existing VMP. Some functions may significantly improve vulnerability management, while others may introduce unnecessary complexity.
For example, an organisation that does not yet have a formal VMP may benefit from a platform that provides a central portal. Such a portal could allow different administrators to review and manage vulnerabilities associated with the systems under their responsibility.
In contrast, an organisation with a mature and well-established VMP may already possess these capabilities. In this case, the primary requirement may simply be a scanner that can export findings in formats that integrate easily with existing systems.
Additional capabilities that should be considered when purchasing a vulnerability scanning solution are described later in this guidance.
2. Identify the assets
Within vulnerability scanning, the term “asset” refers to a physical or virtual entity to which vulnerabilities can be associated. The exact form of an asset depends on the type of scanning being performed. Examples include:
- a network infrastructure device such as a router or switch
- a connected physical or virtual host, including a laptop, peripheral device, or server
- an instance of a web platform or application
- cloud-hosted systems or endpoints
Most organisations operate a mixture of assets across several or all of these categories, although some asset types may be more common than others. Identifying and documenting these assets, ideally in an asset register, is therefore essential when selecting the most appropriate vulnerability scanner or combination of scanners.
Cost estimation
Many vendors license vulnerability scanning services on a “per asset” basis. Establishing an accurate estimate of the number of assets is therefore also important for forecasting procurement costs. Free or low-cost port scanning tools can often assist with this process by identifying active hosts on a network.
Some parts of an IT environment may be highly distributed. A common example is an organisation with remote employees using personally owned mobile devices. In such situations, the priority should be the common services through which those remote devices access organisational resources.
For example, remote users may authenticate through a single externally accessible web portal or Virtual Private Network server. Security of the remote devices themselves remains important, but remote vulnerability scanning is unlikely to provide significant value in such circumstances. Instead, common vulnerabilities on these devices should be reduced by keeping software and devices up to date.
After all relevant organisational assets have been identified, they should be divided into logical groups. For example, servers and web applications supporting the organisation’s primary website could form one group, while internal desktop systems could form another.
This approach creates smaller and more manageable scopes for individual vulnerability scans.
As described in the section on evaluating the vulnerability management programme, some scanning solutions can automate parts of this process by providing built-in asset discovery and classification capabilities.
3. Choose an appropriate type of vulnerability scanner
Vulnerability scanners are generally categorised according to the type of target they are designed to assess. At the broadest level, the distinction is between scanners focused on infrastructure and those focused on applications.
Application scanners can be further divided into tools designed for web applications and tools intended for native applications.
Additional specialised categories also exist. These include scanners designed for cloud infrastructure, mobile applications, or web applications developed with particular platforms or technologies.
Specialised scanners can provide more accurate and relevant findings for the specific targets they are designed to assess. However, most organisational IT environments contain too much technological diversity for a single specialised scanner to provide complete coverage.
A generalised scanning capability should therefore normally be established first. This creates a baseline level of coverage for the most common infrastructure vulnerabilities.
Where an organisation operates assets in more specialised categories, and sufficient budget is available, a layered scanning approach can provide broader protection. Specialised scanners can then supplement the foundational infrastructure scanning capability.
Infrastructure scanners
Infrastructure vulnerability scanners are primarily designed to identify and assess network services that are accessible from other parts of the network or from the Internet. For this reason, these products commonly include host discovery and port scanning functionality.
After discovering an accessible network service, the scanner typically attempts to gather as much information about it as possible. Techniques such as “fingerprinting” and “banner grabbing” may be used to identify information such as the software vendor and version.
Many infrastructure scanners also send safe test requests to certain types of services. These requests can produce more informative responses or directly verify whether a particular vulnerability is present.
Once the scanner has identified a service fingerprint, this information can also be compared with a vulnerability knowledge base containing information about products known to contain security weaknesses.
Some network vulnerability scanners use more advanced techniques and can perform checks that require authentication. However, their primary objective is usually broad coverage rather than deep assessment.
For example, these scanners generally cannot fully navigate complex web applications or identify vulnerabilities that depend on complicated interactions with specialised protocols. They may still detect weaknesses affecting the same exposed ports, such as outdated software or insecure encryption settings.
Network vulnerability scanners are therefore particularly useful for continuously monitoring networks with large external attack surfaces. They can identify newly disclosed or newly exposed vulnerabilities that could potentially be exploited from the Internet or from within the corporate network.
They are also well suited to IT environments consisting mainly of commercially available, “off-the-shelf” technologies with little or no custom-developed software.
Web application scanners
Web application vulnerability scanners are specifically designed to identify security weaknesses in applications and services exposed through HTTP or HTTPS.
These scanners interact with web applications in ways that resemble the behaviour of a browser. However, they can generate requests at a much higher rate and deliberately construct those requests to trigger responses that may reveal the presence of security vulnerabilities.
Web application scanners commonly test for a broad range of security weaknesses affecting both the web server and users of the application.
The vulnerability categories tested often correspond with resources such as the OWASP Top 10, which is periodically updated to reflect some of the most significant security risks affecting web applications.
Unlike general network infrastructure scanners, web application scanners are specifically designed to identify security weaknesses in custom-developed and potentially complex web applications.
More advanced web application scanners may support detailed target configuration. This can include specifying the application’s login page and authentication credentials or excluding particular pages and categories of tests from a scan.
Without these capabilities, a scanner may fail to achieve adequate coverage of complex applications. It may also generate unwanted side effects. Repeatedly submitting forms, for example, could create large numbers of unnecessary database records.
In general, the more precisely a scanner is configured for a specific target application, the more relevant and valuable its findings are likely to be.
Web application security scanners are particularly effective when used alongside network vulnerability scanners. They are also highly relevant where custom web applications represent a large proportion of an organisation’s externally exposed infrastructure and therefore account for a significant share of business risk.
The NCSC Web Check service is an example of a web application scanning service, although it is available only to public sector organisations. Web Check is intentionally designed as a “light-touch” service focused on identifying common and broadly applicable security weaknesses.
Native software scanners
Native software scanning tools share some similarities with web application scanners because they are also intended to identify common weaknesses in the design and deployment of custom-developed applications.
Unlike web application scanners, native software scanners are intended for use within an internal environment. They are often executed on the same host as the application being evaluated or in an environment with direct access to the application’s source code.
This level of access allows checks to be performed that would not be possible when assessing an externally accessible web application with limited network exposure.
The identification and management of vulnerabilities within the software development lifecycle is outside the scope of this guidance. Additional information is available in the Secure Development Principles, including the guidance on how to continually test security.
Comparing infrastructure and web application scanners
| Type of vulnerability scanning | Associated assets | Examples of issues identified |
| Infrastructure | – Network infrastructure components; – physical hosts; – virtual hosts; – end-user devices; – cloud-hosted systems or endpoints | – Missing operating system or application patches; – unsupported operating systems or applications; – default or weak passwords; – weak cryptography or clear-text services; – exposure of sensitive services or information; – insufficient security hardening; overly permissive access controls |
| Web application | – API endpoints; – web applications; – domains | – Injection vulnerabilities caused by malicious input; – broken authentication; – exposure of sensitive personal or system information; – broken access control; – vulnerable third-party components; – weak cryptography or unencrypted communications |
4. Choose a deployment model
The vulnerability scanning market includes both traditional on-premises products and increasingly common vendor-hosted services.
The most suitable deployment model depends on how well it integrates with the organisation’s infrastructure and whether it satisfies applicable security requirements and restrictions.
On-premises solutions
With an on-premises deployment, the organisation hosts and operates the vulnerability scanning product within its own infrastructure.
For example, the scanner may be deployed on a virtual machine (VM) or installed on a dedicated physical appliance within a data center.
This deployment model makes scanning parts of the network without external connectivity considerably easier. Vulnerability data also remains stored locally, giving the organisation direct control over where sensitive information about security weaknesses is retained.
However, this additional administrative control also creates additional operational responsibilities.
On-premises scanners require initial deployment and configuration. They also require continuous maintenance to ensure the platform and its vulnerability information remain current.
On-premises systems may also have difficulty scaling quickly when demand increases. This may become particularly relevant when large sections of an IT environment need to be scanned simultaneously.
Supporting such peaks may require maintaining additional infrastructure capacity that remains unused for much of the time.
This limitation is not unique to vulnerability scanners. It applies to on-premises infrastructure hosting more generally.
On-premises scanning solutions are therefore particularly appropriate for systems that cannot be easily reached from the Internet or for organisations that already maintain suitable internal hosting infrastructure.
Vendor-hosted solutions
Many vulnerability scanning products are also available as externally hosted services. In this model, the scanning software remains within infrastructure controlled and maintained by the vendor.
This deployment approach is commonly referred to as Software as a Service, or SaaS.
SaaS vulnerability scanning can provide a cost-effective way to address many of the operational limitations associated with on-premises products. However, it introduces different technical and security considerations.
Because the scanning platform is hosted externally, it cannot easily reach internal networks located behind organisational firewalls and routers.
One way to address this limitation is to deploy agents inside the internal network. These agents can establish outbound connections to the vendor’s infrastructure and receive scanning instructions.
Another option is to reconfigure firewalls so that connections from known external scanners are permitted.
Either approach requires some initial configuration by network administrators. The complexity of that configuration will depend on the architecture of the organisation’s IT environment.
Any network modifications introduced to enable external scanning can also increase organisational risk. A degree of trust must be placed in the vulnerability scanning provider.
This trust relationship should be formally documented and incorporated into the organisation’s security model.
Advantages of SaaS
Despite these considerations, SaaS scanning solutions provide several important advantages over on-premises platforms.
Because no local scanning product or appliance has to be maintained, routine maintenance tasks are reduced. Examples include applying patches to the scanner itself and updating an internally hosted vulnerability knowledge base.
SaaS platforms can also usually scale their resources in response to changing demand without requiring the organisation to permanently maintain unused infrastructure capacity.
Hosting scan findings within the vendor’s platform can additionally simplify the task of making vulnerability information available to authorised users while protecting it from unauthorised access. This benefit depends on the organisation accepting and trusting the vendor’s security controls.
A hosted vulnerability scanning service is generally suitable where the technical and security challenges associated with granting access to organisational systems can be satisfactorily addressed. The organisation must also be comfortable with vulnerability information being stored by the provider.
This model is unlikely to be suitable for an air-gapped network or an environment that contains highly sensitive information.
5. Decide which assets to scan and when
Scanning a larger proportion of the IT environment provides more complete visibility into organisational risk. However, scanning every asset may not always be practical or financially feasible.
Where full coverage is not possible, priority should be given to assets that are exposed to the Internet, provide business-critical services, or contain particularly sensitive information, such as database servers.
Any assets excluded from vulnerability scanning should be formally recorded. This allows the resulting gaps and associated risks to be reflected in the organisation’s broader security model.
Extrapolating tests
Some organisations deploy multiple hosts from a standardised “golden image.” If that image guarantees an identical configuration across all hosts and no subsequent changes have been introduced, it may be acceptable to scan one representative host and apply the findings to the remaining systems created from the same image.
Vulnerability scanning tools are generally unlikely to disrupt services or affect their availability. Nevertheless, non-production instances may be scanned first when dealing with servers that provide business-critical services.
Results from such testing can only be considered applicable to the live environment when the production and non-production systems have equivalent configurations.
Production systems should still be scanned when their configurations differ. Production scanning should also be performed after testing has confirmed that the scan did not affect the availability of equivalent non-production systems.
In situations where no representative non-production environment exists and certain business-critical systems are considered unusually fragile, those systems may temporarily be excluded from potentially disruptive scans. Any such exclusion should be documented in the organisation’s risk register.
This approach must be used carefully and for the shortest possible period. Excluding systems from scanning creates blind spots within the attack surface.
A more effective long-term approach is to address the underlying reasons for the fragility so that the affected systems can be scanned safely.
System fragility should itself be treated as a vulnerability and remediated promptly.
Scan regularly
Infrastructure vulnerability scanning should be carried out on a regular basis, at least once per month.
An additional scan should be performed immediately after changes have been introduced to remediate a critical vulnerability.
Application scanners should be run whenever the target application changes. Relevant events include the installation of a new application version or the commitment of changes to the source code of a custom-developed application.
Where possible, application security scanning should also be incorporated directly into the software development process as part of a secure build and deployment pipeline.
Additional considerations
Several additional factors should be evaluated when determining whether a vulnerability scanning product or service is suitable for a particular organisation.
It is not always possible to define a universal threshold for what represents “good” or “bad” performance in every area. Nevertheless, the following criteria should be included when assessing prospective vendors and comparing available solutions:
Responsiveness:
How quickly can the platform begin detecting a newly disclosed vulnerability? For critical vulnerabilities, support should normally become available within no more than a few days after public disclosure.
Coverage:
Does the scanner support the vulnerability categories relevant to the organisation? For a web application scanner, for example, consideration should be given to whether it detects the security risks included in the OWASP Top 10.
Authentication support:
Can the scanner perform authenticated assessments? For example, can it authenticate to Windows systems and perform checks that are unavailable to an unauthenticated scanner? Does it support only agent-based local authentication, or can it also authenticate remotely? Are safeguards available to reduce the risk of locking user or service accounts?
Accuracy:
How frequently does the scanner generate false positives, where a vulnerability is reported even though it is not present? How effectively does it avoid false negatives, where an existing vulnerability is not detected? Examples of accuracy problems include incorrectly identifying an outdated software version or reporting a missing patch that has already been installed.
Reliability:
Is the scanning platform consistently available for both scheduled scans and manually initiated, on-demand assessments?
Scalability:
Can scanning performance be maintained when demand increases? Does the pricing model reflect the capacity actually required at a given time?
Reporting capabilities:
Can reports be customised for specific organisational requirements? Do they contain the information and metrics required by security and administration teams?
Support for other areas of a VMP:
Can the scanning platform integrate effectively with existing products and processes? Alternatively, does it provide functions beyond vulnerability detection that can strengthen the existing VMP, such as built-in issue tracking?
Integration with other operating system components:
Can the scanner generate additional value by using software that is already installed on target systems? For example, can it integrate with Microsoft System Center on Windows systems to provide more intelligent patch management capabilities?
Support for different types of assets:
Does the platform support specialised asset types such as virtual machines, containers, or dedicated database servers?
Integration with cloud environments:
Can the scanner connect to widely used cloud platforms to automatically discover and scan additional assets deployed within those environments?
Safety:
Does the vendor guarantee that vulnerability scanning will not disrupt the availability of the target systems or services? If such a guarantee is not provided, can potentially disruptive checks be disabled or excluded from scans?
