Guide to Vulnerability Scanning Using Software Composition Analysis
Every software application can contain vulnerabilities. As a matter of fact, according to a 2021 report, no less than 100 percent of applications tested by security researchers included vulnerabilities, and 85 percent of them were considered critical.
Fortunately, using Software Composition Analysis (SCA) tools, it’s possible to detect most vulnerabilities before you deploy software into production. SCA scanners can identify and analyze vulnerabilities that lurk within both source code and binaries, even in cases where developers would be unlikely to catch the vulnerabilities via manual code reviews.
That’s why vulnerability scanning using SCA tools should be a core step within any application delivery pipeline. Keep reading for an explanation of how SCA works, and how to take advantage of SCA tools to enhance the security of the applications you build.
How does SCA vulnerability scanning work?
SCA scans work in a straightforward way: By parsing source code and/or binaries, SCA tools look for the presence of application components that are known to be insecure.
In most cases, SCA tools do this by matching application components against vulnerability databases, which catalog security vulnerabilities that researchers have reported within open source libraries, modules, container images and other resources. By identifying the specific versions of third-party components within an application, then determining whether those versions are associated with known vulnerabilities, SCA tools can flag security risks. Advanced SCA tools can also determine whether a risk can be exploited based on the specific configuration or environment setup of an application. With this information, developers can remediate the risks by, for example, upgrading an insecure open source library to a newer version that is secure.
It’s important to understand that, although SCA tools can detect many types of vulnerabilities, a major limitation is that they can typically only identify risks associated with open source software components. SCA tools can’t catch security problems caused by original code that developers write themselves, unless those problems are recorded in open source vulnerability databases. Vulnerabilities that exist within open source code, but that have not yet been identified by security researchers or the open source community, also can’t be detected using SCA tools.
When to perform vulnerability scans
Although SCA vulnerability scans can be performed at any stage of the software development lifecycle, they are most valuable when they take place pre-deployment. In other words, developers should scan applications prior to pushing them into production, so that they can catch vulnerabilities before the risks impact end-users.
Note, too, that SCA scans can be performed at multiple stages of the software delivery cycle. In many cases, it makes sense first to scan source code early in the development lifecycle, in order to detect vulnerabilities that may have been introduced by importing third-party code into an application’s codebase.
Then, SCA scans can be run again against binary application components, such as container images, within pre-production staging environments. By scanning binaries, developers can detect additional types of vulnerabilities, such as the use of insecure base images within containerized applications, that would not necessarily be evident from scanning application source code.
Examples of SCA vulnerability scanning
As examples of how SCA can help detect vulnerabilities prior to application deployment, consider the following SCA use cases.
Detecting vulnerabilities in source code
Imagine that you’re developing a Python application, and you include the urllib.parse module in the source code. This module is subject to a known vulnerability that can enable injection attacks.
An SCA tool can scan your Python source code, detect the use of the insecure module and alert you to the risk so that you can take remediative action (which, in the case of the urllib.parse vulnerability, would involve upgrading to a newer version).
Container image vulnerability detection
When you create containers, it’s common to use so-called base images, which contain various libraries and tools that you can use as the foundation of your containerized application environment.
In the event that you choose a base image (such as the Ubuntu 18.04 base image on Docker Hub, which currently contains 21 known vulnerabilities) that includes known vulnerabilities, SCA tools can flag the risk. You can then take steps to mitigate the risk by, for example, including code inside your container to update the vulnerable components of the base image to newer versions.
Helm chart vulnerability detection
Helm charts, which are used to install applications in Kubernetes, can also contain a variety of vulnerabilities. SCA tools can scan Helm charts before they are deployed into a Kubernetes cluster, allowing developers to react to security risks within them.
Conclusion
Source Composition Analysis is the best means of detecting vulnerabilities that originate from open source software within both application source code and binaries. If you import any type of third-party resources into software you build, you should run SCA vulnerability scans to catch security risks before they can be exploited.
As an SCA scanning tool that can integrate seamlessly into your DevOps software delivery pipeline, JFrog Xray makes it easy to perform continuous vulnerability scans as code flows from development into production. With Xray, you can enjoy the confidence that you’ll catch vulnerabilities before hackers exploit them.
