Reporting and Managing Security Issues in Eclipse Foundation Projects

The process for reporting and managing security issues in Eclipse Foundation projects is similar to, though not exactly the same as, managing other kinds of bugs in projects. While security issues are made public (as any other bug report), they do cause a potential threat to users and their data. This is why more discretion is required before a fix is available.

It’s important for committers to understand this process in the event someone reports a vulnerability in the project to which they contribute. In this article, we’ll outline how vulnerabilities are reported and explain why specific steps are necessary. 

Security Issues Are Just Another Kind of Bug

In general, a bug is considered a security issue when it’s a threat to confidentiality, integrity, or availability (CIA). Simply put, this means there’s a way for an attacker to access systems they shouldn’t, modify your code (or any other data) without your knowledge or permission, or control the ability of authorized users to access data. 

When discovered, vulnerabilities can be reported either via email to security@eclipse-foundation.org or directly with a project via the Eclipse Foundation’s issue tracker. Initial disclosure is generally limited to the reporter, the project team, and the Eclipse Foundation security team. It only becomes public when the project releases a fix, and in 90 days from the report. The details of the timing and manner of disclosure is governed by the Eclipse Foundation Vulnerability Reporting Policy.

Ensure Access to Confidential Reporting

Because exploited security issues could cause harm, your project has a vested interest in making sure reporters can flag problems confidentially. This way attackers can’t learn about the issue and take advantage.

The people reporting vulnerabilities are generally developers working on other projects, users, or security researchers. Many reports come from this last group.

Security researchers often seek credit for reporting the vulnerability, with recognition being understood as a reward for their work. They typically work on their own schedule and may have a fixed publication date due to their work on your project being part of a larger project that they’ve submitted to a security conference or similar undertaking. More likely than not, they do not know the internal workings of your project. Many security researchers are students, often working on a Ph.D. or Master’s degree.

Fortunately, these researchers do typically prefer to report issues confidentially. Generally, they’ll start by looking into the Git repository of the project for a SECURITY file where they can find instructions. If they can’t find the information in the repository, they’ll often look at the website and then at the project documentation. Failing all that, they’ll likely either post the issue information on a communication channel like IRC, or create a public issue in your bug tracker — both of which we want to avoid. 

That’s why it’s important to make sure reporters can easily and confidentially report issues. Having a security page on your website with instructions and/or a link to the managing and reporting section of the Handbook is a great way to do this. We also recommend having a chapter on security in your project documentation. The earlier in the process the reporter can find out how to report the issue confidentially, the more likely your project is to get confidential reports. Also note that should the report come to the Eclipse Foundation security team, they will notify your project. 

Confirm and Name Issues 

Once you’ve received a report about a potential issue, the next step is to reproduce it. If they haven’t included it in their initial communication, it’s a good practice to request the procedure used that revealed the issue. Confirming the issue within 48 hours is ideal, while best practice is to confirm within a week. Remember that reporters are doing you a service by reporting the issue directly..

Since the Eclipse Foundation is a Common Vulnerabilities and Exposure (CVE) Numbering Authority, project teams can request a CVE number directly from the Eclipse Foundation. These numbers help with discussion and documentation by providing a known issue with a common identity. When in doubt, request a CVE. The security team will keep the number confidential until the project team gives approval to publish it. 

The following information is required for a complete CVE request (you can always update the information when you have learned more during the investigation):

• The name of the impacted project and product
• Version numbers impacted
• A Common Weakness Enumeration (CWE) code
• A short summary of the issue 
• A URL pointing to the issue being used to track the vulnerability mitigation effort

You can request the assignment of the CVE ID at any time after confirming the security issue. Earlier requests allow easier coordination for publication and more time for the Eclipse Foundation security team to help with editing the issue description.

Once the issue has been confirmed, you can start the fix. In general, fixes should be published within 90 days. There are a few best practices to keep in mind:

• Develop your fix in a private or local branch.
• Use generic terms in your comment messages and pull requests — don’t use the CVE number before it becomes public.
• Merge the fix as usual, perform the code review, and avoid regressions.
• Create a release and backport the fix to all supported branches.

It’s very important to do a new software release after you have a security fix. Most users rely on releases, and applying patches is generally only acceptable for very complex fixes in urgent situations. 

Updated Procedures Available

The Eclipse Foundation Project Handbook, which explains the full procedure for reporting and managing security vulnerabilities, was updated recently. It describes the process in more detail and in more stages, so it’s worth reviewing. 

The new generic issue tracker for security reports replaces the old one from Bugzilla. If a project wants to use their own issue tracker, or GitHub private security advisories, they should contact the security team.

For CVE ID requests, you can find a template form at GitLab. 

The Eclipse Foundation security team has also created a best practices repository, with more information to come. 

For any questions or clarifications, you can always contact the Eclipse Foundation security team directly or create a help desk ticket:

• Use a separate issue tracker for your project
• Use GitHub Security Advisories
• Get help with best practices like secure code practices or setting up tools for your projects (e.g., Dependabot on GitHub)
• Get advice on communicating with reporters
• Get direction on assigning CVEs or writing advisories