Document the labels on security issues in Drupalcode

Are these based on an external reference or ontology?

If not, I'd suggest that "Severity" might be a more descriptive scope than "Security risk", considering the labels are "Critical", "Highly critical", etc. IMO, "Security risk" implies a more qualitative/categorical descriptor, like "Privilege escalation" or "Remote exploit". But we probably don't want to re-invent CVSS...

Also, the "Security status" scope seems to mix concerns somewhat. For example, "not in advisory policy" seems to be of a different nature than "needs work", "rtbc", etc. Perhaps it should be in the "Security Advisory" scope instead?

https://git.drupalcode.org/groups/security/-/labels?search=security

This link appears to not be visible to unauthenticated users. I wonder if it is possibly not accessible to anyone who hasn’t been added to at least one security issues (my test account doesn’t work with GitLab for some reason I’ve never requested infra to evaluate so I can’t test this myself if anyone else has no GitLab security issues you could help by commenting on if you can access this link).

Perhaps not a major blocker since you have to be authenticated to see issues or edit them however worth knowing/evaluating as it relates to public documentation.

That list is linked from this documentation page https://www.drupal.org/drupal-security-team/security-team-procedures/sec...

I’ll note that page is unlikely to be found from a security issue. It’s buried under a topic that says

This section of the handbook details the procedures for Drupal Security Team members. If that is not you, you can safely skip this section of the documentation unless you are particularly interested in the topic.

Longer term: I imagine users will learn to click on Manage > Labels which will mitigate any of these external needs.

Near term: I didn’t think to to check the labels before I responded in Slack regarding a lack of documentation, and while I’m far from a GitLab expert, my experience has been I tend to be one of the users most likely to explore and use the full UI. That leads me to be concerned other users are less likely in the near future learn this GitLab method for finding label text.

Security Status Validated:
and meets the team policies and practices I’ve seen too many issues I expect the security team to refuse end up accepted and ones I would expect them to accept be refused. That phrase for me likley makes this team only. At the very least it implies maintiners need to have a firm grasp of the security team action history to make decisions. Perhaps another middle ground “maintainer agrees” stage ? (Possibly out of scope for this issue since it’s documenting current tags.)

If not, I'd suggest that "Severity" might be a more descriptive scope than "Security risk"

Expanding on that, I would go so far as to suggest it could be prefaced with “Calculated …” to make it more clear it’s an automated field (possibly out of scope for this issue, just wanted to suggest it since it is related to the previous suggestions of changing title)

That leads me to be concerned other users are less likely in the near future learn this GitLab method for finding label text.

We can mention the labels in one of the automated issue updates or comments if we think it will help people. As long as the text doesn’t become so long that the really important points get glossed over.

I thought GitLab had helpful hover tips for labels right on the issue, but it seems it does not.

As another data point:
Mobile devices also do not have hover/mouseover support.

On my phone (where I do somehere around 80-90% of my reviewing and commenting) it is a link where you see the mouseover text for a moment when you click the link before being directed to a page that filters only on that tag (same for my native device app).

To reiterate I do expect long term users will learn all these methods, it is only in the short term where most the project are still likley on D.O. yet the securtiy issues are on G.D.O. (And maybe a half year to a year after the great migration to issues) that I expect this to be a point of per user learning. Unlike much of the rest of the conversion there really wasn’t a viable way to train users on Labels before migration.