Vulnerability Scanning

Vulnerability scanning is the finding of security flaws and vulnerabilities, analyzing them and reporting on them.  Vulnerability scanning tools discover vulnerabilities during the SDLC, they also scan hardware, software, networks and other systems.

Vulnerabilities continue to grow as organizations turn to digital transformation and roll out new applications and enhance existing ones. Identifying and then triaging, diagnosing, and remediating these application vulnerabilities is time-consuming and costly. Organizations using waterfall development processes where releases occurred a few times a year, if that, relied on penetration testing to identify application vulnerabilities at the development cycle. But as organizations have embraced faster and more frequent development cycles, penetration testing has become a greater challenge. As a result, more and more organizations have adopted application security testing (AST) either in place of or as a complement to penetration testing.

Types of vulnerability scanning

Depending on the stage in application development and nature of the application, organizations will employ vulnerability scanning to point out the highest risk factors. While some applications may benefit from the use of one or the other, it is best to combine scans for a truculent approach. The two main categories of scans are:

Unauthenticated vulnerability scan

Access is limited with an unauthenticated scan. While some vulnerabilities are identified, it provides only an outside view of potential threats and weaknesses. One advantage is that it mimics the level of access most often uncovered by hackers, showing whether or not there are any threats to applications at this level. While this may be okay for minor threats, it is not enough to battle and prepare for all potential threats.

Authenticated vulnerability scan

Access to core code and infrastructure is granted when proper credentials are entered. This type of scan provides a more complex look into threats of all types, including cross-site scripting (XSS) that allows for the injection of client-side scripts. Because this type of scan grants intimate access, security teams can take a more forceful approach to the detection of potential threats.

With these levels of access, it is also helpful to perform external and internal scans that take a look at a wider spectrum of issues, including IT ecosystems and the internal corporate network. A more in-depth scan, the environmental scan, takes a look at the operating environment of applications. This is especially useful today with developers turning to cloud-based applications that support complex application infrastructures. Once a vulnerability is identified by a vulnerability scan, the security team must still spend considerable time triaging, diagnosing, and remediating it.

Vulnerability scanning and remediation steps

The first step to a vulnerability scan is to run the scan itself. This often requires specialized application security resources—either on staff or via an outsourced provider. Once the scan is complete, those same application security staff must triage and diagnose the findings that are typically generated in a PDF format. The team of specialized application security staff must manually determine which ones are true vulnerabilities versus false alerts. This can consume significant time and is a task sometimes pushed to developers. When that occurs, developers are prone to becoming overwhelmed with alert fatigue and may simply ignore many of the possible vulnerabilities included in the reports.

Assuming the possible vulnerabilities are triaged and diagnosed as true vulnerabilities, the development team is assigned to trace down the cause and to remediate the problem—which can be a time-consuming exercise. At the same time as fixing the vulnerability, developers must also ensure no additional bugs or vulnerabilities are introduced into the application.

Vulnerability scanning challenges  

As noted, detecting vulnerabilities is only one small part of the bigger picture when it comes to application security. Development teams must still expend a lot of work after an application vulnerability is found. There are a number of reasons this is the case. One is the fact that not every vulnerability is the same and moreover poses the same risk. But unless a security team has a risk rating or scoring system in place such as the Common Vulnerability Scoring System (CVSS), it is difficult for security and development teams to evaluate the risk of a vulnerability. They end up trying to remediate all vulnerabilities at the same time, which is next to impossible considering the number of potential vulnerability alerts they receive.

Another factor that drives up the amount of time are false positives. Legacy application security relies on point-in-time scans and uses signature-based engines. This produces large piles of false positives—vulnerabilities that pose no risk because they will never be exercised by the application in question.

Regular vulnerability scanning for preventative security

Remediating vulnerabilities before code is released into production is critical. It costs significantly more to manage vulnerabilities found in production runtime. Application security scanning aims to shift vulnerability management left into the initial stages of the software development life cycle (SDLC). As vulnerabilities are immensely easier and faster to remediate in application development, fixing them as early as possible during the SDLC is ideal. Regardless, as new vulnerabilities are found after code is released into production, organizations must also run security scans on applications in production. This is particularly important due to the fact that, as the average dwell time increases, so does the risk of that vulnerability being successfully exploited. Vulnerability scanning inspects applications for potential vulnerabilities and flags them in PDF reports for triage and diagnosis. These scans pinpoint potential entry points and bugs or vulnerabilities in code from infrastructure to the application front-end user interface.

Unlike penetration testing, which occurs right before code is released into production, vulnerability scans shift security left. Yet, vulnerability scanning remains an outside-in undertaking, whereby vulnerability management takes place outside of the software. It also provides point-in-time views of application code and cannot provide continuous analysis of the application in runtime.

Vulnerability scanning: SAST vs. DAST

Vulnerability scanning provides security teams with a more comprehensive look at their application risk posture and gives them a more proactive application security approach. When it comes to website vulnerability scanning, there are several different approaches available. 

Static application security testing (SAST) takes a look at the architecture of an application. In order to scan for vulnerabilities, SAST requires access to source code. However, as noted above, SAST encounters challenges such as the need to hire application security experts with specialized skills to manage the scans and then the triage and diagnosis of the results and the large piles of false positives scanning produces. This delays development cycles while ratcheting up time and cost expenditures. Analyzing source code, SAST struggles to analyze application programming interfaces (APIs).

Dynamic application security testing (DAST) analyzes applications from the outside, attempting to capture the same view as potential hackers. This black-box approach to application security testing searches source code for potential vulnerabilities and flags them. However, while DAST is less prone to generating false positives, it still struggles on this front. In addition, because DAST tools rely on predetermined signatures, they miss vulnerabilities (false negatives) that can pose serious risk. And like SAST, DAST also has challenges in analyzing APIs for vulnerabilities

Growth in open source complicates vulnerability scanning

Use of open-source software frameworks and libraries is proving to be a critical enabler of digital transformation. As much as 90% of software is built from open-source code today. There are indubitable advantages: Developers are able to produce more code and release code faster than ever before. This growth in open-source code increases the challenges of website vulnerability scanning. The complexity of open source is an important starting point. For a top-tier open-source library to deliver on its functionality, it must call on directly dependent libraries. These may be linked to transitive dependent libraries, which results in a dependency-of-dependencies issue.

It should be a huge surprise that a majority of applications have an open-source vulnerability, and nearly half of them are transitive. Without an accurate inventory of software dependencies used by different applications, organizations face serious open-source risks. In particular, because software composition analysis (SCA) tools rely on legacy application scanning that generates significant false positives, detecting and remediating these vulnerabilities in open source is time-consuming and costly. Licensing requirements for open source is also a problem, as scanning tools lack the visibility needed to identify them.

Vulnerability management that enables digital transformation

Vulnerability management that uses instrumentation to place security within the applications is proven to be effective and efficient. Developers are able to detect vulnerabilities while they write code. They no longer need to become application security experts to triage, diagnose, and remediate vulnerabilities. And because much of the workflow is automated and the risk rating of detected vulnerabilities is provided, vulnerability management is no longer guesswork but rather remediation that can be prioritized based on risk. Instead, developers are able to find and fix vulnerabilities and return to writing code and release applications in production runtime quickly and easily.

Security instrumentation also extends protection from development through production. Application attacks on vulnerabilities are blocked in virtual real time, as security runs within the software and identifies attacks when they happen.