Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Problem/Motivation
With issues moving to GitLab in the near future, we get GitLab’s confidential issues capability. GitLab does not support a security team having access to all confidential issues.
Project maintainers will see confidential issues for their project right away. The current process is that the security team does the first triage so maintainers do not see invalid issues. Now that triage will effectively be shared with the maintainers, but there will never be a delay in informing them.
We have a GitLab group for the security team at https://git.drupalcode.org/security. This allows security team members to access all projects within that group. Currently the only project is a private fork of core for private merge request testing.
Issues will be moved to GitLab project-by-project, which will take a few weeks. It would be better to move all security issues at one time, so security issues are all following the same process, and security.drupal.org can be removed. Until all projects’ issues are moved, an interim solution will be needed to report security issues. This can be a single Drupal security issue triage project. We can help ensure issues are opened as confidential by linking to the new issue form with issue[confidential]=1 in the query string, and including /confidential in the template.
Valid issue reports also need a place to work on a fix. Since every issue will have a unique set of people with access, a new fork is needed for each issue.
Proposed resolution
When an issue is opened in the security issue triage project, if it has a [project machine name]: prefix, the private fork setup will start. If that prefix is missing, it will start when a security team member triages and updates the issue title to add it. Once a project has public issues migrated to GitLab, the same process will start for confidential issues.
- A private fork of the project is automatically set up with access granted for the reporter, project’s maintainers, and inherited group access for the security team.
- The security issue is moved to that fork, so everyone has the access they should have.
- Moved GitLab issues are actually copied. A comment is posted to the original issue to explain the start of the process and lock discussion.
- A comment is posted to the moved issue to explain the process in more detail and do initial labeling, issues start out as “unverified” until triaged.
Remaining tasks
Set up a webhook receiver to automate everything. The first draft is a drush command.
Set up the issue triage project on production, private so only security team members have access as a preview. This will solve the immediate need to invite subject matter experts to forks for specific issues.
Make sure the process to add a subject matter expert or new maintainer to a fork works. This may need to be the webhook receiver looking for new assignees or mentions in the issue.
Various notifications need to be double checked:
- We can turn on project or issue notifications for project maintainers.
- security.drupal.org sends a notification directly to maintainers when an issue is triaged, we should do the same since not everyone will have their GitLab notification email address set up.
In the security team group:
- Set up more labels to assist in triaging.
- Set up milestones for security release windows, so automations have the release date to build logic around.
- Set up group comment templates for common replies
Set up https://gitlab.com/gitlab-org/ruby/gems/gitlab-triage for automations.
Integrate with #3485758: Move security advisory drafting to www.drupal.org so advisories are associated with the issue, and can update the issue when updated.
Migrate existing security issues, including closed issues.
Document everything for security team members and project maintainers.
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | Screenshot 2024-11-15 at 3.23.06 PM.png | 339.36 KB | drumm |
| #3 | Screenshot 2024-11-15 at 3.20.46 PM.png | 248.97 KB | drumm |
Issue fork drupalorg-3487828
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:
changes
Comments
Comment #3
drummThe initial work in the MR now handles new issues being filed:
And the moved issue currently looks like this:
Comment #4
drummComment #5
drummAdding note that migration needs to happen.
Comment #6
benjifisher> Migrate existing security issues. Do we need closed issues, or lose those forever?
I think we need the closed issues. As a general rule, I hate to throw away information.
If an issue was considered a valid security issue, then fixed, then some of the important information is in the public SA. Even then, a lot of details about the possible exploit are only in the issue (now closed).
If an issue was considered not to be a valid security issue, then at best we have a comment in a public "hardening" issue. The discussion and the details are only in the issue (now closed). We often look for old issues similar to newly created ones: "in previous issues very similar to this one, we decided to fix them in public because ...".
Comment #7
drummAgreed closed issues need to be migrated.
Comment #11
damienmckennaDid anyone open a feature request in gitlab to have a concept of a "security" role for users to be able to access all security issues?
Comment #12
drummNo, that didn’t happen. GitLab has only recently added custom admin roles, https://docs.gitlab.com/user/custom_roles/#custom-admin-roles, which might get us partway there.
Security issues will need private forks regardless, so private MRs can be used for review and testing. Putting those private forks under https://git.drupalcode.org/security takes care of giving the security team access, and the group labels, milestones, etc keep everything organized the same way. Even if there was a good way to give security team members access to all confidential issues, that is only partway there.
Comment #13
drummDocumentation for this is started at https://www.drupal.org/drupal-security-team/security-team-procedures/sec...
Remaining work:
Comment #14
drummI believe the main work left is to migrate the issues. As far as I'm aware, the new setup is feature-complete enough.
Comment #15
drummAnd we can open this process to everyone for more testing, we don’t need to complete the migration for the new process to be the default.
Comment #16
damienmckennaAre we worried about the sdo issue IDs being retained on gitlab?
Comment #17
benjifisherIn https://git.drupalcode.org/security/24-drupal-security/-/issues/1, we discussed a problem in the 11.x branch that did not exist in any released version of Drupal core. The issues that led to that problem were reverted, so the problem will never be part of a release.
I know that someone reading that can search for reverted issues and figure out where the problem was, but the problem has been fixed so I am not worried about mentioning it on this public issue.
The question for this issue is what label to attach when closing the private issue. I chose Closed:public, but I would have liked the option Closed:outdated. Should we add such a label?
Comment #20
drummI have gone ahead and made the git.drupalcode.org workflow the default, once the block caches clear, all “Report a security vulnerability” links will go to git.drupalcode.org.
With the upcoming outages for Drupal.org migrations, this will allow reporting new issues to be available through our server moves. And will settle down the data set for testing the entire migration in staging. I expect we might be able to complete the migration within a couple weeks.
The issue IDs will be retained.
We have Closed::unsupported, but I suppose that is different, the contrib module would have become unsupported as a result of inaction. Outdated would be for vulnerabilities that were reported about unsupported versions?