Skip to content

Latest commit

 

History

History
116 lines (84 loc) · 6.65 KB

vulnerability-response.md

File metadata and controls

116 lines (84 loc) · 6.65 KB
Raw

Tuleap coordinated vulnerability disclosure process

This document describes the process used by the Tuleap Security team to disclose vulnerabilities affecting Tuleap.

A runbook is available for Tuleap Integrators running a vulnerability response and needing a more "hands-on" document.

Source of reports

We are considering that the reports about possible vulnerabilities are classified into 2 categories:

  • external
    • reports received by mail via [email protected]
    • issues misclassified as bug in the public Tuleap Requests tracker
    • vulnerabilities disclosed publicly outside this process
    • report received via a Tuleap Enterprise customer in their private support trackers
  • internal
    • vulnerability identified by a Tuleap Integrator or a Tuleap developer supervised by a Tuleap Integrator
    • vulnerability identified by tooling deployed by the Tuleap Security team (see our tests & automated inspections document)
    • penetration test/audit reports from missions ordered by the Tuleap Security team

It should be noted that processing external reports involves additional communications so that external reporters can have clear expectations on how their reports are handled.

What's a vulnerability?

It can sometimes not be easy to distinguish a vulnerability from a bug or a possible enhancement.

If the answer is yes to one of the following questions the issue should be considered as a vulnerability:

  • Is it exploitable in a way affecting the confidentiality, integrity or availability of data manipulated by Tuleap? Are you able to create a CVSS score for it?
  • Can you find similar issues in the Tuleap Requests tracker that have been identified as vulnerability in the past?

If the issue does not appear to be a vulnerability the report should still be registered as a bug/enhancement request as it can still have interesting information.

Communication with external reporters

Upon the request of an external reporter additional means to protect the confidentiality of the reports can be provided. The following means can be considered:

  • E2EE private chat on the Tuleap Community chat platform
  • document encrypted using Age and one the SSH public keys of the Tuleap Security team member processing the report
  • if nothing else is suitable for the external reporter a GPG key can be generated specifically for this report by the Tuleap Security team member, the GPG key will be thrown away once the report has been processed

Reports made by external reporters are expected to be acknowledged within 3 (French) business days.

External reporters can be credited for their findings in the advisory if the issue is confirmed to be a vulnerability. The Tuleap Security team will confirm with the reporters if they want to be credited and under which name (firstname/lastname of the reporter, company name, pseudo...).

Advancements in the processing of the report are expected to be communicated with the external reporter. At least the following items should be communicated:

  • confirmation that the reported issue is a vulnerability
  • expected date of the public disclosure once it is known
  • the CVE ID assigned to the vulnerability
  • information about availability of the fix
  • if the development team feels it can be relevant and if the reporter is willing to, the fix can be discussed with the reporter in order to collect feedbacks

Preparing the advisory and fixing the issue

Once the issue has been confirmed to be a vulnerability, a security advisory must be created in the Tuleap Requests tracker using the following template. The advisory must stay private until the disclosure.

The base to determinate the severity of the issue is the generation of a CVSS v3.1 score. In order to generate it relies on the CVSS user guide, examples and scores assigned to similar Tuleap vulnerabilities.

The work on the fix and reviews will happen on gerrit.tuleap.net on a private security branch. Once the fix is considered to be ready, it must be merged using the usual integration process into Tuleap Community. Commit messages of the fixes must not contain details on how the vulnerability can be exploited.

Security fixes are expected to be backported into the supported Tuleap Enterprise releases whenever it is relevant. The backported changes should be mentioned as "Security" related in the Tuleap Enterprise changelogs. The Tuleap Enterprise changelogs must not contain more details than what is provided by the commit messages of the fixes.

The publication of the fix should occur within 90 days after the acknowledgement of report for a vulnerability with a Medium (or higher) severity.

For situations where the vulnerability has been disclosed publicly outside this coordinated vulnerability disclosure process decision can be taken by the Tuleap Security team to publish the advisory directly and work on the fix publicly.

Obtaining a CVE ID

Each Tuleap vulnerability must be assigned a CVE ID. The Tuleap project relies on the GitHub CNA via the GitHub Security Advisory (GHSA) feature to obtain CVE IDs.

For each vulnerability a GHSA is created using the following template to request it. The CVE is published the day of the public disclosure.

Disclosure timeline

The advisory is expected to be published on the first Monday (or the next business day if Monday is not one) following the publication of the monthly Tuleap release including the fix.

The disclosure of vulnerabilities with a High severity can be delayed up to one month if the fixes landed the week of the publication of the monthly Tuleap release. This is left to the appreciation of the Tuleap Security team in order to reduce the impact for existing Tuleap deployments. The Tuleap Security team will discuss this with the external reporters (if one exist) to reach an agreement.

For situations where a vulnerability affects multiple projects the disclosure should be discussed between the security teams of the involved projects, the reporters and other actors that might be involved such as CERT.

The vulnerability is also mentioned in the release notes of the Tuleap version disclosing it.

References