What is vulnerability scanning, and how does it work?

Vulnerabilities are code bugs that can be exploited and lead to security breaches. For that reason, regular vulnerability scanning is one of the most critical processes that organizations should implement as a part of their CI/CD process to protect themselves from cybersecurity risks.

That said, vulnerability scanning has its limitations, and is only one pillar of modern cybersecurity best practices. For guidance on understanding where vulnerability scanning fits in alongside other security strategies, keep reading as we unpack everything you need to know about how vulnerability scanning works, popular vulnerability scanning tools, how scanners relate to CVEs and malware, and more.

What is vulnerability scanning?

In cybersecurity, vulnerability scanning is the process of checking software for security flaws and exploitable bugs – particularly those that have received a designation under the Common Vulnerability Enumeration (CVE) system, a widely used framework for publicly registering known security vulnerabilities.

Typically, vulnerability scanning involves using an automated tool to parse the contents of an application and flag any code or dependencies known to be vulnerable to attack. In this way, vulnerability scanning helps teams detect security risks within their applications prior to deploying them into production environments. By extension, it gives them an opportunity to remediate vulnerabilities – which usually entails applying a software patch or updating to a newer software version – before threat actors can exploit them.

What are vulnerability scanners?

Vulnerability scanners are software designed to identify vulnerabilities within software. Typically, they work by analyzing application code and comparing it to a known list of vulnerabilities recorded in public databases – such as the National Vulnerability Database (NVD), a repository of vulnerability information maintained by the U.S. federal government. Scanners can also identify vulnerabilities based on security advisories.

Scanners then generate reports that list the vulnerabilities identified and severity ratings to provide an indication of how much risk each vulnerability poses. Vulnerability scores are usually based on the Common Vulnerability Scoring System (CVSS) system, which assigns numerical values to vulnerabilities based on how much risk they pose. Scanners may also offer remediation guidance, which developers can use to determine how to fix a vulnerability.

How does vulnerability scanning work?

Vulnerability scanning usually works based on the following steps:

1. Developers or security analysts determine which software they want to scan for vulnerabilities. They can scan internal code that the organization has developed itself, as well as any third-party components within the organization’s software supply chain.

2. The team deploys a vulnerability scanner and configures it to scan the software. Sometimes, organizations use multiple types of scanners to address different types of vulnerabilities; for instance, they might use Static Application Security Testing (SAST) scanners to check for vulnerabilities in internal code and Software Composition Analysis (SCA) tools to identify vulnerable third-party components.

3. The scanning tools automatically analyze the software in the form of source code and/or binaries and generate reports that list likely vulnerabilities.

4. The team addresses the vulnerabilities (or at least, those it deems risky enough to address), typically by installing an upstream patch or, if one is not available, implementing a new patch from scratch. It then scans again to confirm that they have been properly mitigated.

Vulnerability scanning can take place on a one-off basis. However, to streamline the vulnerability detection and mitigation process, it’s a best practice to integrate vulnerability scans into Continuous Integration/Continuous Delivery (CI/CD) pipelines. This allows scans to occur automatically and continuously as an integral part of the software development process. This way, vulnerabilities are caught before code is deployed into production. 

The limitations of vulnerability scans

Vulnerability scanning is an effective and efficient means of identifying the many types of security risks that impact applications. However, the practice has clear limitations, and understanding what vulnerability scanners don’t do well is important for determining which risks may exist within applications even if they appear secure based on vulnerability scan reports.

Reliance on CVEs

One major limitation is that vulnerability scanners only report “known” vulnerabilities, meaning those that have been publicly reported and received a Common Vulnerabilities and Exposures (CVE) number. They don’t typically discover unknown vulnerabilities, especially zero-day vulnerabilities, which likely exist within code without being tracked in public CVE databases.

False positives and negatives

Vulnerability scanners sometimes report false positives, meaning they identify vulnerabilities that don’t actually exist. They may also be subject to false negatives, or instances where they fail to catch an actual vulnerability. Both of these issues mean that teams must review vulnerability scanning reports carefully, rather than taking them at face value as a comprehensive listing of all issues that do or don’t exist within an application.

Lack of context

Some vulnerabilities are only exploitable under certain configurations, but vulnerability scanners often lack the ability to understand this context. As a result, they may flag risks that aren’t actually applicable to a given application or environment.

Similarly, vulnerability reports that include severity ratings typically base those ratings on the severity indications found in public CVE databases, rather than by assessing how much risk each vulnerability poses within a specific application environment. This can lead to situations where vulnerabilities receive high-severity ratings when they do not actually pose a risk under the configuration that an organization has in place – or, even worse, it may cause scanners to identify some risks as low priority when in fact they are more serious for a particular environment.

Solutions like VEX can help mitigate this issue by providing context-aware guidance for interpreting vulnerabilities, but this doesn’t work with every type of vulnerability.

Vulnerability volume

A single vulnerability scan can generate dozens or even hundreds of potential security risks. Indeed, the average enterprise has 476 “critical” known vulnerabilities in its systems at any given time – and that’s only counting the severe risks.

The high volume of vulnerabilities can make it challenging for teams to react to vulnerability scanning reports effectively. If engineers are inundated with vulnerability alerts, alert fatigue may set in, causing them to ignore scanner alerts – including critical issues. To mitigate this challenge, teams should strive to reduce the total volume of alerts, as well as false positives. Including accurate, context-aware severity assessments and remediation guidance in vulnerability reports also helps because it allows engineers to triage and remediate vulnerabilities more efficiently.

Conquering vulnerabilities with Chainguard

You don’t have to spend all your engineering hours identifying, triaging, and patching vulnerabilities. Instead, you can build and deploy applications based on containers that are secure and hardened from the start.

This is where Chainguard comes in. By providing minimal, zero-CVE container images, Chainguard offers a secure foundation for developers to leverage when deploying cloud-based applications. Learn more by reading about Chainguard’s secure container images.