Remove rejected CVE alias and switch to upstream CVE reference#6507
Closed
mswilson wants to merge 1 commit intogithub:mswilson/advisory-improvement-6507from
Closed
Remove rejected CVE alias and switch to upstream CVE reference#6507mswilson wants to merge 1 commit intogithub:mswilson/advisory-improvement-6507from
mswilson wants to merge 1 commit intogithub:mswilson/advisory-improvement-6507from
Conversation
Per the OSV schema: https://ossf.github.io/osv-schema/#aliases-field 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. Similarly, distributions often bundle multiple upstream vulnerabilities into a single record. To refer to these upstream vulnerabilities, `upstream` should be used.
github-actions
bot
changed the base branch from
main
to
mswilson/advisory-improvement-6507
Author
|
I guess GitHub hasn't merged in the |
mswilson
added a commit
to mswilson/advisory-database
that referenced
this pull request
Dec 4, 2025
…lated ID for React upstream CVE-2025-55182 Per the OSV schema: https://ossf.github.io/osv-schema/#aliases-field 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. Similarly, distributions often bundle multiple upstream vulnerabilities into a single record. To refer to these upstream vulnerabilities, `upstream` should be used. However, from github#6507 we see that the GitHub advisory database doesn't currently support `upstream` so we'll add a `releated` ID instead.
Author
|
closing in favor of #6509 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Per the OSV schema:
https://ossf.github.io/osv-schema/#aliases-field
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. Similarly, distributions often bundle multiple upstream vulnerabilities into a single record. To refer to these upstream vulnerabilities,
upstreamshould be used.