Anchore Secure - Vulnerability Management
Vulnerability management is the practice of identifying, categorising and remediating security vulnerabilities in software. Using a Software Bill of Materials (SBOM) as a foundation, Anchore Enterprise provides a mechanism for scanning containerized software for security vulnerabilities. With 100% API coverage and fully-documented APIs, users can automate vulnerability scanning and monitoring - performing scans in CI/CD pipelines, registries and Kubernetes platforms. Furthermore, Anchore Enterpise allows users to identify malware, secrets, and other security risks through catalogers.
Jump into a particular topic using the links below:
- Image Analysis
- Registries & Repositories
- Runtime Inventory
- Reporting & Remediation
- Subscriptions
- False Positives
Vulnerability data sources
Vulnerability matching in Anchore Enterprise and Grype begins with collecting vulnerability data from multiple sources to identify vulnerabilities in the packages cataloged within an SBOM.
Anchore Enterprise and Grype consolidate data from these sources into a format suitable for vulnerability identification in SBOMs. One key source of data is the National Vulnerability Database (NVD). The NVD serves as a widely recognized, vendor-independent resource for vulnerability identification. Additionally, it provides a framework for measuring the severity of vulnerabilities. For instance, the NVD introduced the Common Vulnerability Scoring System (CVSS), which assigns numerical scores ranging from 0 to 10 to indicate the severity of vulnerabilities. These scores help organizations prioritize vulnerabilities based on their potential impact.
However, due to known limitations with NVD data, relying on additional sources becomes essential. Anchore Enterprise and Grype also collect vulnerability data from vendor-specific databases, which play a crucial role in accurate and efficient detection. These sources enable vulnerability matching from the vendor’s perspective. Examples of such vendor-specific databases include GitHub, the Microsoft Security Response Center (MSRC), and the Red Hat Security Response Database, among others.
Data import & normalization
Anchore has a tool called vunnel that is responsible for reaching out to various data sources, parsing and normalizing that data, then storing it for future use.
There is not one standard format for publishing vulnerability data, and even when there is a standardized data format, such as OVAL or OSV, those formats often have minor incompatible differences in their implementation. The purpose of vunnel is to understand each data source then output a single consistent format that can be used to construct a vulnerability database.
Providers
The process begins with vunnel reaching out to vulnerability data sources. These sources are known as “providers”. The following are a list of vunnel Providers:
- Alpine: Focuses on lightweight Linux distributions and provides vulnerability data tailored specifically to Alpine packages.
- Amazon: Offers vulnerability data for its cloud services and Linux distributions, such as Amazon Linux.
- Chainguard: Specializes in securing software supply chains and delivers vulnerability insights for containerized environments.
- Debian: Maintains a robust security tracker for vulnerabilities in its packages, concentrating on open-source software used in Debian-based systems.
- GitHub: Provides vulnerability data supported by an extensive advisory database for developers.
- Mariner (CBL-Mariner): Microsoft’s Linux distribution, provides vulnerability data within its ecosystem.
- NVD (National Vulnerability Database): Serves as the official U.S. government repository of vulnerability information.
- Oracle: Tracks vulnerabilities in Oracle Linux and other Oracle products, focusing on enterprise environments.
- RHEL (Red Hat Enterprise Linux): Delivers detailed and timely vulnerability data for Red Hat products.
- SLES (SUSE Linux Enterprise Server): Offers vulnerability data for SUSE Linux products, with a strong focus on enterprise solutions, particularly in cloud and container environments.
- Ubuntu: Maintains a well-documented vulnerability tracker and provides regular security updates for its popular Linux distribution.
- Wolfi: It is a community-driven, secure-by-default Linux-based distribution that emphasizes supply chain security and provides reliable vulnerability tracking.
vunnel reaches out to all of these providers, collates vulnerability data and consolidates it for use. The end product of the operations of vunnel is what we call the Grype database (GrypeDB).
Building GrypeDB
When the data from vunnel is collected into a database, we call that GrypeDB. This is a sqlite database that is used by both Grype and Anchore Enterprise for matching vulnerabilities. The Anchore Enterprise database and the Grype database (consolidated by vunnel) are not the same data. The hosted Anchore Enterprise database contains the consolidated GrypeDB as well as the Exclusion database and Microsoft MSRC vulnerability data.
Non-Anchore (upstream) data updates
When there are problems with other data sources, we contact those upstream sources and work with them to correct issues. Anchore has an “upstream first” policy for data corrections. Whenever possible we will work with upstream data sources rather than trying to correct only our data. We believe this creates a better overall vulnerability data ecosystem, and fosters beneficial collaboration channels between Anchore and the upstream projects.
An example of how we submit upstream data updates can be seen in the GitHub Advisory Database HERE
Data enrichment
Due to the known issues with the NVD, Anchore Enterprise enhances the quality of its data for analysis by enriching the information obtained from the NVD. This process involves human intervention to review and correct the data. Once this manual process is completed, the cleaned and refined data is stored in the Anchore Enrichment Database.
The Anchore enriched data can be reviewed in GitHub HERE
The scripts that drive this enrichment process are also in GitHub HERE
Before implementing this process, correcting NVD data was a challenge. However, with our enrichment process, we now have the flexibility to make changes to affected products and versions. The key advantage is that the data used by Anchore Enterprise is now highly reliable, ensuring that any downloaded data is accurate and free from the common issues associated with NVD data.
An example of enriching NVD data for more accurate detection is CVE-2024-4030, which was initially identified as affecting Debian when it actually only impacts Windows. By applying our enrichment process, we were able to correct this error.
Vulnerability matching process
When it’s time to compare the data from an SBOM to the vulnerability data constructed into Anchore Enterprise, we call that matching. Anytime vulnerability data is surfaced in Anchore Enterprise, that data is the result of vulnerability matches.
CPE matching
CPE which stands for Common Platform Enumeration is a structured naming scheme standardized by the National Institute of Standards and Technology (NIST) to describe software, hardware, and firmware. It uses a standardized format that helps tools and systems compare and identify products efficiently.
CPE matching involves comparing the CPEs found in the SBOM of a software product against a list of known CPE entries to find a match. The diagram below illustrates the steps involved in CPE matching.
Due to the current state of the NVD data as mentioned above, CPE matching is sometimes leads to false positives match, this led to the creation of the exclusion data we manage in Anchore.
Vulnerability Match Exclusions
There are times we cannot solve a false positive match using data alone. This is generally due to limitations of how CPE matching works. In those instances, Anchore Enterprise has a concept called Vulnerability Match Exclusions. These exclusions allow us to remove a vulnerability from the findings for a specific set of match criteria.
The data for the vulnerability match exclusions is held in a private repository. The data behind this list is not included in the open source Grype vulnerability data.
For example, if we look at CVE-2012-2055 which is a vulnerability reported against the GitHub product. When trying to match a CPE against this CVE, CPE is unable to capture this level of detail. GitHub libraries for different ecosystems will show up as affected. The Python GitHub library is an example. In order to resolve this, we exclude the language ecosystems using a match exclusion.
The exclusion data can be seen below:
exclusions:
- constraints:
- namespaces:
- nvd:cpe
packages:
- language: java
- language: python
- language: javascript
- language: ruby
- language: rust
- language: go
- language: php
justification: This vulnerability affects the GitHub product suite, not language-specific clients
id: CVE-2012-2055
Matching
The matching process that happens against an SBOM is the same basic process in both Grype and Anchore Enterprise. The vulnerability data is stored in GrypeDB, details such as vulnerability ID, package and versions affected as well as fix information are part of these records.
For example for vulnerability CVE-2024-9823 we store the package name, Jetty, the fixed version, 9.4.54, and which ecosystems are affected, such as Debian, NVD, and Java. We call these ecosystems a namespace in the context of a match.
The namespace used for the match is determined by the package stored in the SBOM. For a Debian package, the Debian namespace would be used, for Java - GitHub will be used by default in Grype, but NVD will be used by default in Anchore Enterprise. The default matcher for Java can be changed in Anchore Enterprise, we encourage you to do so as it will result in higher quality matches. We will be changing this default in a future release. See disabling CPE matching per supported ecosystem
The details about the versions affected will be used to determine if the version reported by the SBOM falls within the affected range. If it does, the vulnerability matches.
For a successful match, the fixed details field will be used to display which version fixes a particular vulnerability. The fix details are specific to each namespace. The version in Debian that fixes this vulnerability, 9.4.54-1, is not the same as the version that fixes the Java package, 9.4.54.
It should also be noted that if a vulnerability appears on the match exclusion list, it would be removed as a match.
Once a match exists, then additional metadata can be surfaced. We store details such as severity and CVSS in this table. Sometimes a field could be missing, such as severity or CVSS. Missing fields will be filled in with the data from NVD if it is available there.
Vulnerability Matching Configuration
Search by CPE can be globally configured per supported ecosystem via the anchore enterprise policy engine config. The default enables search by cpe for all ecosystems except for javascript (since NPM package vulnerability reports are exhaustively covered by the GitHub Security Advisory Database).
A fully-specified default config is as below:
policy_engine:
vulnerabilities:
matching:
default:
search:
by_cpe:
enabled: true
ecosystem_specific:
dotnet:
search:
by_cpe:
enabled: true
golang:
search:
by_cpe:
enabled: true
java:
search:
by_cpe:
enabled: true
javascript:
search:
by_cpe:
enabled: false
python:
search:
by_cpe:
enabled: true
ruby:
search:
by_cpe:
enabled: true
stock:
search:
by_cpe:
# Disabling search by CPE for the stock matcher will entirely disable binary-only matches
# and is *NOT ADVISED*
enabled: true
A shorter form of the default config is:
policy_engine:
vulnerabilities:
matching:
default:
search:
by_cpe:
enabled: true
ecosystem_specific:
javascript:
search:
by_cpe:
enabled: false
If disabling search by CPE for all GitHub covered ecosystems is desired, the config would look like:
policy_engine:
vulnerabilities:
matching:
default:
search:
by_cpe:
enabled: false
ecosystem_specific:
stock:
search:
by_cpe:
enabled: true
Comprehensive distributions
When matching vulnerabilities against a Linux distribution, such as Alpine, Red Hat, or Ubuntu, there is a concept we call “comprehensive distribution”. A comprehensive distribution reports both fixed and unfixed vulnerabilities in their data feed.
For example, Red Hat reports on all vulnerabilities, including unfixed vulnerabilities. Some distros, like Alpine, do not report unfixed vulnerabilities. When a distribution does not contain comprehensive vulnerability information, we fall back to other data sources as a best effort to determine vulnerabilities that affect Alpine and are not fixed yet.
Fix details
There are some additional details for the fixed data from NVD that should be explained. NVD doesn’t contain explicit fix information for a given vulnerability. Other namespaces do, such as GitHub and Debian. There is a concept of “Less Than” and “Less Than or Equal” in the NVD data. When a vulnerability is tagged with “Less Than or Equal”, it could mean there is no fix available, or the fix couldn’t be figured out, or a fix was unavailable at the time NVD looked at it. In those cases we cannot show fix details for a vulnerability match.
If NVD uses “Less Than”, it is assumed that the version noted is the fixed version, unless that version is part of the affected range of a subsequent CPE configuration for the same CVE. We will present that version as containing the fix.
For example if we see data that looks like this:
some_package LessThan 1.2.3
We would assume version 1.2.3 contains the fix, and any version less than that, such as 1.2.2 is vulnerable. Alternatively, if we see:
some_package LessThanOrEqual 1.2.2
We know version 1.2.2 and below are vulnerable. We however do not know which version contains the fix. It could be in version 1.3.0, or 1.2.3, or even 2.0.0. In these cases we do not surface fixed details. If we are able to figure out such details in the future, we will update our CVE data.
Last modified December 4, 2024