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
📌
Move security advisory drafting to www.drupal.org
Active
so advisories are associated with the issue, and can update the issue when updated.
Document everything for security team members and project maintainers.