Drafting a security advisory

This page describes what information is expected from module maintainers when drafting an advisory, and how the security team reviews the draft.

Drafting a security advisory

In the git.drupalcode.org issue, the drupalbot will provide a customized link to creating a draft security advisory once the label Security advisory needed is added. Maintainers should use this link to create any advisories that are needed for the issue -- each vulnerability needs its own advisory.

Security advisory fields

The following fields are visible to maintainers when creating or editing an advisory.

• Project: This field is an automatically-populated reference to your project's page.
• Security risk: The risk score calculation widget builds the risk score for the vulnerability. For detailed information, see Security risk levels defined. Some notes about specific choices:
  • Authentication: Administrator (A:Admin) only applies to permissions that are not flagged with the restrict access warning. Vulnerabilities requiring a restrict access permission are not candidates for a security advisory.
  • For certain types of vulnerabilities, we have standardized conventions for Confidentiality impact and Integrity impact, since the specific impact is up to the attacker.
    • For cross-site scripting (XSS) and some improper authentication issues, the convention is to set Confidentiality impact: Certain non-public data is released (CI:Some) and Integrity impact: Some data can be modified (II:Some).
    • For remote code execution (RCE), the convention is to set Confidentiality impact: All non-public data is accessible (CI:All) and Integrity impact: All data can be modified or deleted (II:All).
  • Zero-day impact: Proof of concept exists (E:Proof) should be limited to cases where a proof-of-concept has been publicly disclosed. Steps to reproduce in a confidential security issue should remain E:Theoretical.
  • Target distribution: Default or common module configuration are exploitable, but a config change can disable the exploit (TD:Default) typically refers to configuration changes not related to permissions.
• Vulnerability: A brief, high-level description of the vulnerability. Each vulnerability addressed in a security release needs its own advisory.
• Description: A rich-text field that typically contains two or three paragraphs.
  • A sentence or two describing the project.
  • A high-level description of the vulnerability present in the project.
  • If applicable, any mitigating factors (such as a required permission or specific configuration) that could help a site owner understand their specific threat level.
• Solution: The typical solution (updating to the latest release) is provided as default text which need to be filled out with the project's name and release version.
  • If there are multiple supported branches, all branches should be addressed here.
  • If a specific branch is not affected by the vulnerability, that needs to be explicitly stated.
  • Releases are typically listed beginning with the highest version number.
  • If a workaround or mitigation is available in that a site could be made secured without updating to the latest release, also describe that here.

The contributions section of the record can also be filled in at this point, though we strongly recommend saving the draft before proceeding.

• Reported by user names: A reference list of drupal.org usernames of the issue reporter(s). Since an issue can only be authored by a single person, duplicate reporters will be mentioned in the issue's comments.
• Reported By: Use the "Update" button immediately above to automatically generate the necessary markup from the Reported by user names list.
• Fixed By user names: A reference list of drupal.org usernames of people who worked on fixing the issue. This includes any one who reviewed or tested the MR.
• Fixed By: Use the "Update" button immediately above to automatically generate the necessary markup from the Fixed By user names list.
• Coordinated By user names: A reference list of drupal.org usernames of security team members who guided the remediation process, including reviewing and published releases and advisories.
• Coordinated By: Use the "Update" button immediately above to automatically generate the necessary markup from the Fixed By user names list.

Reviewing a security advisory

When reviewing a draft security advisory, security team members ask themselves the following questions:

1. Is the vulnerability type accurate?
2. Is there only one vulnerability reported in the advisory?
3. Are all of the project's supported branches mentioned in the advisory?
4. Is the risk score accurate?
5. Does the advisory provide enough information to describe the vulnerability, yet not so much information that specific steps to exploit are easily guessed?
6. Is the description readable and appropriate for a high-level, less technical audience?
7. Are any provided mitigations or workarounds accurate and appropriate?
8. Have all contributors for an issue be listed?

A security team member is also responsible for entering and/or validating the following restricted fields:

• Fixed in: This field is automatically populated when a released tagged as a Security update is created. It will be blank until the releases are staged immediately before the release window.
• Affected versions: This field is automatically populated based on the version numbers of unpublished security release(s). If the has previously unpublished releases tagged as Security update, their version values will fill in here and will need to be overridden manually. 
• CVE ID: Every published advisory should be assigned its own CVE ID.

During the release window, security team members will also confirm that:

1. The "Fixed in" releases are properly referenced.
2. The "Affected versions" value is correct.
3. The links to release(s) in the "Solution" section is/are correct.
4. The list of contributors is up-to-date.
5. A CVE has been added to the advisory.