Determining Common Platform Enumeration (CPE)

Common Platform Enumeration (CPE)

Common Platform Enumeration (CPE) is a standardized method of describing and identifying classes of applications, operating systems, and hardware devices present among an enterprise's computing assets.

Read more about CPE - Common Platform Enumeration

Why determine CPE?

Each CPE uniquely identifies Red Hat platform (product) and version. A package, identified during the container scan, can have a different severity impact rating and state for identified CVE(s) based on the platform and version specific repository it belongs to.

Example

Lets take a look at CVE-2019-20387.

The Red Hat CVE database page for this CVE shows that package "libsolv" is affected by this CVE.

The overall impact of this CVE, as determined by Red Hat Product Security is "Moderate"; however the impact rating of this CVE for package "libsolv" is "low" for Red Hat Platform (product) Satellite version 6 and the state is "Affected". As you can see, from the table below, the impact and state for the same CVE and same package on Red Hat Platform RHEL7 is however "moderate" and "Will not fix" respectively.

This is why it is critical to identify CPEs (product+version) to accurately assess the impact of a CVE on a particular package or module.

Explore Red Hat's repository-to-cpe.json

CPEs let you identify the Red Hat product-version specific repositories the packages, from a container image, are installed from. Identified CPEs then can be used to find the corresponding OVAL v2 streams for assessing vulnerability risk associated with those packages.

You can employ your own methodology as long as you can accurately identify package repositories and corresponding OVAL v2 feeds for identified packages+versions (including Red Hat backporting fixes).

Content Manifests and CPEs

Each Red Hat published container image after June 2020 includes content manifest JSON files. The content manifests JSON file includes content_sets which provide you the repository names from which the packages from that container image were installed from.

Example

In this example we are inspecting the content manifest file "nodejs-10-container-1-99.json" from container image: "registry.redhat.io/ubi8/nodejs-10:1-108"

The process of identifying CPEs

For each container layer

Query the layer’s RPM database to get a list of packages
Use RPM to understand which packages have been updated.
If content manifest exist in /root/buildinfo/content_manifests
Use content_sets to get CPEs from mapping json

Clair processes each layer one at a time, which will only contain one content manifest json. The running container’s "/root/buildinfo/content_manifests" folder contains the aggregation of all layer’s content manifests, which could have different content sets.

The guidance is to extract the content sets from all json files.

Example

The "nodejs-10-container-1-99.json" from above example includes two repositories viz. rhel-8-for-x86_64-baseos-rpms and rhel-8-for-x86_64-appstream-rpms. As per Red Hat mapping json ;

rhel-8-for-x86_64-baseos-rpms maps to following CPEs

and rhel-8-for-x86_64-appstream-rpms maps to following CPEs.

Determining CPEs for Red Hat published images prior to June 2020

This use case is not within the scope of Red Hat Vulnerability Scanner Certification; however if you are interested in supporting Red Hat published images prior to June 2020 you may benefit from this guidance.

For each layer, if a content manifest does not exist, but a Dockerfile-* does exist;

Construct NVR (Name-Version-Release)

Get com.redhat.component in /root/buildinfo/Dockerfile-*
Extract version number from /root/buildinfo/Dockerfile-* file name
- NVR = (com.redhat.component label + Dockerfile version)