Common Vulnerabilities and Exposures, or “CVEs”, are identifiers for specific vulnerabilities. MITRE defines its CVE list as a “dictionary of publicly disclosed cybersecurity vulnerabilities and exposures that is free to search, use, and incorporate into products and services.” The CVE list feeds into the National Vulnerability Database (NVD).
CVEs allow teams to track vulnerabilities that directly impact their system. In modern DevSecOps environments, it is common for CVE’s to be discovered during both build and runtime. A CVE matters because it provides traceability for each vulnerability that adversely impacts software. It is a way to describe and manage a discrete vulnerability. The name of a CVE simply provides the year each vulnerability was detected, which is useful. But the truly impactful part of each CVE as it matters to our everyday users come from the data and various scoring methods associated with each one. The scoring, description, and intelligence associated with each CVE are far more important than the CVE identifier itself.
Anchore includes CVEs in our report generation as they are the primary way our customers trace the impact of a vulnerability on their images. In many popular attacks against container images, attackers focus on the software supply chain (such as storing malicious images in container registries, typosquatting attacks on packages/images, etc.) rather than probing an existing system for a specifically available exploit in a running image. That being said, beyond their value in identifying and tracking specific vulnerabilities, they lack the information required for a security team to take action.
So Now What?
But how does Anchore incorporate the importance of a CVE into their product? What can your team do to be more proactive with container security?
Your security team can definitely help prevent typosquatting (see a good story at The New Stack about typosquatting and the dangers associated) and the downloading of malicious (accidentally, hopefully) images by your developers. Anchore can both help with supply chain oriented attacks in addition to taking the information we know about CVEs and using that as actionable data in our scanning policy.
Whitelist/Blacklist Your Images and Packages
To prevent this, Anchore easily provides the ability to blacklist images that may be suspicious, malicious, or simply up to no good in a public container registry. Navigate to your “policy tab”, select Edit Policy, then navigate to the whitelisted blacklisting images tab here:
Under blacklisted images, you can select “let's add one.” You will see the screen below that allows you to add an image based on name (providing the registry, repo, and tag), by image ID, or by SHA digest. Blacklisting assumes you already know what is malicious and what is not. A more proactive approach would be whitelisting ONLY the images you want to use so that any other images, malicious or otherwise, are flagged for review in Anchore before they hit production. You also have the option to take this a step further and whitelist/blacklist specific packages for your organization to prevent typosquatting attacks.
Similarly, typosquatting attacks can happen on URLs, images, and even individual packages as was the case here where python packages contained legitimate code but had a setup.py script that would gather hostname and user information that would be sent back to another system. To prevent these unfortunate events from occurring in your container workloads, Anchore provides the ability to inspect your packages and blacklist specific package contents. You can view package contents here to understand the complete packages and files within your image to hunt for potentially malicious packages that wouldn’t be identified by a CVE.
Anchore allows you to make user-defined policy so you can easily blacklist malicious packages that are independently discovered by your security team or a part of any threat intelligence you are acting upon. You can do this by navigating to policy checks and either adding to an existing policy or creating a new one. For this example, I will create a specific policy called “Typosquatting Checks” here:
I will then tailor this policy for specific known malicious packages that may be impersonating legitimate packages, and create a stop action in Anchore for any image that contains a malicious/fake package as seen here where we blacklist urlib3 (malicious package) that is impersonating urllib3 (legitimate package).
Don’t Boil the CVE Ocean: Incorporate CVSS Scoring into Scanning
Another more proactive way to tackle the management of CVEs in your environment, albeit not perfect given some flaws of scoring, is to integrate scoring into your scanning policy. The Common Vulnerability Scoring System (CVSS) is “an open framework for communicating the characteristics and severity of software vulnerabilities.” A way of explaining this is depicted below:
[caption id="attachment_987460283" align="aligncenter" width="1600"]
Source: NVD[/caption]
At a high level, you can correlate a CVE with its CVSS score to determine which CVEs have the greatest impact on your system by looking at two things:
- Exploitability
- Impact
The higher the score on either of these factors, the more concern it should have for your security team. If a CVE has a very high exploitation score of a 9.5, but has a very low impact with a score of 2.0 then maybe it shouldn’t be a high priority. The same is true if you have a high impact score, but low exploitation score, which can commonly be the case if an attack vector isn’t widely available or if certain privileges are required in order to execute the attack and actually exploit the vulnerability. There are many other things that should be looked at when assessing vulnerability exploitation such as attack vectors, associated privileges, and attack complexity.
We put the power in the hands of the security teams to define the terms of policy enforcement for their container images. One way to make an intuitive policy using Anchore is to click “Add New Policy.”
There are 10+ selectors you can use to create your policy, such as CVSS base score, exploitability score, impact score, and fix availability.
This way, you aren’t scanning “just to scan” and check the compliance box for your next audit. You are scanning proactively, using a collection of user-defined acceptance rule checks to generate an actionable list of vulnerability and compliance findings immediately addressable by your security team. By taking these steps, your teams can gain more security insight about the containers they are using instead of routinely gathering the CVE’s and attempting to solve your security woes by boiling the entire “CVE ocean."
