From 3939ea9d5e729a0f05abc2e360f74087f5d5feb4 Mon Sep 17 00:00:00 2001 From: Dan Luhring Date: Wed, 10 Jul 2024 09:36:12 -0400 Subject: [PATCH 1/3] add clarity around distros' use of aliases Signed-off-by: Dan Luhring --- docs/schema.md | 18 ++++++++++++------ 1 file changed, 12 insertions(+), 6 deletions(-) diff --git a/docs/schema.md b/docs/schema.md index f2c7bbab..f3bdbdf1 100644 --- a/docs/schema.md +++ b/docs/schema.md @@ -460,11 +460,11 @@ databases, in the form of the `id` field. This allows one database to claim that its own entry describes the same vulnerability as one or more entries in other databases. -Two vulnerabilities can be described as aliases if a potential patch that -addresses one of the vulnerabilities (and no other vulnerabilities) will also -address the other vulnerability, and vice versa. Aliases may be used for -vulnerabilities affecting different packages or ecosystems as long as they -follow this definition. +Two vulnerabilities can be described as aliases if they affect any given +software component the same way: either both vulnerabilities affect the software +component or neither do. And, consequently, a potential patch that addresses one +of the vulnerabilities (and no other vulnerabilities) will also address the +other vulnerability, and vice versa. Aliases should be considered symmetric (if A is an alias of B, then B is an alias of A) and transitive (If A aliases B and B aliases C, then A aliases C). @@ -475,6 +475,13 @@ vulnerabilities as `aliases` would mean that they are all identical (due to the symmetry/transitivity of `aliases`), not that one release fixes multiple (distinct) vulnerabilities. +Aliases should **not** be used to refer to vulnerabilities in packages upstream +or downstream in a software supply chain from the given OSV record's affected +package(s). For example, if a CVE describes a vulnerability in a language +library, and a Linux distribution package contains that library and therefore +publishes an advisory, the distribution's OSV record must not list the CVE ID as +an alias. (It should use the `related` field instead.) + ## related field ```json @@ -1613,4 +1620,3 @@ When a package in the `Android` ecosystem is the Linux kernel source code, its ` - NVIDIA - Qualcomm - Unisoc - From f84a635d0c0de333237efc2772b0ddc435c87a1a Mon Sep 17 00:00:00 2001 From: Dan Luhring Date: Thu, 11 Jul 2024 09:45:55 -0400 Subject: [PATCH 2/3] reword sentence about patching aliases Signed-off-by: Dan Luhring --- docs/schema.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/docs/schema.md b/docs/schema.md index f3bdbdf1..300de31f 100644 --- a/docs/schema.md +++ b/docs/schema.md @@ -462,9 +462,8 @@ databases. Two vulnerabilities can be described as aliases if they affect any given software component the same way: either both vulnerabilities affect the software -component or neither do. And, consequently, a potential patch that addresses one -of the vulnerabilities (and no other vulnerabilities) will also address the -other vulnerability, and vice versa. +component or neither do. A subsequent patch addresses both of the +vulnerabilities (and no others), and vice versa. Aliases should be considered symmetric (if A is an alias of B, then B is an alias of A) and transitive (If A aliases B and B aliases C, then A aliases C). From 21cbf35d2fdb95320fa3aa97e3f3b079df090222 Mon Sep 17 00:00:00 2001 From: Dan Luhring Date: Thu, 11 Jul 2024 09:48:13 -0400 Subject: [PATCH 3/3] merge paragraphs on distro use of aliases Signed-off-by: Dan Luhring --- docs/schema.md | 9 ++------- 1 file changed, 2 insertions(+), 7 deletions(-) diff --git a/docs/schema.md b/docs/schema.md index 300de31f..d31ac268 100644 --- a/docs/schema.md +++ b/docs/schema.md @@ -468,18 +468,13 @@ vulnerabilities (and no others), and vice versa. Aliases should be considered symmetric (if A is an alias of B, then B is an alias of A) and transitive (If A aliases B and B aliases C, then A aliases C). -Aliases should **not** be used in records that bundle many different -vulnerabilities in one patch of a distribution of a package. Listing multiple -vulnerabilities as `aliases` would mean that they are all identical (due to the -symmetry/transitivity of `aliases`), not that one release fixes multiple -(distinct) vulnerabilities. - Aliases should **not** be used to refer to vulnerabilities in packages upstream or downstream in a software supply chain from the given OSV record's affected package(s). For example, if a CVE describes a vulnerability in a language library, and a Linux distribution package contains that library and therefore publishes an advisory, the distribution's OSV record must not list the CVE ID as -an alias. (It should use the `related` field instead.) +an alias. Similarly, distributions often bundle multiple upstream +vulnerabilities into a single record. `related` should be used in these cases. ## related field