SAST and SCA Complemented with Dynamic Observability for CVE Prioritization

Over the past years, the adoption of Agile and DevOps grew, and together with it, we have also observed the rise of DevSecOps. Such practice recommends shifting left security testing and remediation of security vulnerabilities as early as possible within the SDLC. While the idea is great, and we’ve seen the rise of many types of security testing tools, for developers that are no security experts, finding the needle in a haystack white using such tools is a challenge and a delay to the overall release cycle.

The tool stack that is available today for developers and security engineers to run security tests consists of SAST, DAST, and SCA, and while these are powerful tools and mostly automated, they have their limitations when it comes to flooding the developers with a lot of security issues, false positives, and other noise.

In this article, I’ll provide a brief overview of the SAST and SCA tools for better and worse, and suggest using the Dynamic Observability approach as part of the overall CVE prioritization and noise reduction from the developer's pipeline.

To gain some context to this article, I would like to bring a reminder of one of the most famous and most dangerous security vulnerabilities in the past years. The Log4Shell vulnerability found in the popular Log4j Java logging utility was deemed by the Department of Homeland Security as “one of the most critical software vulnerabilities in history”. The thing about this vulnerability was that while it was a very risky issue, it did not necessarily impact all applications that were using the library, since such vulnerability was not exposed in the runtime path of all applications.

Static Application Security Testing

SAST is a testing methodology that analyzes the source code of a software application to identify potential security vulnerabilities before the application is deployed, and in many cases it’s also referred to as part of white-box testing. 

The code scanning is done automatically for common security issues identifications, and it uses security profiles based on rules, languages, and other standards to ensure that coverage is appropriate and up to date., Among key things that are being scanned for, you’ll find things like input validation weaknesses, buffer overflows, and SQL injection attacks.

If you look at a sample output from one of the commercial SAST tools in the marketplace (in our case, Codacy), you can observe over a hundred security violations that a developer would get upon a SAST execution. Such execution can happen upon each new code commit or other triggers, and that generates a lot of pressure on developers.  

From a developer perspective, the above report triggers quite a tedious workflow of reviewing at first the high-priority classified issues, analyzing them, and, where required, applying a fix and re-deploy. This is a continuous lengthy process where the developer does not have, in many cases, the relevant information on whether a security issue is even impacting the application runtime paths or not. 

With that in mind, keep in mind that the SAST scanning process only runs on the proprietary source code of your application, and does not cover the third-party libraries' source code. From historical experience and the abovementioned log4J incident, many of the security issues are attributed to 3rd party codes. This means that even after running the SAST and hopefully remediating the issues, the portions of the code that leverages third-party open-source code are not yet covered. For that portion, developers ought to use SCA tools.

Software Composition Analysis

Software Composition Analysis (SCA) is an application security methodology for managing open-source components in software development. This process allows development teams to easily track and analyze all open-source components that are brought into a project. The goal of SCA is to minimize security risks that could potentially harm the project by identifying any vulnerabilities and potential exploits in third-party libraries. In the below comparison table that was created by GitHub, we can clearly see how SCA and SAST complement each other and maximize the code coverage security analysis. We can also learn about the pitfalls of both; false negatives and positives, which translates into more noise for developers.

In a nutshell, SCA tools run on the open-source and third-party libraries within the application under test and create a Software Bill of Materials (SBOM) that contains all the third-party libraries used in the application.

Upon an SCA code scan completion, such tools generate a comparison of findings against a public list of known vulnerabilities (CVEs) to identify any that could potentially impact the code. 

As highlighted in the above SAST example from CODACY, below is a different example from an SCA scan output provided by CAST. 

Here as well, developers receive a large list of findings that, while classified by severity, do not have the context and prioritization based on the actual application as it is being used in runtime.

The outcome of both SAST and SCA tools from a developer standpoint is that they are overwhelmed by the scale of security flags that the tools reflect, and they don’t have a quick and easy way to prioritize all these issues in a way that does not impact the software delivery velocity. To proactively remediate the “RIGHT” security issues, developers need a way to determine if a relevant class is loaded, if the codepath is invoked, and more application-specific information.

Dynamic Observability: Benefiting From SCA and SAST Toward Better DevSecOps Workflow?

As mentioned earlier, developers must get a “filter” for all security noise that traditional tools expose within their dashboards and within the CI/CD pipelines. For that purpose, there is a great methodology called Dynamic Observability that enables developers to troubleshoot live applications directly from their IDEs – on demand, in real-time, and regardless of where the application is deployed.

When executing SAST and SCA to obtain SBOM of CVEs, you can leverage such a modern method to easily determine at runtime whether a flagged vulnerability like the log4J, or a more recent issue within the Python libraries has an actual impact on your application. In addition, you can also determine specifically the impact of such vulnerability on a segment of your users or customers, and remediate it effectively.

Such an approach can contribute to noise reduction by determining only the CVEs that are actually exploitable in production as opposed to being flooded with hundreds of alerts.

Real-Life Example: Lightrun CVE Prioritization

Lightrun is a dynamic observability platform that enables developers to add logs, metrics, and snapshots to live applications—without having to release a new version or even stop the running process.

By enabling you to query your runtime code on-demand and in real-time, Lightrun can be used to determine the actual impact of a given vulnerability on your live application and thereby prioritize your security alerts. 

This process consists of three steps. 

1. Receive CVE alert via SAST/SCA tool or equivalent.

You receive an alert notifying you that a vulnerability has been flagged in one of the third-party libraries your application uses. 

2. Determine the impact of the vulnerability on the actual deployment.

Using Lightrun, you can investigate whether:

• The vulnerability’s code is actually loaded in a live code path.
• Which users/paths/customers are affected?
• How widespread the vulnerability is (i.e. which sections of the code are affected).
• How often the vulnerability could be exploited (by looking at the amount of code path invocations).
• Add logs, take snapshots, and set metrics in various places in the code to better understand the impact of the vulnerability.

3. Re-prioritize based on the actual effect on the Runtime application.

Armed with the relevant knowledge, you can now re-prioritize all “critical” and “high” severity vulnerabilities and mitigate them in the right order.

Don’t just take my word for it, the below is an example (courtesy of Tom Granot), of running dynamic observability on a code to determine whether it is impacted by the recent log4J.

Dynamic Observability: Bottom Line

By using solutions like Lightrun, developers get the information they need to prioritize alerts directly from the running application, directly in their IDEs. 

Developers query their code that is running in production and discerns which specific modules of it are vulnerable and which are not. This is how they effectively prioritize the security alerts and retain a little sanity! 

This latest evolution in dynamic observability empowers developers to properly prioritize their security alerts and massively reduce the number of false positives. They can spend less time scratching their heads over confusing alerts and more time getting on with writing valuable (and secure!) code. 

Shifting DevSecOps left by combining the power of SAST, DAST, and SCA together with dynamic observability tools is a major shift toward enhanced productivity and better remediation of security vulnerabilities that are growing year over year.