Thanks for the feedback @ljharb!
We currently @ mention the author and/or publisher of the vulnerability if they created it on GitHub (otherwise we don't have the data). Are you saying you'd prefer we notify everyone listed in the CODEOWNERS file?

ah, then maybe you've already set up what i'm hoping for :-) i don't actually care if it's CODEOWNERS or not, i just want to be sure that i don't miss any activity that affect packages I maintain.

Sounds like we've got you covered here! But don't be shy to share feedback if it's not working for you. Thanks @ljharb!

Great feedback, thank you! I'll write up an issue to address it.

We've picked this up to ship and it should be changed shortly!

With a slight change– Decided to make the PR title the same as the advisory title as that will hopefully be an equally good at-a-glance reminder and frequently includes the ecosystem/package name/vuln type regardless. Let me know if that works or is still not solving the problem.

I’ll take a look once it’s shipped, but that sounds workable!

Shipped! 🚀

Thanks @MTRNord, great feedback. Got a ticket written to address this and we'll get it fixed asap.

I help triage advisories for the Python Packaging Advisory Database and it would be really great to have a way to get GHSA entries created for anything that doesn't yet have one and is deemed valid (and if it turns out we have something that shouldn't be there, we can get it withdrawn from ours)

Hi @westonsteimel thanks for reaching out!

Has there been any discussion about how to go about contributing an entirely new advisory

Most definitely!

If you are the package maintainer, you can already create a new security advisory and even get a formal CVE number through our repository security advisory feature.

If you are not the package maintainer, we are brainstorming a possible feature to report a new vulnerability for the maintainer to review. This is still in its initial idea stages and will be separate from this community contribution feature.

for instance some historical CVE that just hasn't been tagged with specific package information

This part is possible now. Our new unreviewed category is filled with advisories that are auto-imported from NVD and have not yet been tagged with the ecosystem and package information. Our Curation team does a pass through them to seek the ones that are part of our eight supported ecosystems (currently including Composer, Go, Maven, npm, NuGet, pip, RubyGems, and Rust), but of course, there could be more that we missed.

If you find one without a package name and it is part of our eight supported ecosystems, you can go through the community contribution process and add it as described above.

Right now our unreviewed category only goes back to November 2021, but we also have plans to backfill historical NVD advisories as well.

I hope I answered your question, but let me know if there's more I can clarify! We'd love to work with communities like Pypa to drive closer integration!

Thanks so much! Yes I think that covers it. I suspect that most of the cases where PyPA has one that GitHub doesn't fall before the November 2021 threshold, but I'll run some scripts later to have a look.

I find it similarly weird that GHSA-xvqg-mv25-rwvw is credited to a person who submitted an advisory suggestion but not to the original reporter. The credits section certainly gives the (wrong) impression that it's listing the vulnerability reporter.

@tony thanks for all the questions! I have answers for you...

Where does my security credit come from? Is it my vcs-python/libvcs#306 as the package maintainer or just me having a #108 in this repository?

Today you are getting that credit for having a contribution merged. It looks the same as the credit for having originally reported it and being given credit on the original security advisory. We agree @dkasak that this is weird, so we're changing it! I don't want to commit to ship date too soon but this is on our roadmap to differentiate types of advisories.

Can it be credited to the finder @dellalibera also, or in my place?

Not right now. But giving credit to others is a functionality we'd like in the future too.

Can an auto-imported security advisory be attached to a github repository?

Again, not yet. But great suggestion for the future.

Tried that too, and it didn't work. Same error.

@GrahamCampbell I am pretty sure it's due to needing a space between the range operator >= and the version string 3.0.0

if so, i'd encourage you to use https://npmjs.com/semver for that form (http://semver.npmjs.com for a demo) which is more forgiving :-)

We'll log an issue about making that a little more obvious, or better yet fix it automatically.

@ljharb just an overeager regexp IIRC 🤣 😭

Great idea, thanks @Bibo-Joshi! We're still actively iterating on these advisories so I'll add that to the list of papercuts to address. Appreciate it!

That's great feedback @kornelski, thank you. We've been toying with the idea of adding a comments section so that's good evidence to do so.

For now, you can submit it and when it opens a pull request you can edit the pull request description with the explanation. But I agree that not everyone may know that's a possibility and something more inviting would help.

This is a massive problem in the npm ecosystem as well; it reflects a fundamental flaw in the architecture of the CVE ecosystem.

If I get one more alert about a non-exploitable ReDoS in a transitive dependency, I am going to scream. It has been almost two years since https://overreacted.io/npm-audit-broken-by-design/, and nothing has changed.

Advisories imported from NVD which are not from one of the "supported
ecosystems" can't currently be edited and improved

I just hit this issue as well when trying to update an existing advisory:

• [GHSA-2q4h-h5jp-942w] Firejail before 0.9.64.4 allows attackers to bypass... #1814

Related discussion:

• Include more details in "unreviewed" advisories #568

Surely such advisories should still be editable? Should also consider having
an Other ecosystem for stuff that doesn't fit elsewhere, such as C
projects.

+1

@KateCatlin

@dkasak that's a major issue we're toying with as all contributions right now
are reviewed by our highly-trained curation team. That's why we gate it to
only supported ecosystems because our Curators can only be experts on so
much.

I see, but that might not be necessary for more trivial contributions.

For example, in the PR above, I think that being familiar with git should be
enough to review the changes, as it's more about adding missing information
rather than changing the explanation/metrics/score or anything of the sort.

Still trying to find creative solutions for the future though... perhaps a
category like "Unreviewed but edited" or something? What do you think?

Currently the advisory already mentions the following:

This advisory has been edited. See
History.

So if anything, it might be better to improve the commit messages from the
advisory-database bot to clarify what each one is about (and include a link to
the pull request if applicable). Example commit message titles:

• Advisory Database Sync (NVD)
• Update schema_version
• Review GHSA-XXX
• Edit GHSA-XXX

But if you must do something with the fields, I think it would make more sense
as a separate field, since it's arguably something that can happen
independently of when/if an advisory is officially reviewed by GitHub. That
is, community edits can happen multiple times, including after an advisory is
reviewed.

Example fields:

• Reviewed by GitHub: yes/no (type:reviewed / type:unreviewed)
• Edited by the community: yes/no (is:changed / is:unchanged)

(By the way, I find the current type:(un)reviewed a bit confusing, as being
reviewed or not seems more like a status:, though it might be unfeasible to
change it now)

But implementation details aside, I wouldn't consider that a blocker (having
Other as the ecosystem would be enough).

As a user and as someone involved with a project (rather than a being a
reviewer, for example), the key part to me would be enabling contributions to
existing advisories.

I decided to add a link to fix commit in GHSA-vf42-37cv-443p, but it doesn't allow me to do so without selecting Ecosystem->Affected products. The vulnerability is related to free-bsd, we can't categorize it.

@JafarAkhondali apologies, but we scope ourselves to a set of ecosystems that we know we can provide high quality advisories for and we do not support free bsd at the moment.

https://github.com/github/advisory-database/?tab=readme-ov-file#supported-ecosystems

I'm hitting the same issue: I cannot improve GHSA-jm46-725r-hh9v (to correct which versions of cpython are affected) because it forces me to choose "Affected products" where python is not an option (only pip).

If the GHSA page is going to exist, it should be possible to improve/correct it - so is this a bug, or should that GHSA not exist?

This issue also happens with the "Title" field, I can't improve an untitled advisory without having to give it a title as well.

Great feedback, thanks @lukaseder. I'll pass this along to our Dependabot team.

hi @lukaseder 👋 I wanted to follow up and let you know that the ability to snooze a Dependabot alert until a patch is available was beta released yesterday at the repository level 😄

That's a very useful addition, thanks a lot for pinging me about it, @taladrane!

I've settled for adding a link to the CHANGELOG as a reasonable work-around. But it would be great to handle these alongside other issues without manually creating and linking a new issue.

Hey @edthedev! Thanks for reaching out. Would you want that 'convert to issue' button to be on an advisory listed at https://github.com/advisories? Or do you want that to exist on a Dependabot alert within your repository?

@KateCatlin I would want the 'convert to issue' button on the Dependabot alert within my repository. That way it can flow through the usual issue tooling we have setup on that repository. We do get this benefit when Dependabot can open a pull request, since a pull request is also an issue. But when Dependabot cannot create a pull request, a 'convert to issue' button on the advisory would be very welcome.

Got it thank you @edthedev! I'll pass that request along to the appropriate PM internally here!

then why bother importing it in the first place? having stale/incorrect advisory information is worse than not having it

Importing them in the first place is really important because the community can't submit enhancements to historical data if an advisory doesn't already exist in the database. I think GitHub have done an excellent job in bringing these in and building such great tooling for contributing enhancements back to the dataset. I agree having a process to keep unreviewed and unmodified advisories in sync would be ideal, but bringing them in as-is and clearly labelling them as unreviewed seems a very reasonable initial approach to me.

observation during log4j, after months of the upstream advisory had been changed to indicate that originally proposed mitigation measures were inadequate, people were still applying them due to sites with out of date information as you propose to have, and claiming they had addressed the vulnerability while the opposite is the case.

How is one more site with out of date/incorrect vuln advisories going to help? Why not spend the time and energy of having 1 correct and up to date authoritative source?

but bringing them in as-is and clearly labelling them as unreviewed seems a very reasonable initial approach to me.

Heavily disagreed. When you have prominence on the level of Github, you simply cannot afford to be distributing outdated and inaccurate information. Since in this instance Github is in the business of mirroring information from an upstream rather than being an upstream itself, the first reasonable iteration ought to be the one in which you have the ability to automatically pull upstream revisions.

I agree with all of you. It's our mission as a database to serve up the most accurate information we can, and that's what we work to do every day. Clearly this initial approach is not cutting it and we absolutely should be auto-merging all updates on unreviewed advisories.

I did update my comment above with some more complete information, which is that we auto-merge updates to unreviewed advisories today if the information is purely additive. However, if the update would overwrite existing data we do not merge it because it was historically decided that it must have human eyes on it, and we couldn't manually review it and keep it in the unreviewed category.

That said, we still want to get this resolved! I've already discussed this with the team. As soon as we have an available engineer, we'll be fixing this. I'll return back to this thread and update you all when that's shipped!

Hey @richardfan0606. thank you for the corrections on GHSA-5229-94p3-7wwq, GHSA-4w23-c97g-fq5v, and GHSA-wrxc-mr2w-cjpv. Those three do have erroneous packages listed. I've gone ahead and updated our data to reflect the correct packages.

GHSA-m56g-3g8v-2rxw has been withdrawn as a dupe of GHSA-9pgx-gcph-mpqr which does have vrana/adminer listed as the affected package.

To directly answer

Can we suggest a standard of the package names for each type?

We use the package names for the backing registries (packagist.org in this case). The full list is here https://github.com/github/advisory-database/#supported-ecosystems

Thanks for the feedback @vancluever, I'll check in on that.

Out of curiosity, what was the discussion that helped you resolve your question?

@KateCatlin unfortunately I don't have the exact advisory anymore, but ultimately I made my way to the advisory DB repository where I was able to search for the advisory number and determine that there was already progress towards correcting it.

Hope that helps!

Awesome, thanks for letting me know!

Hey @vin01, as of today there is no way to exclusively request credit on an advisory.

However, if someone submits a community contribution that improves an advisory and it is accepted by our Curation team, they will then be given credit on an advisory with the analyst credit type.

Allowing folks to request reporter credit is a feature we'd like to build in the future! In the interim, I would suggest doing as much of your reporting as possible through our new private vulnerability reporting feature so that reporter credit is automatically applied.

thanks for the prompt response, appreciate it.

I usually do try to follow the private reporting feature but not all projects use it, for e.g. in Rust ecosystem, reporting via RUSTSEC is mostly how it works: https://rustsec.org/contributing.html

Love to hear that! Thanks @vin01!

@medikoo can you elaborate on what you mean? Different version ranges should be expressed as the same affected product on a new line with a new range attached. We do still support that if that's what you're getting at.

@darakian See #2901. The form for PR (https://github.com/advisories/GHSA-c59h-r6p8-q9wc/improve), accepts single range for "Affected versions" and inputs as >=0.9.9 <13.4.20-canary.13 or 0.9.9 - 13.4.20-canary.12 are not accepted.

I see that in PR you've suggested to separate ranges with coma, but it's not valid per semver range spec, see e.g. https://devhints.io/semver

Not all of our ecosystems follow semver which may be the root issue here, but glad you got it working 👍

Hey @retr0reg , we took a look and fixed it! You should see your credit show up in all the right places now!

@KyLeggiero can you clarify what you're talking about here? Are you looking for Dependabot alerts to ignore these lock files?

Yes. For example, I have several sites which have a Gemfile that only contains gem 'github-pages'. When Github Pages builds this site, in the backend, it generates a Gemfile.lock for itself before shutting down its generator and serving the static files.

Eventually, something like nokogiri has a vulnerability. My Gemfile doesn't mention it at all; all my code says is to use the latest version of Github Pages.

This results in Dependabot sending me alerts for dependencies like nokogiri (which I genuinely have no clue what that is), and then when I tell it to show me the problem it fails because that code it's calling out doesn't exist in my repo.

The vulnerability only exists in some dependency that is technically related to my code on Github's backend, but doesn't actually matter because no code actually runs on my site. Github's backend runs the generator and then shuts down, and my Gemfile already says to use the most-recent version of everything, so next time it runs it'll be using the most-recent version of these dependencies and all will be right with the world.

@KyLeggiero OK, thank you for the clarification!

@JafarAkhondali I recommend creating an issue with the details and my team will take a look!

Hi @retr0reg , please submit a ticket in our customer service portal for action here.