Document policy on who gets credit on SAs

DamienMcKenna's picture

While it is mentioned in some locations, the security team's policy is not made completely clear on who gets credit on an SA or what format it will be in. It was briefly discussed before ( and here's the SA form fields have default values like the following:

  • <a href="">Real Name</a>
  • <a href="">Real Name</a> of the Drupal Security Team
  • <a href="">Real Name</a> the module maintainer

So the format currently is:

[a href=""]Real Name[/a]

with either "of the Drupal Security Team" or "the [module] maintainer" appended as appropriate. Furthermore, the user agreement specifically states:

3. If you are sharing your user account with multiple people (e.g. as your “official” organization account), you are not allowed to do the following using this account:

  • commit code to Git repositories on the Website
  • create any nodes except for organization, case study or project nodes
  • comment on nodes

If you are sharing your user account with multiple people you ARE allowed to:

  • create project nodes
  • create organization nodes
  • create case study nodes
  • submit translations to

Therefore the user accounts mentioned in an SA must be to individual users, not an organization.

What I would like to do is combine all of these into a documentation page in the security-team section on d.o. What I'm figuring is something like the following:

Security Advisory naming policy

The security team's security advisory naming policy fits in line with the user agreement. As such, individual users who report, work on or commit security fixes will be named in the security advisory. Depending upon the specific situation, the name will be listed in one of the following formats:

  1. <a href="[username]">Full name</a>.
  2. <a href="[username]">Full name</a> of the Drupal Security Team.
  3. <a href="[username]">Full name</a>, the [module/theme/core] maintainer.

Additional notes:

  • If the user's full name cannot be identified from their user profile, their username will be used.
  • If the user does not have a user account on, e.g. they emailed details to the security team and refrained from creating a user account, there would not be a link for their name.

Are there any other improvements or details that should be noted?


Sometimes vulnerabilities are

klausi's picture

Sometimes vulnerabilities are reported through other channels (Email, IRC, phone calls!) by people that don't have user accounts. In that case we should just credit them with whatever name they would like.

Examples that are all acceptable to me:
Pseudonyms: L33tH4Xooress
Pseudonyms with links to their homepage: L33tH4Xooress
Real names: Barbara Smart (with or without link)
Organizations: Security lab Trans*H4ck (with or without links)

Proposal: default to full name and account, but otherwise just put in whatever the reporter would like. Credit where credit is due!

Organization, client/project credit?

DamienMcKenna's picture

Given that issues on allow credit to be given for the organization funding the work, or even the client/project that the work was for, should we not also include that in the SA?

IMO people should put that on

greggles's picture

IMO people should put that on their profile.

The new content type will

mlhess's picture

The new content type will allow for this, however, the credit won't show up on the SA, but it will show up on their profile and if a company the companies commit credits.

The existing standard that

greggles's picture

The existing standard that has evolved from prior discussions is in

2 sections that seem relevant to me:

Do not disclose the vulnerability to anyone else before the advisory is issued. If progress on fixing the issue stalls and it cannot be fixed in a mutually agreeable time, we will unpublish the releases and create a Security Advisory detailing the problem.

If you follow this process to report a previously unknown vulnerability to the Drupal security team, you will be credited in the security announcement with your name and a link to your profile. Individuals who choose to disclose it publicly before the team and module maintainer can coordinate on a release will not be credited in the release.