Problem/Motivation

GitHub has recently started to make use of SECURITY.md files if present in the repository root. Many open source projects have since stared to have a SECURITY.md file explaining how to report security vulnerabilities properly.

Just a moments ago, we got WordPress to commit their SECURITY.md file, and I would like to propose that we use a SECURITY.md file as well.

This file can explain the procedures we have security.drupal.org, how to report a Drupal core vulnerability, how it works for core, security coverage, and a lot of other information that will surely make it easier for security researchers and end users alike.

Thank you.

Steps to reproduce

N/A

Proposed resolution

Add SECURITY.md that points to the drupal policy

Remaining tasks

Decide if it belongs in root or core. I think it should be as easy to find as possible.
Decide on wording of the link.

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Issue fork drupal-3094817

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

Ayesh created an issue. See original summary.

cilefen’s picture

Title: Add a SECURITY.md file to Drupal » Add a SECURITY.md explaining how to report security vulnerabilities properly
Priority: Minor » Normal

👍

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

agoja made their first commit to this issue’s fork.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

prudloff’s picture

I agree this would be useful.
We sometimes report vulnerabilities to upstream libraries used in contrib and having a SECURITY.md file helps a lot. So we should also make it easy for people outside of Drupal to share vulnerabilities with us.

nicxvan made their first commit to this issue’s fork.

quietone’s picture

Keep in mind there is existing documentation, https://www.drupal.org/docs/develop/issues/issue-procedures-and-etiquett.... Should core just link to that? Just a thought.

nicxvan changed the visibility of the branch 9.2.x to hidden.

nicxvan changed the visibility of the branch 3094817-add-a-security.md to hidden.

nicxvan’s picture

Issue summary: View changes
Status: Active » Needs review

Exactly what I was thinking!

smustgrave’s picture

Status: Needs review » Reviewed & tested by the community

Seems straight forward enough.

quietone’s picture

Status: Reviewed & tested by the community » Needs work

There is a suggested change on the MR.

Also the text limits this to core and contributed modules where as the linked page states "module, theme, or distribution".

nicxvan’s picture

Status: Needs work » Needs review

Thanks! I think those notes came after RTBC and I missed them.
I think I've addressed their comments and yours.

quietone’s picture

Status: Needs review » Needs work

This time I did more research before commenting.

nicxvan’s picture

Status: Needs work » Needs review

I addressed all feedback I think.

bserem’s picture

Status: Needs review » Needs work

@nicxvan added some feedback as a gitlab suggestion

nicxvan’s picture

Status: Needs work » Needs review

I think quietone addressed your suggestion, thank you!

smustgrave’s picture

Status: Needs review » Reviewed & tested by the community

Distribution aren't really a thing anymore, are they?

They may be out of date with recipes but believe they are definitely still around

bserem’s picture

Thanks for the clarifications all

cilefen’s picture

Status: Reviewed & tested by the community » Needs work

Sorry for the late comment here, but there already exists text of this policy:

# How to report a security issue

If you discover or learn about a potential error, weakness, or threat that can compromise the security of Drupal, we ask you to keep it confidential and submit your concern to the Drupal security team.

Should we not use the same?

nicxvan’s picture

Status: Needs work » Reviewed & tested by the community

No, that was already suggested by @bserem and addressed by @quietone:

From the MR:

I don't think this is an improvement. Previous comments have pointed out that the capitalization of Contributed is incorrect. That would also apply to 'Core'. This also removes distribution, which should remain. And core does not use the style 'we ask' in any user facing text so this should not as well. The exchange of 'security vulnerability' for a list of items is limiting and I would rather that the more open to interpretation phrase remain.

We are also linking to the resource that the one you linked to links to so it's more direct.

I think it's ok to restore status since this question was addressed already.

  • quietone committed 8c2ce13d on 10.4.x
    Issue #3094817 by nicxvan, quietone, prudloff: Add a SECURITY.md...

  • quietone committed 0cf21013 on 10.5.x
    Issue #3094817 by nicxvan, quietone, prudloff: Add a SECURITY.md...

  • quietone committed 3b8c1839 on 10.6.x
    Issue #3094817 by nicxvan, quietone, prudloff: Add a SECURITY.md...

  • quietone committed 74a477bc on 11.1.x
    Issue #3094817 by nicxvan, quietone, prudloff: Add a SECURITY.md...

  • quietone committed 04bd2f9c on 11.2.x
    Issue #3094817 by nicxvan, quietone, prudloff: Add a SECURITY.md...

  • quietone committed 6603a36d on 11.x
    Issue #3094817 by nicxvan, quietone, prudloff: Add a SECURITY.md...
quietone’s picture

Version: 11.x-dev » 10.4.x-dev
Status: Reviewed & tested by the community » Fixed

Thanks everyone.

Backported to Drupal 10 because of the expectation this file exist is growing and security issues can be critical.

cilefen’s picture

@nicxvan re #28, not everything in that comment was addressed. I guess recipes don’t count? IMO this text shouldn’t cite specific project types.

poker10’s picture

I agree that we technically cover all code on git.drupalcode.org, if the project is opted into security advisory coverage and has stable release. So also recipes (https://new.drupal.org/browse/recipes) and general projects (https://www.drupal.org/project/project-general).

We probably need to update the wording in https://www.drupal.org/docs/develop/issues/issue-procedures-and-etiquett..., but in the SA policy (https://www.drupal.org/drupal-security-team/security-advisory-process-an...), the project types (modules, themes, distributions) are not explicitly mentioned and the policy is not restricted to these types.

//edit - recipes seems to be technically still general projects, so I think we are missing at least the one category - general projects for now

prudloff’s picture

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.