5 Best Practices for Reducing CVEs in Container Applications

All software (and even hardware) contains security vulnerabilities, and the number of publicly reported CVEs (common vulnerabilities and exposures) continues to grow every day. All software depends on other software, which can include a vulnerability at each level, further exacerbating the risk and reinforcing the urgency for organizations to detect and patch vulnerabilities. Let’s take a look at how to detect CVEs and best practices for reducing them in your container applications through prevention and detection.

Typical Sources of CVEs

There are three common sources of CVEs.

1. Base image: All distributions (Alpine, Ubuntu, Red Hat, etc.) have built-in libraries that are updated with each distro’s release. If your software is pinned to a base image version that was released a year ago, the underlying libraries would not have been updated since and are likely to contain CVEs.
2. Code: Your code depends on other software libraries (code dependencies), and if these libraries are pinned to old versions, they can contain CVEs. Although the CVE is not directly related to your code, your code might still be vulnerable if the vulnerable function is being used. This is known as a transitive vulnerability. For example, if you use Kubernetes libraries within your own code and one of the Kubernetes libraries has a CVE, your code can potentially be vulnerable.
3. Coding language: The language libraries you use could themselves have CVEs. For example, Golang could have some CVEs within its own language that regularly get patched in the new Golang versions.

All of these sources open up your environment to potential CVEs and increase your attack surface.

Detecting CVEs

The work of detecting CVEs is usually carried out by vulnerability scanners, of which there are many free and paid versions. Vulnerability scanners identify everything your software consists of (base image, code, language, etc.) in order to build a list of software components or a software bill of materials (SBOM). This information is checked against the scanner’s own database to identify which of the libraries have vulnerabilities.

There can be variability in scan results from different vulnerability scanners. There are a few reasons for this. First, some scanners might only use CVEs from the national standard databases, such as the U.S. National Vulnerability Database (NVD), while others use additional third-party databases. Second, how a vulnerability scanner goes about identifying libraries within code can differ in the way they detect software binaries and match known vulnerabilities with those software binaries. Third, how scanners handle transitive dependencies (dependencies of dependencies that you import into your code) varies in depth and granularity. All of these considerations can make a difference in the outcome/results of a scan.

All this is to say that vulnerability scanners are not perfect; they can miss things or not get the whole picture. They might not find all sources (everything your software is built of) and might return varying results. Let’s look at some best practices for both prevention and detection that can help guard against these deficits.

Best Practices for Reducing CVEs in Container Applications

It’s important to detect and patch CVEs in a timely manner to ensure the security of your environment/product. The sheer number of reported CVEs combined with multiple potential sources of CVEs can make this a difficult task. Here are five best practices for reducing CVEs in your container applications.

1. Trim your base image: Including too many libraries in your code and base image increases your attack surface. The best practice is to only include the libraries you need. To do this, start with a scratch image and only copy the specific libraries from the latest base image that is needed. If there are 100 libraries in a base image, only include the 10 that you actually need.
2. Use the latest and greatest libraries: Consistently follow code updates for the libraries you use, and stay ahead of the curve by updating regularly when new versions are available. If there is a new version of the coding language you use, you should include it in the next release.
3. Use more than one vulnerability scanner: Since vulnerability scanners can produce different results, you should use more than one scanner in an effort to detect as many potential vulnerabilities as possible. We also recommend checking your code source (such as GitHub) to get even wider coverage in case the scanners miss anything or don’t have access to your code.
4. Scan often: We recommend performing regular (at least once a week) scans of your software to monitor the status of CVEs. Leading up to a release, increasing the frequency of scans to multiple times a day helps to ensure CVEs do not slip through. Alternatively, it is recommended to integrate vulnerability scanning into your build or deploy CI/CD process if this better fits your organization’s software release process.
5. Shift left: Traditionally, vulnerability scanning and security assessments have been performed by specialized security teams or external auditors after the code is developed. Shift the responsibility of vulnerability scanning processes closer to development teams to avoid a long and complicated resolution process when CVEs are discovered. Shifting visibility and creating processes to proactively address CVEs for developers empowers them to become more responsible and involved in the security of their own code from the beginning.

Lastly, make sure you have a good relationship with the development team in your organization, as you’ll both need to be on the same page in terms of understanding the importance of security in your environment/product. This is done via security education and training, establishing security guidelines and creating a process that considers the unique processes and needs of your engineering organization.

What to Do After Detecting CVEs

You’ve scanned your environment to identify CVEs and are now staring at a list of 200 things to fix. What next? There’s no way you can analyze them all before the next batch of CVEs comes out, so start by identifying and patching the high-priority CVEs first, and then if you have time, work your way down the list in terms of priority. For a more detailed discussion of patching CVEs, stay tuned for our next article, “Vulnerability Management: Best Practices for Patching CVEs.”

Read our guide to learn more about Kubernetes vulnerability scanning.