Motivation
@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).
Release Monitoring
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.
Terms
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
Discussion
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 application.
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.
Scalability notes
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:
Reilly Brogan
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.
Recommendation
Version: 5
Implement as a file called monitoring.yaml (which sits next to stone.yaml per recipe) with the following format:
releases:
id: <integer corresponding to package anitya id>
rss: <valid URI to RSS/ATOM release feed>
ignore:
# ignore pertains to version to ignore. Supports globs. Example:
- "253.*"
security:
cpe:
- vendor: somevendor
product: someproduct
# aliases/historical renames and/or multiple vendor/products in a single package
- vendor: someoldvendor1
product: someoldproduct1
- vendor: someoldvendor2
product: someoldproduct2
ignore:
- CVE-x
- CVE-y
- CVE-z
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 vendor: and product: values from the security/cpe section.
