Consolidate security advisories, revise security policy

[achrinza]

Currently, security advisories are inconsistently documented here and here (for older lb2 vuln.).

They are also not known to the Node.js Security WG.

This may obscure security advisories from the end-user as they may depend on the messages appearing on npm install or npm audit, or through third-party tools such as Snyk.

From the Security | Node.js page:

Security bugs in third party modules should be reported to their respective maintainers and should also be coordinated through the Node.js Ecosystem Security Team via HackerOne.

Suggestion

1. Consolidate security advisories

   The lb2 security advisories should be consolidated to the main security advisory page.

2. Revise security policy

   In the spirit of fostering a safe, FOSS ecosystem, the project should adopt the Node.js Security WG Responsible Disclosure Policy to leverage a trusted vulnerability-reporting platform and bug bounty program (Node.js HackerOne programme).

3. Re-disclose old vulnerabilities

   Existing vulnerabilities should be re-disclosed to the Node.js Security WG via HackerOne

   • [ ] Security advisory 08-15-2018 (Not disclosed yet)
   • [ ] Security advisory 08-08-2018 (Not disclosed yet)
   • [ ] Security advisory 06-17-2019 (Disclosing....)
   • [ ] Security advisory 01-31-2018 (Not disclosed yet)
   • [ ] Security advisory 10-24-2017 (Not disclosed yet)
   • [ ] Security advisory 09-21-2017 (Not disclosed yet)
   • [ ] Security advisory 03-10-2017 (Not disclosed yet)
   • [ ] Security advisory 08-16a-2016 (Not disclosed yet)
   • [ ] Security advisory 08-16-2016 (Not disclosed yet)
   • [ ] Security advisory 01-12-2016 (Not disclosed yet)
   • [ ] Security advisory 06-04-2015 (Not disclosed yet)
   • [ ] Security advisory 01-09-2015 (Not disclosed yet)

4. Add a Responsible Disclosure badge:

   

Existing Examples

Express (which was under IBM) adopts a variant of the policy. Though the Node.js Security WG encourages coordination via HackerOne.

Acceptance criteria

TBD - will be filled by the team.

[bajtos]

Thank you @achrinza for taking the initiative to improve our docs related to security policy. I'll try to review the changes by the end of this week. I think we will need to get an approval from @raymondfeng and @dhmlau too.

[sam-github]

I'm not convinced the actions here and in the associated PR are all necessarily improvements.

Currently, security advisories are inconsistently documented

Perhaps the lb version advisories should cross-link, but having the advisories collected in a way specific to the LB versions seems like a feature to me.

https://loopback.io/doc/en/sec/index.html is a pretty clear location for responsibly disclosed and clearly documented reports of vulnerabilities.

This may obscure security advisories from the end-user as they may depend on the messages appearing on npm install or npm audit ... or Snyk

Describing npm install as obscure seems a reach to me, its the only way to install loopback, and npm does a sec audit implicitly on every install! Its how most people will know there is a report.

If loopback sec advisories are somehow not showing up in npm audit results, then I would definitely agree that is a problem, and ideally the npm reports that show up link to the loopback security reports.

Security bugs in third party modules should be reported to their respective maintainers and should also be coordinated through the Node.js Ecosystem Security Team via HackerOne.

I help maintain that policy, and it wasn't my understanding that we should be encouraging projects that are sucessfully accepting, fixing, and disclosing vulnerabilities (like Loopback) to modify their process and start to depend on a team external to the project (the ecosystem-security-wg) to manage vulns. Its more intended to outsource security best-practice for packages that haven't established a security policy.

Revise security policy

Its not necessary to disclose vulns to the ecosystem-sec-wg, it is mostly used as an upstream to npmjs.com sec advisories. snyk might pull from it as well.

Express ... adopts a variant of the policy

I don't think that is accurate. https://github.com/expressjs/express/blob/master/Security.md says

Report security bugs in third-party modules to the person or team maintaining the module. You can also report a vulnerability through the Node Security Project.

Note that the Node Security Project was acquired by Npmjs.com, and that link now redirects to the top level of npmjs.com, which is not so useful.

Express' policy is much like loopback's: https://loopback.io/doc/en/sec/index.html#how-to-report-a-security-issue

I do agree that https://github.com/strongloop/loopback (and all the repos, actually) should have a top-level SECURITY.md file (and it should point to the link above, or possibly loopback version specific links, so the policies are clearly consolidated and identical).

It might also be useful to use https://help.github.com/en/github/managing-security-vulnerabilities/about-github-security-advisories to manage the discussion, fixing, and eventual disclosure of vulnerabilities. It might even be worth looking into some kind of unification of github advisories with the ones at https://loopback.io/doc/en/sec/index.html

Add a Responsible Disclosure badge:

That could be done now, Loopback does responsibly disclose vulnerabilities.

[achrinza]

Thanks @sam-github for the extremely detailed feedback;

Perhaps the lb version advisories should cross-link, but having the advisories collected in a way specific to the LB versions seems like a feature to me.

I think that's a good idea. The concern right now is that its inconsistent: some vulnerabilities across different LoopBack versions are consolidated into the same page, some from LoopBack 2 are in a separate page than the rest without any link between these pages.

If loopback sec advisories are somehow not showing up in npm audit results, then I would definitely agree that is a problem, and ideally the npm reports that show up link to the loopback security reports.

Apologies my wording was convoluted, I believe that they are indeed showing on npm audit.

it wasn't my understanding that we should be encouraging projects that are successfully disclosing ... vulnerabilities (like Loopback) to modify their process and start to depend on a team external to the project (the ecosystem-security-wg) to manage vulns.

Seems like I misunderstood the purpose of the Node.js hackerone platform based on the wording from the Node.js website.

My impression is that the platform is meant to consolidate and standardise the disclosure process so as to make it easier for people to report security vulnerabilities.

The platform tends to provides more transparency in how well the disclosure process was handled as it provides a single pane of glass to view the security reports and response rates.

Furthermore, since hackerone can issue CVEs, it'll increase the visibility of the security advisory to other non-npm platforms (e.g. IBM xForce Exchange).

AFAIK, only issues that affect IBM API Connect are issued CVEs: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=ibm+loopback

I'm not sure how many people leverage a CVE database for NPM third-party package vulns, but it may be a good idea to do so since the hackerone platform does so.

Since GitHub is also a CVE issuer, perhaps we could leverage it instead?

Its not necessary to disclose vulns to the ecosystem-sec-wg, it is mostly used as an upstream to npmjs.com sec advisories. snyk might pull from it as well.

How LoopBack disclose the vulnerability to npmjs.com sec advisories doesn't seem to be well-documented. Perhaps adding more details on the disclosure process might be beneficial.

Note that the Node Security Project was acquired by Npmjs.com, and that link now redirects to the top level of npmjs.com, which is not so useful.

Apologies, it seems that I mixed up Node.js WGs with npmjs.com

That could be done now, Loopback does responsibly disclose vulnerabilities.

+1 for the badge

Overall, I agree with a lot of your points, though I think we could benefit from providing more transparency on disclosure process, and my initial thought was that the hackerone platform provided that in a convenient package based on the Node.js website

[sam-github]

Apologies, it seems that I mixed up Node.js WGs with npmjs.com

Its genuinely confusing! :-) There used to be a Node Security Project, and they donated a snapshot of the DB to the ecosystem-sec-wg, and then the nsp project's parent company was acquired by npmjs.com, so there could be said to be two "inheritors" of the project. At this point (not when the wg was founded) npmjs.com has package audit and sec reporting capability, it didn't used to. I'm not saying that the sec-wg is in any sense obsolete, but a project not using it in no way makes them non-standard.

So, lets focus on the concerns with the current lb process. :-)

The concern right now is that its inconsistent: some vulnerabilities across different LoopBack versions are consolidated into the same page, some from LoopBack 2 are in a separate page than the rest without any link between these pages.

I'm not clear on what the concern is. If you use lb2, why would you want to know about lb3 vulns? Seeing them seems at best distracting, at worst, confusing if you fail to notice they don't apply to lb2.

Since GitHub is also a CVE issuer, perhaps we could leverage it instead?

Lack of CVEs could be considered an issue. not everyone uses them, but those who do use them, like to have them for all vulns. :+1:

How LoopBack disclose the vulnerability to npmjs.com sec advisories doesn't seem to be well-documented.

That should be clear in the SECURITY.md (or where it links to). :+1:

I think we could benefit from providing more transparency on disclosure process

That should be crystal clear, yes. :+1:

Perhaps something could be said about how any vulns that are reported will eventually be publicized?

[bajtos]

Great discussion!

I see few semi-independent topics to discuss and improve:

1. What responsible disclosure process we want to use. Are we fine with the current email-based one or are there compelling arguments to start looking for a different option (e.g. HackerOne)?

2. What is our process for handling security reports and fixing them in a responsible way, so that the information is not leaked before the fix has been published.

3. What is our process for reporting fixed security vulnerabilities. Where are they published (reported to), who and how is responsible to perform the necessary actions.

   Some of the options where to publish:

   • LB docs
   • IBM Security (see PSIRT)
   • GitHub security advisories
   • npm and/or Snyk security advisories
   • Node.js' ecosystem-sec-wg.

4. Proper documentation. I think we need few pieces of content for different personas involved in security:

   1. As a security researcher who found a vulnerability in LoopBack, how can I disclose the problem responsibly?

   2. As a LoopBack maintainer handling a security vulnerability, how should I send a fix, so that it can be reviewed by other maintainers and tested by our CI, while preserving confidentiality?

   3. As a LoopBack maintainer that has fixed a security vulnerability, where and how should I report it?

   4. As a LoopBack user, how and where can I learn about new security vulnerabilities that may be affecting by applications?

   5. As a (potential) LoopBack user auditing project security standards, where can I find details on the topics above?