@Ikey wants it to be easy to do automated CVE checks.
@ReillyBrogan suggested supporting the NIST CPE format as a way to search for CVEs related to a specific software asset (read: package).
It turns out that monitoring.yml is also useful in terms of checking release versions against a database of known upstream releases.
Hence, release monitoring syntax was added in version 5 of this spec.
I looked into what CPE is and came up with the following (based on the NIST CPE Naming Specification v2.3):
CPE = Common Platform Enumeration
WFN = Well Formed Name
FSB = Format String Binding
The CPE Naming Standard version 2.3 (the one currently in use) was made to be extensible.
The FSB used to identify a particular product looks like this in CPE v2.3 (section 6.2):
cpe:2.3: part : vendor : product : version : update : edition : language : sw_edition : target_sw : target_hw : other
In the above FSB, a value of
* means ANY. The
part thing will always be
a in our case, because
a stands for
If we assume that the CPE v2.3 standard is extensible enough to last us, say, 5 years into the future, it should be fine to hide away the FSB prefix in our code, along with this rationale. This would allow us to concentrate on exposing the relevant keys (vendor, product, etc.) to the packager in YML format files.
Assuming that the
product string will in many cases be the same as the package name property, it might also make sense to make the section that describes CPE properties a part of stone.yml, because it will allow us to use the package
%(name) definition where appropriate.
Consider that changing/validating the format string prefix in single place in the code has a time complexity of O(1).
In contrast, changing/validating the format string prefix if it's baked into the monitoring.yml file format has a time complexity of O(n) where 'n' is the number of packages with a monitoring.yml file. In addition, it introduces the possibility of syntax errors in each and every monitoring.yml file.
CVE tracking across CPE vendors/products
In some cases, products and vendors change over time but refer to the same code base.
To gain the ability to introspect a product's entire security history, it may be useful to be able to collate CVEs for all known aliases of a cpe product:vendor pair.
In the recommendation below, the aliases/historical renames are considered OPTIONAL per package and can be added at maintainer discretion.
In particular, the recommendation provides an intuitive way to manage the list of ignored CVEs even when product/vendor aliases or multiple products are present.
The recommendation in this post supersedes the below post titled "CPE Product:Vendor aliases".
@ReillyBrogan also notes that:
Also, I see that you put "aliases/historical renames" as a comment. I would like to point out that it's possible for a package to be composed of several components and another reason for allowing multiple entries is to search for all of them
Take docker on Solus. It is composed of moby, docker-cli, and tini
Finally, note that the
cpe: substruct was added to allow for future extensibility in the event that a downstream consumer needs to add its own internal security monitoring fields.
Implement as a file called
monitoring.yml (which sits next to
stone.yml per recipe) with the following format:
id: <integer corresponding to package anitya id>
rss: <valid URI to RSS/ATOM release feed>
# ignore pertains to version to ignore. Supports globs. Example:
- vendor: somevendor
# aliases/historical renames and/or multiple vendor/products in a single package
- vendor: someoldvendor1
- vendor: someoldvendor2
Make the implementation that looks up CPE strings construct a WFN as a FSB with a hardcoded prefix of
cpe:2.3:a and tack on the
product: values from the security/cpe section.