Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Vulnerability Disclosure #322

Open
juanis2112 opened this issue Jun 5, 2024 · 8 comments
Open

Vulnerability Disclosure #322

juanis2112 opened this issue Jun 5, 2024 · 8 comments

Comments

@juanis2112
Copy link
Member

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

@pllim
Copy link
Contributor

pllim commented Jun 5, 2024

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
Copy link
Contributor

pllim commented Jun 5, 2024

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?

@tupui
Copy link
Member

tupui commented Jun 5, 2024

... 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.

@pllim
Copy link
Contributor

pllim commented Jun 5, 2024

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."

@tupui
Copy link
Member

tupui commented Jun 5, 2024

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.

@bsipocz
Copy link
Member

bsipocz commented Jun 6, 2024

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)

@tupui
Copy link
Member

tupui commented Jun 6, 2024

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

@pllim
Copy link
Contributor

pllim commented Jun 6, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants