Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Table of Contents

Background

In November 2019, FINOS rolled out enhanced vulnerability scanning using Whitesource as a new feature integrated within the FINOS Open Developer Platform CI/CD (Continuous Integration / Continuous Development) tooling which is made available to all FINOS-hosted project Github repositories.

As part of that rollout, FINOS concurrently introduced a new Security Vulnerabilities Responsible Disclosure Policy (this document) in order to define how potential vulnerabilities should be handled and managed within and amongst the community.

Image Added

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

Image Removed

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


Warning
titleIMPORTANT!

No information should be made public about the vulnerability until it is formally announced at the end of this process. That means, for example that a GitHub Issue must NOT be created to track the issue since that will make the issue public. Also the messages associated with any commits should not make ANY reference to the security nature of the commit.

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.


Info
titleSharing information

Information may be shared with domain experts (e.g. colleagues at your employer) at the discretion of the project's security team providing that it's made clear the information is not for public disclosure and that help@finos.org or the private PMC list must be copied on any communication regarding the vulnerability.



For FINOS Open Source Contributors


Warning
titleIMPORTANT!

No information should be made public about the vulnerability until it is formally announced at the end of this process. That means, for example that a GitHub Issue must NOT be created to track the issue since that will make the issue public. Also the messages associated with any commits should not make ANY reference to the security nature of the commit.


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.


Info
  1. We are working with WhiteSource to allow email recipient configuration and publishing rules setup as part of .whitesource configuration file
  2. Checkout the Rollout Plan to enable automated scanning across all FINOS hosted projects


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.