Include publishing a GitHub Security Advisory in the triage process

[esarafianou]

When a vulnerability is submitted in the Node.JS Ecosystem, it's triaged, assigned a CVE and then the HackerOne report is publicly disclosed. One piece that I think is important to add is working with the maintainer so that they release a security advisory in GitHub. We could work on a Security Advisory template that we'll be using when assisting the package maintainers to publish a security advisory under their repo.

Advantages Although the triage and co-ordinated disclosure happens in HackerOne, publishing a Security Bulletin in the repository once the CVE is assigned and the HackerOne report is published helps the project's community know about the vulnerability, research the impact of the security vulnerability and update the package to a secure version.

Disadvantages This will increase the work needed for the triage team, as it adds an extra step.

What do other people think?

[lirantal]

That's a good idea in terms of promoting the awareness and attention of maintainers, but I'm wondering won't maintainers already have this information? Part of the triage process is adding them to the issue so they should be aware?

I agree with the second part where the community receives a security bulletin through GitHub. If we can get some help from H1/GitHub folks to help build this I think it could be interesting. On the other side, we already know pretty much agree in other issues to stop maintaining the whole security-advisories db from the WG due to the work involved, and I don't think it makes sense to start a new project to maintain. GitHub should be able to pull data from H1 on their own to run those security bulletins.

[MarcinHoppe]

There is a parallel effort going on under the Open Source Security Coalition to document a data format that would allow automation between H1 and GitHub to work.

In the meantime, if we worked towards publishing GitHub maintainer advisories, we'd make it easier for two popular SCA tools (GitHub security alerts and npm audit) to consume this data, without having to maintain the 3rd party vulnerability database.

The only challenge I see is that maintainers are already busy as they are, and requesting them to perform one additional step might be much, especially if they have never written a security advisory and are not sure where to start.

I feel this is something we could help with, if the tooling allows for this. I am not quite sure if I, as a complete stranger, can open up a security advisory for any GitHub repo?

[fraxken]

Interesting topic. Any news on this? There are probably things that have evolved in two years!

Today github seems to me quite efficient at reporting CVE, no? (However I never experienced a vulnerability in one of my project so I can't tell about this).

[lirantal]

GitHub isn't actually handling disclosures and creating a "security bulletin" is relevant for when maintainers are either starting that process on their own or more likely, getting pinged directly about it. I'm not sure to say how much either of these is happening to merit the work here but if we'd want to offer some sort of template or training as the scope of this issue then that might be a good one to take on.

I'll also share this with the GitHub crew and see if there is more input beyond what I'm aware of on this topic.

[github-actions[bot]]

This issue is stale because it has been open many days with no activity. It will be closed soon unless the stale label is removed or a comment is made.