Disclosure Policy

Reporting a Vulnerability

If you think that you have found a security vulnerability, please report it to this email address: feedback-crypto@bouncycastle.org

Describe the issue including all details, for example:

  • Short summary of the problem
  • Steps to reproduce
  • Affected API versions
  • Logs if available

The Bouncy Castle team will send a non-automated response indicating the next steps in handling your report within 48 hours. You may be asked to provide additional information or guidance.

If the issue is confirmed as a vulnerability, we will allocate a CVE number and open a Security Advisory and acknowledge your contributions as part of it. Any other parties with knowledge of the vulnerability will also be made aware of the CVE number. Unless the CVE is of a LOW (see below) severity we will keep details of the CVE private and only discuss it with parties that already have prior knowledge until the Security Advisory is ready for publication.

Optionally, you can have your name and contact information listed in Contributors as well.

CVE Notification

The Legion of the Bouncy Castle maintains a list of CVE announcements on the Bouncy Castle GitHub. These can be found https://github.com/bcgit/bc-java/wiki for Java issues and at https://github.com/bcgit/bc-csharp/wiki for .NET C# issues. Once a Security Advisory becomes public and is published on the NVD, information concerning the advisory and its associated CVE number will appear there.

Please note we endeavor to issue patched releases that deal with security issues as soon as they are made known to us, ideally prior to issuing a Security Advisory where otherwise possible. In some cases, particularly if it relates to a FIPS release, delays due to external processes may delay the issuing of a Security Advisory.

Issue Severity

We will determine the risk of each issue, taking into account our experience dealing with past issues, versions affected, common defaults, and use cases. We use the following severity categories:

  • CRITICAL Severity. This affects common configurations and which are also likely to be exploitable. Examples include significant disclosure of the contents of server memory (potentially revealing user details), vulnerabilities which can be easily exploited remotely to compromise server private keys or where remote code execution is considered likely in common situations. These issues will be kept private and will trigger a new release of all supported versions. We will attempt to address these as soon as possible.
  • HIGH Severity. This includes issues that are of a lower risk than critical, perhaps due to affecting less common configurations, or which are less likely to be exploitable. These issues will be kept private and will trigger a new release of all supported versions. We will attempt to keep the time these issues are private to a minimum; our aim would be no longer than a month where this is something under our control.
  • MODERATE Severity. This includes issues like crashes in client applications, flaws in protocols that are less commonly used (such as DTLS), and local flaws. These will in general be kept private until the next release, and that release will be scheduled so that it can roll up several such flaws at one time.
  • LOW Severity. This includes issues such as those that only affect the utilities like the Kotlin API, or unlikely configurations. These will in general be fixed immediately in latest development versions, and may be backported to older versions that are still getting updates. We will update the vulnerabilities page and note the issue CVE in the changelog and commit message, but they may not trigger new releases.

Timelines

For CRITICAL or HIGH level CVEs we will issue a patch release within 28 days of the report, sooner if possible, and only longer where third-party procedural issues, such as revalidation for FIPS, may make it necessary. Where third-party procedural issues intervene we will make an "early access" release available to those aware of the CVE for the certified module with the patch applied while the procedural issues are dealt with. The "early access" release will be made available within the 28 day period.

For MODERATE or LOW level CVEs we will issue a patch release within 65 days of the report, or on the next release boundary, whichever arrives sooner, unless there are third-party procedural issues that must be dealt with. Where third-party procedural issues intervene we will make an "early access" release available to those aware of the CVE for the certified module with the patch applied while the procedural issues are dealt with. The "early access" release will be made available within the 65 day period.

Security Advisories and CVEs will be published within a few days of the release fixing them. Only longer if other circumstances, such as those where publication may put one of our users at risk as they are still in the process of patching - possibly due to a need to be only using certified releases - require it.

Dispute Resolution

As a CNA the Legion of the Bouncy Castle Inc. is also bound by the CNA Dispute Resolution Policy. If you feel we have not handled a bug report correctly the Dispute Resolution Policy is available by submitting a dispute to our root CNA, MITRE.