Vulnerability Scanning Process: An In-Depth Look

What is Vulnerability Scanning?

Vulnerability scanning is an automated process that identifies security weaknesses in networks, applications, and computing infrastructure. It is a central part of vulnerability management strategies.

Vulnerability scanning may be performed by automated tools, by third party providers, or manually as part of in-depth penetration testing. 

Vulnerability scans are an attempt both to detect and to identify security vulnerabilities. Once a vulnerability is detected, security risk information can be associated with the detected vulnerability, such as their severity, exploit availability, attack vector information, and remediation guidance. 

To do this, vulnerability scanners reference one or more vulnerability databases, comparing information found in the scan to known vulnerabilities, coding flaws, network communication anomalies, and unsecure configurations that can be exploited by attackers.

In this article, you will learn:

• SAST vs SCA: Two Approaches to Software Vulnerability Scanning
• 4 Stages of the Vulnerability Management Process
• How Often Should You Perform Vulnerability Scanning?
• Cloud Native Vulnerability Scanning with Aqua Security

SAST vs SCA: Two Approaches to Software Vulnerability Scanning

In large enterprises, two technologies are commonly used to perform software vulnerability scanning:

• SAST—an application security testing technology that works by scanning source code for code quality issues. It produces a report of weaknesses found in the code and how to remediate them. These weaknesses are often identified by their Common Weakness Enumeration (CWE).
• SCA—a newer technology that addresses risks in open source components . It scans applications and prepares a bill of materials (BOM) of all open source components. Using metadata and other attributes, it analyzes each component’s vulnerabilities and associated software licensing, and reports on issues that could affect the organization.

There are a few key differences in how SAST and SCA tools identify vulnerabilities:

• SAST can be used to scan proprietary code, while SCA mainly focuses on open source components within an application.
• SAST scans source code directly, while SCA relies on metadata and package structure
• SAST requires access to source code, while SCA is, traditionally, less intrusive
• SAST typically has a higher false positive rate. SCA can drastically minimize the number of false positives by relying on information about open source components included in build processes and library metadata.
• SAST tools are limited to the development and testing phases of the software development lifecycle (SDLC), while SCA can also scan software during and after the software build process, and as software is sent into code repositories, container registries, or staging and production environments.

4 Stages of the Vulnerability Management Process

The vulnerability management process includes the following stages:

1. Detecting and Identifying Vulnerabilities
2. Scoring and Prioritizing Vulnerabilities
3. Remediating Vulnerabilities
4. Vulnerability Risk Reporting

Detecting and Identifying Vulnerabilities

Vulnerability scanners are the primary method employed to evaluate the security risk posture of the analyzed technical assets. To achieve accurate results, a vulnerability scanner requires the following capabilities:

• Assessment—the scanner works to find and identify information about devices, open ports, software assets, and systems.
• Correlation—the scanner correlates the collected data with information about known vulnerabilities, which is typically pulled from vulnerability databases or supplied by a security solution vendor.

Often, vulnerability scanning can be accomplished with greater efficiency and improved results for mitigating security risks by taking some additional steps, including:

• Schedule vulnerability scans —scheduling scans outside of business hours can help  avoid disruptions to operations and prepare results for review and reporting for the next day’s issue management activities.
• Use adaptive vulnerability scanning—depending on which assets are being scanned, it is possible to detect changes as they occur, such as network changes, newly connected endpoints, or new software artifacts moving through development and deployment processes.

Scoring and Prioritizing Vulnerabilities

Once vulnerabilities have been identified, they should be evaluated in order to address the risks to the organization. Software vulnerability management solutions provide risk assessments and vulnerability scoring, typically based on the Common Vulnerability Scoring System (CVSS). 

CVSS scores reflect the severity of a vulnerability, but they don’t tell you which vulnerabilities your organization should focus on first. To prioritize vulnerabilities, you should take into account additional factors, such as:

• Confirmation—whether the vulnerability is confirmed, or possibly a false positive
• Public networks—whether the affected system is exposed to public networks
• Ease of exploitation—the level of sophistication or skill needed to exploit the vulnerability, and availability of public exploit code for the vulnerability (making it accessible to a large number of threat actors)
• Business impact—what would be the impact on the organization if the vulnerability were exploited. For example, a severe vulnerability in a non-mission-critical system could be considered less impactful.
• Existing security controls—whether the vulnerability is addressed by existing security systems. For example, a web application firewall may prevent exploitation of many vulnerabilities without remediation of the underlying code.
• Age—the time since the vulnerability was introduced is significant. Long-lived vulnerabilities have a greater chance of having associated exploits or may have been incorporated into a larger number of assets and locations. These need to be handled more urgently.

Many automated vulnerability scanning tools help prioritize vulnerabilities, but their recommendations are not perfect. These prioritization recommendations should be paired with internal standards for risk tolerance and any custom severity preferences. For additional testing validation, full penetration testing by a skilled, ethical hacker or security services provider can be used. Penetration testing typically combines automated vulnerability scanning with manual exploration and testing via additional, customized tools.

Remediating Vulnerabilities

Once a vulnerability has been identified, the next step is determining how to address the vulnerability. There are three ways to address a vulnerability:

• Remediate—repair or patch the system or software affected by the vulnerability to prevent it from being exploited.
• Mitigation—in cases where it is difficult or infeasible to remediate the vulnerability, the organization can still take action to avoid its exploitation. For example, adding security controls that can prevent an exploit, isolating the affected system from the network, or implementing a workaround.
• Acceptance—not taking any action to address the vulnerability. While it is dangerous to avoid addressing known vulnerabilities, in a modern IT environment with a large number of constantly changing infrastructure and software components, such a choice may be unavoidable, at least temporarily. This strategy should only be selected for vulnerabilities that are not expected to have a major business impact, or where the potential damage is smaller than the cost of remediation, for example.

Most scanning solutions provide recommended remediation techniques for the vulnerabilities they uncover. Some tools can also automatically patch affected systems. 

However, recommendations and fixes from automated tools are not always the optimal way to resolve a vulnerability. High priority vulnerabilities should be evaluated by the security team, system owners, and operations staff, to determine the most effective solution in terms of cost, impact to users and productivity, and long-term maintenance. The remediation or patch options should then be tested to ensure the change does not adversely impact the performance of the system or software to which it is applied.

After remediation of vulnerabilities, a scan should be re-run to confirm that the vulnerabilities are fully resolved.

Vulnerability Risk Reporting

Finally, the vulnerability scanning tool will generate a report that summarizes the vulnerabilities discovered, the risks facing the organization, and next steps. For each vulnerability, the tool will typically report on its name, date of discovery, severity/CVSS score, details on the vulnerability from CVE databases or other sources, and recommended fixes.

Organizations should not take vulnerability scanning reports at face value. They should analyze them to highlight systems or software that are high in risk. These are the areas where future remediation efforts should be focused. It is also important to analyze vulnerabilities over time—while an asset may be free of vulnerabilities at the time of the scan, new vulnerabilities are discovered each day (more than 14,000 CVEs were published in 2019 alone, for example). 

Because the rate of vulnerability growth often outpaces the rate of remediation, common success metrics and security risk reporting techniques are based on how much net progress is made at decreasing the number of open vulnerabilities, as well as accelerating time to remediation.

How Often Should You Perform Vulnerability Scanning?

The frequency of vulnerability scanning depends on a number of factors, including the frequency of changes to IT systems, software releases or code changes, compliance standards, and security program goals. When operating in a cloud native environment, the need for frequent vulnerability scans is exponentially greater.

Vulnerability scans must be an integral part of the organization’s information security program. After any change to infrastructure, software, or operational systems, vulnerability scans should be performed to identify and remediate security vulnerabilities. Vulnerability scans should be an integral part of the build process for software development teams, and part of the continuous integration (CI) and continuous deployment (CD) process for those using DevOps methodologies for software creation. 

In addition to scans triggered by changes or new developments, the organization should plan a broad vulnerability scan of all systems and assets once per month, per quarter, or per year, as dictated by compliance requirements.

Related content: learn about free tools that can help you get started with vulnerability scanning, in our guide to open source vulnerability scanning ›

Cloud Native Vulnerability Scanning with Aqua Security

Aqua Security enables Security, Engineering, and DevOps teams with vulnerability scanning solutions for cloud native software assets, including containers, functions, Infrastructure-as-Code (IaC) templates, and VMs. Aqua’s vulnerability scanner examines cloud native artifacts for vulnerabilities and provides detailed security risk insight and remediation guidance – sourced and curated by Aqua’s dedicated cybersecurity research group Team Nautilus.

The results of Aqua’s vulnerability scans are prioritized based on contextual risk factors for faster triage, and can be integrated throughout CI/CD pipelines to empower teams with actionable insight directly in the tools they use as part of established DevOps workflows.

Learn more about Aqua’s solutions for vulnerability scanning ›, or Trivy, Aqua’s open source vulnerability scanner ›