The Case of Disappearing Vulnerabilities

This blog is inspired by a recent customer conversation that went like this:

Customer: We are moving our software to AWS lambda.

ShiftLeft: How are you thinking about security?

Customer: We have been using a WAF for our on-prem installation. We use a vulnerability scanner like Nessus and its findings to inform WAF of the vulnerabilities to make detection more accurate. We plan to continue doing the same.

This should not come as a surprise because identifying vulnerabilities using scanners and enabling signatures in next generation firewall (NGFW) and Intrusion Detection and Prevention Systems (IDS/IPS), and correlating with Web Application Firewall (WAF) alerts is common-sense and best practice.

But, does this approach make sense for software that is deployed in the cloud? The short answer is no, it does not!

Sampling of Vulnerabilities by Vendor

Here is some data from CVEDetails.com, a resource for searching vulnerabilities across independent software vendors (ISVs) and their products:

Have cloud software vendors have figured out how to write software without vulnerabilities?

Let’s look at the results of another search:

What stands out is that it’s not the vendor but the cloud-hosted software that makes the difference. And, given that it’s the same vendor and engineering teams, one has to conclude that the cloud-hosted software has vulnerabilities that are not part of the public database of vulnerabilities. Why? Because vulnerabilities of a custom SaaS application will not show up in vulnerability databases, for reasons I discuss below.

Packaged Software

In the packaged software world, vulnerabilities become part of the National Vulnerability Database (NVD), or a similar database of vulnerabilities (such as the Common Vulnerabilities and Exposures), for one or more of the following reasons:

1. The ISV mentions in the release notes that they have fixed a vulnerability in the latest version, meaning the vulnerability exists in versions prior to the latest one.
2. The ISV acknowledges certain vulnerabilities in the release notes.
3. Customers or security companies find vulnerabilities in the application by using penetration testing tools like metasploit, fuzzing, etc.
4. Abnormal behavior is identified in the use of the application and is reported both to the vendor and publicly (based on the vendor’s policies).
5. For open-source software (OSS), because the source code is available, vulnerabilities can also be found using code analysis and added to one of the vulnerability databases.

Software as a Service

In the SaaS world, both the software and the application developed by the SaaS vendor never leave that vendor. Only the SaaS vendor can identify vulnerabilities, and it has no incentive to make them a part of a publicly available vulnerability database. The only ways that vulnerabilities in a SaaS applications can become public are as follows:

1. Abnormal behavior is identified in the use of the application and is reported both to the vendor and publicly (based on the vendor’s policies).
2. Bug bounty programs are established by the ISF to encourage third-party security professionals to proactively identify vulnerabilities during blackbox testing. In this case tools such as interception proxies are employed to help identify shallow vulnerabilities.
3. The vulnerability exists in OSS that the SaaS vendor has leveraged, for example, a vulnerable version of an OpenSSL library. Here there is some recourse to the extent that tooling can be used to identify OSS being used in the application and identify the list of vulnerabilities in the OSS. But this approach is limited because: it assumes that the application exposes all OSS it is using via port scan; it fails to identify whether the application is using the vulnerable portion of OSS; and it does not identify contextual vulnerabilities in the use of OSS.

In sum, the reason software vulnerabilities disappear from public vulnerability databases for SaaS applications is that the software never leaves the SaaS vendor. The SaaS vendor is responsible for hosting the application in production and therefore retains the responsibility for fixing its vulnerabilities. Since the software never leaves the SaaS vendor, cloud-hosted software is not exposed to the same level of third-party analysis as packaged software.

Security Strategy for Packaged Software

In an on-prem data center, the customer (owner of the data center) is responsible for protecting the network, the operating system and the applications. The data center is scanned by vulnerability scanners like Nessus that scan the applications (and the network elements like routers, switches, and operating systems) to determine the software version. Once identified, they then match the vulnerabilities in a vulnerability database to identify the list of vulnerabilities across the applications, operating systems, routers, etc. in use in the data center. This helps customers prioritize patching and configure protection through tools like NGFW, IDS/IPS, and WAF by turning on specific vulnerability based signatures (or attack-based signatures that target the vulnerability). The vulnerability scanners work by conducting an active scan of the open ports, by passive scanning of the network traffic, or by installing an agent on the host. For a data center, this is a very logical strategy.

A New Security Strategy Is Needed for SaaS Apps

A SaaS application is typically deployed in a public cloud using infrastructure and platform providers (IaaS/PaaS). Such infrastructure is not available to be scanned for vulnerabilities from the public internet. And, as we have seen, there is little merit in running a scan of SaaS applications since public vulnerability databases have little-to-no SaaS vulnerabilities!

This has broad implications:

1. Publicly-available vulnerability databases (CVE/NVD) are largely irrelevant for SaaS applications and infrastructure.
2. As a result, correlating vulnerability scans with WAF is meaningless.
3. Further, vulnerability-based signatures — a key use case for NGFW and IDS/IPS — do not apply to SaaS applications and infrastructure.

Where Do We Go from Here? Let’s ShiftLeft

The basic premise of identifying vulnerabilities in the application and correlating that information with runtime protection tools is fundamentally sound. But for SaaS applications, the only prudent way to identify vulnerabilities is to conduct next-generation code analysis — code analysis that is fast (in the order of seconds), identifies issues across all application components, including OSS and third-party libraries, and identifies all use of sensitive data.

Instead of just copying the legacy security strategy and correlating the results of code analysis with an off-the-shelf security solution (like NGFW, IDS/IPS, WAF), we can do better. The ShiftLeft solution extracts the Security DNA of each version of each application every time it changes using next-generation code analysis techniques. The Security DNA is then used to create policy for the ShiftLeft Microagent that protects the specific version of the specific application against attack in a production environment. This eliminates the overhead of generic off-the-shelf security solutions that have attack-based signatures for hundreds of applications, operating systems and network elements. With ShiftLeft, correlation between code vulnerabilities and runtime protection is automated with no human intervention required. The ShiftLeft solution offers a security solution for SaaS software that is agile, accurate, and high-performant — how security was meant to be.

To get started with ShiftLeft, sign up at https://www.shiftleft.io and try our Quickstart tutorial where you can use ShiftLeft to analyze a sample app.