Vulnerability Naming Schemes
With a constantly growing number of IT assets to administer, security practitioners require new and more powerful tools to perform automated and large scale analysis. Thanks to software attention can be focused on the more creative and intellectually challenging problems. Unfortunately, having vulnerability assessment tools, antivirus software, and intrusion detection systems communicate its not an easy job. It has resulted in several technical complications, requiring a standardized way to identify each software flaw, vulnerability, or configuration issues identified. The lack of this interoperability capabilities can cause inconsistencies during the security assessment, confusing reporting, and extra correlation efforts among other problems that will produce an important waste of resources and time.
A naming scheme is a systematic methodology used to identify each one of those vulnerabilities in order to facilitate clear identification and information sharing. This goal is achieved by the definition of a unique, structured, and software-efficient name for each vulnerability. There are multiple schemes used to facilitate this effort, the most common are:
Common Platform Enumeration (
CPE)Software Identification Tag (
SWID)Package URL (
PURL)
Software Identification Tag
Software Identification Tag (SWID) is an International Organization for Standardization's standard defined by the ISO/IEC 19770-2:2015. The SWID tags are used to identify each software clearly as part of comprehensive software asset management lifecycles. This information schema is recommended to be used by the National Institute of Standards and Technology (NIST) as the primary identification for any developed or installed software. From SWID it's possible to generate other schemas such as the CPE used by the National Vulnerability Database (NVD) whereas the reverse process is not possible.
Each SWID tag is represented as a standardized XML format. A SWID tag is composed for three groups of elements. The first block composed by 7 predefined elements required to be considered a valid tag. Followed by an optional block which provides a set of 30 possible predefined elements that the tag creator can use to provide reliable and detailed information. Finally, the Extended group of elements provides the opportunity for the tag creator to define any non predefined elements required to accurately define the described software. The high level of granularity provided by SWID, not only provides the capability to describe a given product of software, but also it's specific status on the software lifecycle.
Examples
ACME Roadrunner Service Pack 1 patch created by the ACME Corporation for the already installed product identified with the
@tagId: com.acme.rms-ce-v4-1-5-0:
Red Hat Enterprise Linux version 8 for x86-64 architecture:
Common Platform Enumeration
The Common Platform Enumeration scheme (CPE) is a structured naming scheme for information technology systems, software, and packages maintained by NVD. Commonly used in conjunction with the Common Vulnerabilities and Exposures identification codes (e.g. CVE-2017-0147). Despite being considered a deprecated scheme superseded by SWID, CPE is still widely used by several security solutions.
Defined as a Dictionary of registered values provided by NVD. Each CPE code can be defined as a well-formatted name or as a URL. Each value MUST follow this structure:
cpe-name = "cpe:" component-list
component-list = part ":" vendor ":" product ":" version ":" update ":" edition ":" lang
component-list = part ":" vendor ":" product ":" version ":" update ":" edition
component-list = part ":" vendor ":" product ":" version ":" update
component-list = part ":" vendor ":" product ":" version
component-list = part ":" vendor ":" product
component-list = part ":" vendor
component-list = part
component-list = empty
part = "h" / "o" / "a" = string
vendor = string
product = string
version = string
update = string
edition = string
lang LANGTAG / empty
string = *( unreserved / pct-encoded )
empty = ""
unreserved = ALPHA / DIGIT / "-" / "." / "_" / " ̃"
pct-encoded = "%" HEXDIG HEXDIG
ALPHA = %x41-5a / %x61-7a ; A-Z or a-z
DIGIT = %x30-39 ; 0-9
HEXDIG = DIGIT / "a" / "b" / "c" / "d" / "e" / "f"
LANGTAG = cf. [RFC5646]
Examples
Microsoft Internet Explorer 8.0.6001 Beta (any edition):
wfn:[part="a",vendor="microsoft",product="internet_explorer", version="8\.0\.6001",update="beta",edition=ANY]which binds to the following URL:cpe:/a:microsoft:internet_explorer:8.0.6001:beta.Foo\Bar Big$Money Manager 2010 Special Edition for iPod Touch 80GB:
wfn:[part="a",vendor="foo\\bar",product="big\$money_manager_2010", sw_edition="special",target_sw="ipod_touch",target_hw="80gb"], which binds to the following URL:cpe:/a:foo%5cbar:big%24money_manager_2010:::~~special~ipod_touch~80gb~.
Package URL
Package URL standardizes how software package metadata is represented so that packages can be universally located regardless of what vendor, project, or ecosystem the packages belongs.
A PURL is a valid RFC3986 ASCII string defined URL composed of seven elements. Each of them is separated by a defined character in order to make it easily manipulated by software.
scheme:type/namespace/name@version?qualifiers#subpath
The definition for each component is:
scheme: URL scheme compliant constant value of "pkg". (Required).
type: package type or package protocol such as maven, npm, nuget, gem, pypi, etc. (Required).
namespace: type-specific value to a package prefix such as it's owner name, groupid, etc. (Optional).
name: name of the package. (Required).
version: package version. (Optional).
qualifiers: extra qualifying data for a package such as an OS, architecture, a distro, etc. (Optional).
subpath: extra subpath within a package, relative to the package root. (Optional).
Examples
Curl software, packaged as a
.debpackage for Debian Jessie meant for an i386 architecture:pkg:deb/debian/curl@7.50.3-1?arch=i386&distro=jessieDocker image of Apache Casandra signed with the SHA256 hash 244fd47e07d1004f0aed9c:
pkg:docker/cassandra@sha256:244fd47e07d1004f0aed9c
Recommendation Uses
Client or Server Application
CPE or SWID
Container
PURL or SWID
Firmware
CPE or SWID*
Library or Framework (package)
PURL
Library or Framework (non-package)
SWID
Operating System
CPE or SWID
Operating System Package
PURL or SWID
Note: Due to the deprecated status of
CPE, industry recommended seems to be that new projects implementSWIDwhen they need to decide between the two methods. Even thoughCPEis known to be a widely used naming schema within current active projects and solutions.
References
Known Implementations
Last updated