Add SECURITY.md

[luigigubello]

Adding a security policy to the Eclipse Theia repository, copied from Eclipse Vulnerability Reporting Policy.

Signed-off-by: Luigi Gubello [email protected]

What it does

Adding a security policy to the repo. See also the discussion in issue #8795

How to test

Review checklist

• as an author, I have thoroughly tested my changes and carefully followed the review guidelines

Reminder for reviewers

• as a reviewer, I agree to behave in accordance with the review guidelines

[luigigubello]

eclipsefdn/eca is green 🎉 thanks @vince-fugnitto 🙏

[luigigubello]

Hi @marcdumais-work, hi @svenefftinge /cc @vince-fugnitto 👋👋

I have contacted the Eclipse Foundation Security Team to understand how to assign CVE IDs to some public vulnerabilities of Thea IDE. They have replied so:

[...] Using GitHub features to track and mitigate issues is supported.

So, you can also use Github Security Advisories to track the security issues of the project 🎉 I think this feature can really help the community.

In particular, about the CVE IDs, they have written:

When it comes to assigning CVEs, our process is that they must be requested by a committer. The project's process could be to use GitHub to track and mitigate the issue, and just use Bugzilla to request the CVEs. Since you're already in contact with the committers, the best way to proceed is to ask them to request a CVE assignment using the process defined in the handbook.

So, on the Eclipse Foundation site, I see that you - @marcdumais-work and @svenefftinge - are the project leads. Can you report in Eclipse Bugzilla the known Theia vulnerabilities and assign them a unique CVE ID?

I have created a list, but I'm not sure they are all the security issues missing a CVE ID:

Vulnerabilities:

Github issue: #8794
Status: Open
Title: XSS in Debug Console [Theia v1.8.0]
Date YYYY-MM-DD: 2020-11-29
Vulnerability type: XSS
Theia version impacted: <= 1.8.0
Resolution: Not fixed yet

Github issue: #7954
Status: Open
Title: [security] XSS vulnerability in markdown preview
Date YYYY-MM-DD: 2020-06-03
Vulnerability type: XSS
Theia version impacted: <= 1.2.0
Resolution: PR #7971

Github issue: #7283
Status: Closed
Title: Javascript injection via notification messages
Date YYYY-MM-DD: 2020-03-05
Vulnerability type: XSS
Theia version impacted: <= 0.16.0
Resolution: PR #7289

Github issue: #6987
Status: Closed
Title: [browser] XSS vulnerability in browser sidebar
Date YYYY-MM-DD: 2020-01-28
Vulnerability type: XSS
Theia version impacted: <= 0.14.0
Resolution: PR #6988

Github issue: #6976
Status: Closed
Title: [browser dialogs] XSS venerability in file dialog
Date YYYY-MM-DD: 2020-01-28
Vulnerability type: XSS
Theia version impacted: <= 0.14.0
Resolution: PR #6977

Cheers :)

[luigigubello]

Hi, any news about this PR?

[vince-fugnitto]

@brianking I'd like to know if you have any comments on the repository including the security.md (in order to highlight the process in which we report vulnerabilities) and if the foundation has a specific process we should use.

cc @marcdumais-work

[marcdumais-work]

cc: @waynebeaton

[marcdumais-work]

One concern I have is that, for this file to be meaningful, it needs to be maintained, going forward. There's a lot of project info in that file, that's already available on our Eclipse Foundation project page, as well as Foundation's documentation related to security vulnerabilities.

Potential compromise: link the content rather than copy it over.

[waynebeaton]

Having a project-specific security policy is a good idea.

Copying the Eclipse Foundation's policy doesn't add value. Worse, it adds a liability as the vulnerability management policy does change from time-to-time.

The project-specific security policy should describe how the project implements the foundation's security policy.

It doesn't have to be particular complex.

e.g.,

• Eclipse Milo
• Eclipse Leshan

Note that you do NOT have to use Bugzilla to track vulnerability mitigation. Our current process requires that a member of the project team use Bugzilla to request a CVE. The project team can, for example, decide to use GitHub security advisories.

[luigigubello]

Sorry for my late reply and thank you for your comments!
My2cents
I totally agree, a copy-paste of the Eclipse Foundation security policy doesn't add a real value to the project's security, but it is useful to have an "easy-to-find" security policy for an open-source project. For my personal experience, the Eclipse Foundation has already a well-written security policy, a process to assign CVE and a platform for tracking vulnerabilities (Bugzilla), but all this procedure is not user-friendly and it can be a friction for reporting a vulnerability. Theia IDE is open-source, and people can open issue or PR on Github, by disclosuring potential 0day of the project. It might be a good idea to have a SECURITY.md on Github that:

• links to the EF security policy
• gives a security contact (e-mail)
• defines a policy about vulnerabilities disclosured on Github (e.g. repo administrators could close and remove an issue or PR if it is disclosuring a new vulnerability, to better track it on Bugzilla)
• defines a standard time period to provide a solution or fix (usually 90 days)
• assigns a CVE to vulnerabilities and shows them on Github (using Github Advisories)

May it work?

[waynebeaton]

Please note that I've edited my previous comment to add an important "NOT" that was missing.

Note that you do NOT have to use Bugzilla to track vulnerability mitigation. Our current process requires that a member of the project team use Bugzilla to request a CVE. The project team can, for example, decide to use GitHub security advisories.

FWIW, the Eclipse Foundation is re-evaluating our process around assigning CVEs. We are, for example, exploring how we can more optimistically assign CVEs without necessarily waiting for the project team to make a formal request.

[waynebeaton]

The short version is that I don't believe that copying the EF's security policy adds value. What would be useful, IMHO, is a pointer to the EF policy, and description of how vulnerabilities should be reported and what the team will do with the report.

e.g.,

Request that the reporter identify the specific versions that they are aware are affected, provide a concise description of the issue, a CWE, and other supporting information.

Describe the circumstances under which a CVE will be requested.

[bobbyz007]

Any progress about this security issue: #8794？

[marcdumais-work]

Hi @luigigubello , @waynebeaton ,

FYI, I have a new, alternate PR, that adds a security policy to the repo:
#9804

I went with the essentials, taking inspiration from this PR here and the discussions above.