PROJECT, an LF Decentralized Trust Project Security Policy

Instructions

The following is the best practices template security vulnerability disclosure policy for LF Decentralized Trust projects or subprojects within individual LF Decentralized Trust projects. Please copy the text below, place it into the SECURITY.md file for the primary repository of your project, and adjust it as necessary for your project. Notably:

• Remove this “Instructions” section.
• Replace “PROJECT” throughout the document with the name of your project.

Once your project’s security vulnerability disclosure policy document is published, place a copy of it into the rest of the repositories of your project, or create a SECURITY.md file in each repository that links back to the primary document.

See the “Alternative:” notes in the LF Decentralized Trust Security Policy document for how the “best practices” in this document can be changed to meet the needs of a specific project while still adhering to the LF Decentralized Trust policies.

About this document

This document defines how security vulnerability reporting is handled in PROJECT, an LF Decentralized Trust Project. The approach aligns with the LF Decentralized Trust Security Policy . Please review that document to understand the basis of the security reporting for PROJECT.

This vulnerability policy borrows heavily from the recommendations of the OpenSSF Vulnerability Disclosure working group. For up-to-date information on the latest recommendations related to vulnerability disclosures, please visit the GitHub of that working group.

If you are already familiar with the security policies of PROJECT, and ready to report a vulnerability, please jump to Report Intakes.

Outline

This document has the following sections:

• PROJECT Security Policy
  • Instructions
  • About this document
  • Outline
  • What Is a Vulnerability Disclosure Policy?
  • Security Team
  • Discussion Forums
  • Report Intakes
  • CNA/CVE Reporting
  • Embargo List
  • (GitHub) Security Advisories
  • Private Patch Deployment Infrastructure

What Is a Vulnerability Disclosure Policy?

No piece of software is perfect. All software (at least, all software of a certain size and complexity) has bugs. In open source development, members of the community or the public find bugs and report them to the project. A vulnerability disclosure policy explains how this process functions from the perspective of the project.

This vulnerability disclosure policy explains the rules and guidelines for PROJECT. It is intended to act as both a reference for outsiders–including both bug reporters and those looking for information on the project’s security practices–as well as a set of rules that maintainers and contributors have agreed to follow.

Security Team

The current PROJECT security team is:

Name	Email ID	Discord ID	Area/Specialty
Satoshi Nakamoto	satoshi@nsa.gov		Everything
Hart Montgomery	hart@donotmail.com		Else
<>	<>	<>	(if applicable)

The security team for PROJECT must include at least three project Maintainers that agree to carry out the following duties and responsibilities. Members are added and removed from the team via approved Pull Requests to this repository. For additional background into the role of the security team, see the People Infrastructure section of the LF Decentralized Trust Security Policy.

Responsibilities:

1. Acknowledge the receipt of vulnerability reports to the reporter within 2 business days.

2. Assess the issue. Engage with the reporter to ask any outstanding questions about the report and how to reproduce it. If the report was received by email and may be a security vulnerability, open a GitHub Security Advisory on the repository to manage the report. If the report is not considered a vulnerability, then the reporter should be informed and this process can be halted. If the report is a regular bug (but not a security vulnerability), the reporter should be informed (if necessary) of the regular process for reporting issues.

3. Some issues may require more time and resources to correct. If a particular report is complex, discuss an embargo period with the reporter during which time the report will not be publicly disclosed. The embargo period should be negotiated with the reporter and must not be longer than 90 days.

4. If necessary, create a private patch development infrastructure for the issue by emailing the LF Decentralized Trust Community Architects.

1. Request a CVE for the issue (see the CNA/CVE Reporting section).

2. Decide a date for the public release of the vulnerability report, the date the embargo period ends.

3. If applicable, notify members of the embargo list of the vulnerability, upcoming patch and release, as described above.

4. Publish a new (software) release in which the vulnerability is addressed.

5. Publicly disclose the issue within 48 hours after the release via a GitHub security advisory (see the (GitHub) Security Advisories section for details).

Discussion Forums

Discussions about each reported vulnerability should be carried out in the private GitHub security advisory about the vulnerability. If necessary, a private channel specific to the issue may be created on the LF Decentralized Trust Discord server with invited participants added to the discussion.

Report Intakes

PROJECT has the following ways to submit security vulnerabilities. While the security team members will do their best to respond to bugs disclosed in all possible ways, it is encouraged for bug finders to report through the following approved channels:

• Email the LF Decentralized Trust Foundation security list: To report a security issue, please send an email with the name of the project/repository, a description of the issue, the steps you took to create the issue, affected versions, and if known, mitigations. If in triaging the email, the security team determines the issue may be a security vulnerability, a GitHub security vulnerability report will be opened.
• Open a GitHub security vulnerability report: Open a draft security advisory on the “Security” tab of this GitHub repository. See GitHub Security Advisories to learn more about the security infrastructure in GitHub.

CNA/CVE Reporting

PROJECT maintains a list of Common Vulnerabilities and Exposures (CVE) and uses GitHub as its CVE numbering authority (CNA) for issuing CVEs.

Embargo List

PROJECT maintains a private embargo list. If you wish to be added to the embargo list, please email the LF Decentralized Trust Foundation security mailing list, including the project name (PROJECT) and reason for being added to the embargo list. Requests will be assessed by the PROJECT security team in conjunction with the appropriate LF Decentralized Trust Staff, and a decision will be made to accommodate or not the request.

For more information about the embargo list, please see the Embargo List section of the LF Decentralized Trust Security Policy.

(GitHub) Security Advisories

PROJECT uses GitHub Security Advisories to manage the public disclosure of security vulnerabilities.

Private Patch Deployment Infrastructure

In creating patches and new releases that address security vulnerabilities, PROJECT uses the private development features of GitHub for security vulnerabilities. GitHub has extensive documentation about these features.