Decide which labels are needed for a full security issue workflow
>>> [!note] Migrated issue
<!-- Drupal.org comment -->
<!-- Migrated from issue #3519588. -->
Reported by: [poker10](https://www.drupal.org/user/272316)
>>>
<h3 id="summary-problem-motivation">Problem/Motivation</h3>
<p><strong>In s.d.o, we currently have these statuses:</strong></p>
<ul>
<li>Needs triage</li>
<li>Needs work</li>
<li>Needs review</li>
<li>Needs maintainer response</li>
<li>Needs team response</li>
<li>Needs reporter response</li>
<li>Needs public followup</li>
<li>Reviewed & tested by the community</li>
<li>Ready for SA to be Published</li>
<li>No maintainer response (unsupported)</li>
<li>Postponed</li>
<li>Closed (fixed)</li>
<li>Closed (can be public)</li>
<li>Closed (duplicate)</li>
<li>Closed (won't fix)</li>
</ul>
<p><strong> </strong></p>
<p><strong>In Gitlab, these labels are set currently:</strong></p>
<ul>
<li>D7 / affected (Tracking for D7ES vendors)</li>
<li>D7 / needs evaluation (Tracking for D7ES vendors)</li>
<li>D7 / only (Tracking for D7ES vendors)</li>
</ul>
<p><strong> </strong></p>
<ul>
<li>Needs attention (Automatically added when an issue has not had a timely response)</li>
<li>Needs maintainer response</li>
<li>Needs public followup</li>
<li>Needs reporter response</li>
<li>Needs review</li>
<li>Needs security team response</li>
<li>Needs work</li>
<li>Project to be unsupported</li>
</ul>
<p><strong> </strong></p>
<ul>
<li>Security advisory / drafted (Automatically added when a security advisory draft is created on Drupal.org)</li>
<li>Security advisory / needed (Will prompt maintainers to draft a security advisory)</li>
<li>Security advisory / published (Automatically added when the security advisory is published)</li>
</ul>
<p><strong> </strong></p>
<ul>
<li>Security risk / Critical (Automatically updated with the risk score from draft security issues)</li>
<li>Security risk / Highly critical (Automatically updated with the risk score from draft security issues)</li>
<li>Security risk / Less critical (Automatically updated with the risk score from draft security issues)</li>
<li>Security risk / Moderately critical (Automatically updated with the risk score from draft security issues)</li>
<li>Security risk / Not critical (Automatically updated with the risk score from draft security issues)</li>
</ul>
<p><strong> </strong></p>
<ul>
<li>Security status / can be public (A security fix is not needed, further work can happen in public issues)</li>
<li>Security status / evaluating to be public (2 weeks are allowed for security team feedback on potentially handling the issue in public)</li>
<li>Security status / unvalidated (The issue is newly reported, the first step is to validate the issue)</li>
<li>Security status / validated (It's been confirmed that an issue is in fact valid)</li>
</ul>
<p>-----------------</p>
<p><strong>The missing original statuses are:</strong></p>
<ul>
<li>Reviewed & tested by the community → Security status::reviewed & tested</li>
<li>Ready for SA to be Published → Security status::ready to be published</li>
<li>Postponed → Security status::postponed</li>
<li>Closed (duplicate) → Closed::duplicate</li>
<li>Closed (won't fix) → Closed::invalid, potentially might be other statuses</li>
</ul>
<p><strong> </strong></p>
<h3 id="summary-proposed-resolution">Proposed resolution</h3>
<p>Decide which additional labels we need to add and add them.</p>
issue