Security Vulnerabilities Responsible Disclosure Policy

Introduction

This document defines a set of rules and policies established by FINOS to manage the lifecycle of potential vulnerabilities and security incidents within FINOS projects, aimed to guarantee...

1. Discretion for new and ongoing development activity around security vulnerabilities that haven't been published yet
2. Transparency and guidance around security vulnerabilities that have been identified, patched and released as new versions

It includes step-by-step guides on how contributors can setup a process to manage security vulnerabilities and how anyone can privately submit an undisclosed security vulnerability to a FINOS project.

Common Vulnerabilities and Exposures

The Common Vulnerabilities and Exposures (or CVE) is a dictionary that provides definitions for publicly disclosed cybersecurity vulnerabilities and exposures, although the term is normally used to identify CVE entries; each entry is comprised of an identification number, a description, and at least one public reference, you can check an example on the cla-bot project. Please note that the term security vulnerability also comprises undisclosed ones, as opposed to CVEs, which only refer to publicly disclosed entries.

For FINOS Open Source Consumers

An overview of the vulnerability handling process is:

• The reporter reports the vulnerability privately to a FINOS PMC.

• The appropriate project's team members works privately with the reporter to resolve the vulnerability.

• A new release of the FINOS product concerned is made that includes the fix.

• The vulnerability is publicly announced.

Browse security vulnerabilities for a project and release

Security vulnerabilities are published as GitHub Issues marked with the label security vulnerability. You can easily browse through the open and closed ones using the GitHub web UI.

Submit a new security vulnerability

To submit a new vulnerability, please follow these steps:

1. Identify the FINOS Project (project) related to the security vulnerability.
2. Identify the FINOS Program (program) related to the project.
3. Identify the private PMC email address from this list ; if you cannot find it, please use help@finos.org
4. Email the PMC privately with the description - and screenshots, if useful - of the vulnerability.

FINOS lifecycle

The responsible disclosure ties into FINOS Project Lifecycle in the following items:

1. All Incubating projects MUST have an automated way to manage security vulnerabilities, see below (as of Jan 1 2020, TBC)
2. All Active projects MUST have WhiteSource enabled (as of Jan 1 2020, TBC)
3. All projects publishing artefacts under FINOS package registries MUST have WhiteSource enabled (as of Jan 1 2020, TBC)

Collecting project CVE list

Since all CVE entries are labeled as security vulnerability, it is possible to use GitHub Issues UI to browse them.

Managing new vulnerabilities

A typical process for handling a new security vulnerability is as follows. Projects that wish to use other processes MAY do so, but MUST clearly and publicly document their process and have FINOS team review it ahead of time.

Accepting a new vulnerability

1. The person discovering the issue, the reporter, reports the vulnerability privately to the PMC Private list and cc's help@finos.org (or sends the email directly to help@finos.org)
2. The FINOS team will forward the report (without acknowledging it) to the private (PMC) mailing list.
3. The project team sends an e-mail to the original reporter to acknowledge the report, cc to help@finos.org and the private (PMC) mailing list.
4. The project team investigates report and either rejects it or accepts it.
5. If the report is rejected, the project team writes to the reporter to explain why. This e-mail must be cc'd to help@finos.org and the private (PMC) mailing list.
6. If the report is accepted, the project team writes to the reporter to let them know the issue has been accepted and that they are working on a fix.

Working on a fix

1. The project team agrees the fix, the announcement and the release schedule with the reporter. The level of detail to include in the report is a matter of judgement. Generally, reports should contain enough information to enable people to assess the risk associated with the vulnerability for their system and no more. Steps to reproduce the vulnerability are not normally included.
2. The project team commits the fix. No reference should be made to the commit being related to a security vulnerability.
3. The project team creates a release that includes the fix.

Apply fixes to all supported versions

As soon as the project team finds and implements a fix for the vulnerability, all supported versions (most likely GitHub branches) can be patched and released.

Publishing

1. The project team announces the release. The release announcement should be sent to the usual FINOS mailing lists.
2. The project team announces the vulnerability. The vulnerability announcement should be sent after, or at the same time as, the release announcement to the following destinations:
   1. GitHub Issues, reporting the following info:
      1. CVE ID in the title
      2. Apply label security vulnerability
      3. Specify which library is affected, if any
      4. Specify code line/block that causes the vulnerability
      5. Specify vulnerability details, including link to CVE description
      6. Specify fix (high level)
      7. Specify affected and fixed released versions
   2. The same destinations as the release announcement.
   3. The vulnerability reporter.
   4. help@finos.org
   5. Additional requirements for the emails sent to the above lists are:
      1. The subject must contain the name of the project and the CVE name(s), and should contain a short description of the issue(s), for example "Subject: [CVE-2007-5648] Apache Tomcat information disclosure vulnerability"
      2. The reply-to address should be appropriately set (e.g. the PMC public mailing list)
      3. The message body must contain details of the vulnerability, similar to what will be sent to The Mitre Corporation in the next step (not just a URL link to the details)
3. Any relevant project documentation page must be updated
4. The log for the Git commit that applied the fix is updated to include the CVE number. Projects that use git as their primary source code control system should not do this as editing a pushed commit causes all sorts of problems.

Automating security vulnerabilities

Using the WhiteSource integration for GitHub.com it is possible to monitor commits, Pull Requests and also scan existing dependencies for new CVE; the .whitesource configuration can either:

1. (Default) Use the WhiteSource Unified Agent and configure your build tools accordingly
2. Use the WhiteSource integration for GitHub.com to publicly notify the community about the CVE found; this is the standard configuration for project that are either not publicly released yet or haven't been deployed anywhere publicly.
3. Disable GitHub Issues and request FINOS - by sending an email to help@finos.org - to configure email notifications; we encourage using one of the private mailing-lists already provided by FINOS.

Responsible Disclosure at Apache Software Foundation

We took great inspiration from the work that the Apache Software Foundation have done; we started from there, then adapted processes and contents around our requirements; below the links describing the ASF responsible disclosure.

• https://www.apache.org/security/
• https://www.apache.org/security/committers.html