If you think you have found a security vulnerability, then please send an email to the Trusted Firmware security team at mailto:security@trustedfirmware.org. This is a private team of security officers who will help verify the security vulnerability, develop and release a fix, and disclose the vulnerability details responsibly. The security team is referred to from now on as "us/we/our". We do our best to respond and fix any issues as soon as possible. As with any bug, the more information you provide, the easier it is to diagnose and fix. If you already have a fix, please include it with your report, as that can speed up the process considerably. Any exploit code is very helpful. We may bring in extra help from area maintainers to understand and fix the vulnerability. Please let us know your disclosure plans if you have any. This may affect our disclosure plan as described in the next section. Please indicate any sensitive information you do not wish us to share. We reserve the right to share any information you provide with trusted third parties and eventually the public unless you request otherwise. We will credit you in any security advisory unless you request otherwise. You may use this PGP/GPG key [insert link] for encrypting the vulnerability information. This key is also available at http://keyserver.pgp.com and LDAP port 389 of the same server. The fingerprint for this key is: [Insert Fingerprint] If you would like replies to be encrypted, please provide your public key. Please note we cannot guarantee that encrypted information will remain encrypted when shared with trusted third parties. If we consider the bug not to be a security vulnerability, we will inform you and direct the bug to the normal bug fixing process. Disclosure ========== Our normal security vulnerability disclosure plan is as follows. This may change if disclosure needs to be coordinated with the reporter or other stakeholders. 1. For confirmed security vulnerabilities, we will develop a robust fix as soon as possible. During this time, we will only share information with the reporter, those needed to develop the fix and Especially Sensitive Stakeholders (ESSes). See the "ESS and Trusted Stakeholder registration" section below for more information about ESSes and Trusted Stakeholders. 2. After a robust fix becomes available, our preference is to publicly release it as soon as possible. We will automatically do this if the vulnerability is already publicly known. However, we may defer release if the reporter requests it or an ESS requests it within 1 calendar day of being notified, and we agree the criticality of the vulnerability requires more time. The ESS requested deferral period should be as short as possible, up to 7 calendar days after the fix becomes available, with an exceptional extension to 14 calendar days. The only valid reason for release deferral is to accommodate deployment of the fix by ESSes. If it is immediately clear that ESSes are unaffected by the vulnerability then we will skip this stage. This 0-14 day deferral is the primary embargo period. Due to export control restrictions, some Trusted Firmware projects may not be allowed to distribute the fix to a restricted audience. In such cases, if an ESS requests it, we will allow ESSes a reasonable period to develop and deploy their own fix. This period should be as short as possible and must always allow enough time for Trusted Stakeholders (see below section) to develop and deploy their own fixes before the public embargo period ends (see below). 3. After the primary embargo period, we will share the fix and relevant vulnerability information with registered Trusted Stakeholders. We may defer fix release further if a Trusted Stakeholder requests it within 3 working days (Monday to Friday, in their timezone) of being notified, and we agree the criticality of the vulnerability requires more time. The requested deferral period should be as short as possible, up to 7 calendar days after the Trusted Stakeholder is notified, with an exceptional extension to 14 days. The only valid reason for further release deferral is to accommodate deployment of the fix by a Trusted Stakeholder. This further 3-14 day deferral is the secondary embargo period. For Trusted Firmware projects that are not allowed to distribute the fix due to export control restrictions, and if a Trusted Stakeholder requests it, we will allow Trusted Stakeholders a reasonable period to develop and deploy their own fix. This period should be as short as possible and must always complete before the public embargo period ends. Note, security fixes contain the minimum information required to fix the bug. We will disclose the accompanying vulnerability details later. 4. After the fix is ready, we will consolidate details of the security vulnerability into a security advisory. This includes a CVE number and we will request one if not already done by the reporter. We will circulate drafts of the security advisory with the reporter, ESSes and Trusted Stakeholders as they become available. 5. 90 days after the vulnerability was reported, we will publicize the security advisory (and fix if not already available) at https://www.trustedfirmware.org/. This 90 day window is the public embargo period. Handling embargoed information ============================== On receipt of embargoed information, you must not disclose any of the provided information beyond the group of people in your organization that need to know about it. During the primary and secondary embargo periods, that group of people should be limited to those entrusted to assess the impact of the vulnerability on your organization and deploy fixes to your products. After the secondary embargo period but during the public embargo period, that group of people may be expanded in order to prepare your organization's public response. The embargoed information must not be shared outside your organization during the public embargo period under any circumstances. It is permitted to point others to a public fix during an embargo period, as long as this is not identified as a vulnerability. If you think another individual/organization requires access to the embargoed information, then please ask them to register as a Trusted Stakeholder (see next section). If you believe there has been a leak of embargoed information then please notify us immediately. We welcome feedback on embargoed information at any time. ESS and Trusted Stakeholder registration ======================================== The security team of each Trusted Firmware project maintain private, vetted lists of organizations and individuals who are considered ESSes and Trusted Stakeholders of security vulnerabilities for that project. Contact <mailto:security@trustedfirmware.org> if you want to register for one of these lists, providing the following information: 1. Which Trusted Firmware project(s) you want to register for. 2. Which stakeholder list you want to be on; this will almost always be the Trusted Stakeholder list. 3. A justification of why you should be on the list. That is, why you should know about security vulnerabilities and have access to security fixes before they are made public. A valid reason to be on the Trusted Stakeholder list for example, is that you use Trusted Firmware in a deployed product. The ESS list is strictly limited to those organizations that use Trusted Firmware for large scale deployments providing bare-metal access on multi-tenancy systems, and organizations that supply Trusted Firmware to such deployments. 4. Your full name and a valid email address. This should be an organization email address where possible. It is preferable for each organization to provide an email alias that you manage yourselves rather than us managing a long list of individual addresses. 5. Confirmation that you and the individuals in your organization will handle embargoed information responsibly as described in the previous section. Note, we reserve the right to deny registration or revoke membership to the stakeholders lists, for example if we have concerns about the confidentiality of embargoed information.