specs icon indicating copy to clipboard operation
specs copied to clipboard

Vulnerability Disclosure

Open juanis2112 opened this issue 1 year ago • 8 comments

We are doing some work at the summit on security best practices and vulnerability disclosure came up. So we'll add it as SPEC 11. Here's the scope for the spec:

  • Securicy policy (What should include and template)

    • Prominently document how to report vulnerabilities
    • Contact information
  • Enable private vulnerability reporting via API (GitHub Security Advisories for GitHub, Confidential Issues for GitLab)

  • What to do when you get a vulnerability report?

    • Use resources like the Guide to coordinated vulnerability disclosure.
    • Explicitly disclose security issues affecting vendored dependencies.
    1. acknowledge
    2. request cve
    3. share cve
    4. release (add cve number in the release notes)

This is the draft: https://hackmd.io/dZiPH2UDRXWtPg_-1af2Iw

juanis2112 avatar Jun 05 '24 00:06 juanis2112

Are there cases where the vulnerability does not deserve a CVE (i.e., issuing a CVE would be overkill and cause unnecessary panic from management)? If so, what are the guidelines?

pllim avatar Jun 05 '24 17:06 pllim

For severe cases, do we privately disclose the vulnerability to affected downstream first to give them a chance to patch things before we issue a public CVE? If so, how do we identify them (opt-in? opt-out? auto bot?) and what are the guidelines?

pllim avatar Jun 05 '24 17:06 pllim

... issuing a CVE would be overkill and cause unnecessary panic from management ...

I would disagree with that specific part. Security needs to become part of our workflow and we need to keep raising awareness on the matter. I am actually happy if management etc. gets panicked about security. It could help us steer security related topics.

tupui avatar Jun 05 '24 18:06 tupui

I am actually happy if management etc. gets panicked about security.

I think this is a double-edged sword. In OSS, the reaction could also be, "Oh no, look at how insecure this package X is, let's roll our own in a private repo."

pllim avatar Jun 05 '24 18:06 pllim

As someone working in a very regulated environment, this is actually something we want to see 😅 Companies who know what a CVE is, know the ins and outs of what this means.

tupui avatar Jun 05 '24 18:06 tupui

Companies who know what a CVE is, know the ins and outs of what this means.

Is this true for academic overloards and agencies? If not, this may more hurtful for the more domain specific libraries. (I don't know the answer, this really just thinking out load and stirring the pot)

bsipocz avatar Jun 06 '24 00:06 bsipocz

This is a question for you 😉 I can only speak for the business side (that I know of)

tupui avatar Jun 06 '24 07:06 tupui

Maybe @eteq can share his experience dealing with a more academic domain, if he doesn't mind. We went through this recently.

pllim avatar Jun 06 '24 14:06 pllim