Best Practices for Package Vulnerability Scanning
Package security vulnerability scanning is a basic step toward securing virtually any modern software delivery pipeline. With SCA Tools, one can automatically identifying known vulnerabilities within the packages that are used to deploy applications, package scanners significantly reduce the risk of releasing insecure software into production.
Securing packages, however, requires more than simply setting up an automated package scanner and assuming that it will detect all potential vulnerabilities. As this article explains, teams should take additional steps to get the most out of package vulnerability scanning.
What is package vulnerability scanning?
Package vulnerability scanning is the process of automatically analyzing software packages for known vulnerabilities.
Vulnerability scanners can inspect virtually any type of package. They can be used to scan Docker container images, for instance, or Debian or RPM packages that developers create to deploy software on Linux systems.
Typically, package scanners work by checking whether the contents of a software package match items that are known to be vulnerable based on databases that track security flaws within applications and libraries. For example, a vulnerability scanner may determine that a package includes a particular version of a software library that contains a known security bug. The scanner would flag the issue and warn developers to update the library to a more recent, secure version.
The limitations of package vulnerability scanners
While vulnerability scanners are an important tool for finding many types of security risks within software, it’s important to remember that they only check for vulnerabilities that have already been identified within vulnerability databases.
They usually can’t detect security bugs, like buffer overflow vulnerabilities, that exist within code that developers write in-house. That’s a job for static application security testing tools. Nor do they monitor application behavior for signs of a security breach, which is a task handled by SIEMs and other security monitoring tools.
Another limitation is interpreting the large number of alerts that vulnerability scanners can generate. You’ll typically receive a long list of vulnerabilities when you scan your packages, and the scanner doesn’t necessarily assess the severity of each vulnerability it identifies. For that reason, it can be challenging to know which vulnerabilities are serious enough to warrant not using an image, and which pose insignificant risks. Gleaning that insight often requires manual analysis of each vulnerability and its potential to impact your environment.
Watch the On-Demand Webinar: Identifying and Avoiding Malicious Packages
WATCH ON-DEMAND WEBINAR
Getting the most from package vulnerability scanners
Simply deploying an automated package vulnerability scanner as part of your CI/CD pipeline is the first step toward staying ahead of security issues. But teams should take additional steps to maximize their chances of finding all potential vulnerabilities within packages.
Keep packages as small as possible
The more code and dependencies you have in each package, the more difficult it can be for vulnerability scanners to unpack all of the layers and detect vulnerabilities. It’s also harder to fix a security issue and rebuild the package if the package contains many items.
It’s a best practice to ensure that each package you create contains only the code and other resources required to deploy one facet of functionality. Resist the temptation to cram multiple components of an application into a single package.
For instance, instead of creating a Docker image that contains multiple microservices, generate different images for each microservice. Or, rather than packaging both an application frontend and the application logic into the same Debian package, separate them into different packages.
Scan early in the development lifecycle
Instead of waiting until just before deployment to scan packages, aim to perform scans as soon as packages are built.
Scanning as early as possible offers two benefits. First, vulnerabilities are easier to address earlier in the CI/CD pipeline, because you have less invested. If you wait to scan until you’ve already performed other types of tests with your packages, you’ll need to run those tests again if you detect a vulnerability and have to rebuild the package.
Second, early scanning minimizes the risk of making an insecure application available to production. You don’t want to push container images into a registry, where users could start downloading and installing them, before you’ve scanned them.
Early scanning is not a substitute for scanning just prior to deployment, which is also important in order to ensure you assess the risks of the software you actually push into production. But scanning earlier in the development cycle as well will help you weed out potential vulnerabilities before they move down the pipeline.
Assess priority levels
As noted above, a long list of vulnerabilities within a package isn’t very helpful if your team struggles to determine which vulnerabilities are serious enough to make the package unusable. Avoid this problem by investing in a scanner that enables effective vulnerability risk assessment and prioritization based on an analysis of the actual security impact of each vulnerability. That way, you can easily determine which vulnerabilities are show-stoppers, and which are issues that you can ignore.
Scan packages even if you trust the source
Sometimes, the packages you deploy come from third-party sources rather than in-house. It’s critical in these cases to ensure that you scan the packages, no matter how much confidence you have in the source.
Invest in a comprehensive vulnerability database
Open-source package vulnerability scanners (SCA Tools) are only as effective as the vulnerability data you feed into them. If your vulnerability database doesn’t include a known security issue, your scanner can’t detect it. That’s why it’s a wise choice to invest in a vulnerability scanning solution from a DevOps security platform provider that leverages a comprehensive vulnerability database by drawing on multiple sources of threat information — including public, proprietary, and in-house security research expertise.
The JFrog security research team builds and maintains the JFrog Xray vulnerability database with open-source package data including license types and known vulnerabilities (CVEs). JFrog’s security analysts also add enhanced context and CVE data with alternate remediation guidance where applicable.
