@@ -249,7 +249,7 @@ All three health labels are required for each PSRR risk:
## Triage Bot Automation
PSRR adopts [GitLab Triage Bot](https://gitlab.com/gitlab-org/ruby/gems/gitlab-triage) using recommended [USRM policies](/handbook/security/security-observations-risk-management/#required-triage-bot-policies) to:
PSRR adopts [GitLab Triage Bot](https://gitlab.com/gitlab-org/ruby/gems/gitlab-triage) using recommended [USRM policies](/handbook/security/security-observations-risk-management/#required-usrm-finding-policies) to:
| **Department**|`Department:[department-name]`| To identify department that owns the risk for Corporate findings |
| **Group**|`group:[group-name]`| To identify product that owns the risk for Product findings |
| **Department**|`Department:[department-name]`| To identify department that owns the risk for Corporate (-com) findings |
| **Group**|`group:[group-name]`| To identify product that owns the risk for Product (-org) findings |
| **Priority** | `priority::1`, `priority::2`, `priority::3`, `priority::4` | Aligns with GitLab standard priority framework. Use either priority/severity labels OR risk rating labels, not both |
| **Severity** | `severity::1`, `severity::2`, `severity::3`, `severity::4` | Aligns with GitLab standard severity framework. Use either priority/severity labels OR risk rating labels, not both |
| **Risk Rating** | `RiskRating::Critical`, `RiskRating::High`,`RiskRating::Moderate`,`RiskRating::Low`| Alternative to severity and priority to rate risks|
@@ -428,191 +428,21 @@ This runbook provides instructions for Finding Coordinators to manage finding is
| Label | When to Apply | When to Remove |
|-------|---------------|----------------|
| `USRM Workflow::Finding Identified` | Security finding has been discovered and documented with all required fields complete (description, recommendation, RACI, priority/severity) | When Remediation Manager begins documenting detailed remediation plan (apply `Remediation Plan` label) |
| `USRM Workflow::Remediation Plan` | Remediation Manager is documenting detailed remediation plan with steps, owners, and due dates | When remediation work begins and issue enters active monitoring (apply `Monitoring Active` label) |
| `USRM Workflow::Monitoring` | Remediation work is underway with active progress monitoring - awaiting completion and validation | When Finding Identifier validates remediation complete (apply `Closed` label) |
| `USRM Workflow::Remediation Plan` | Remediation Manager is documenting detailed remediation plan with steps, owners, and due dates | When remediation work begins and issue enters active monitoring (apply `USRM Workflow::Monitoring` label) |
| `USRM Workflow::Monitoring` | Remediation work is underway with active progress monitoring - awaiting completion and validation | When Finding Identifier validates remediation complete (apply `USRM Workflow::Closed` label) |
| `USRM Workflow::Closed` | Security finding has been fully remediated and validated as resolved | N/A - Terminal state |
---
</details>
#### Required Triage Bot Policies
All security teams generating findings must implement the following automated policies in their respective projects:
1.**Stale Issue Nudging**
Policy: Automated nudging when issues remain inactive
- Trigger: Issues without updates for 30 days
- Action: After 30 days of inactivity, add `stale` label and add comment requesting status update and tag assignee
- Exception: Issues labeled `ignore` or `blocked` are excluded
<details>
<summary>Example Policy</summary>
```yaml
-name:Nudge stale issues
conditions:
issue_type:issue
forbidden_labels:
-stale
-<blocked team label here>
state:opened
date:
attribute:updated_at
condition:older_than
interval_type:months
interval:1
actions:
redact_confidential_resources:false
comment:|
{{author}} This issue has not been updated in 1 month.
If this issue is still relevant, please provide an update and/or update the workflow status.
The `stale` label has been applied to help track issues requiring attention.
labels:
-stale
```
</details>
1. **Missing Assignee Management**
Policy:All finding issues must have designated owners
-Trigger:Issues without assignees after 48 hours of creation
-Action:Add `needs-assignee` label
-Exception:Issues in backlog milestone may remain unassigned
<details>
<summary>Example Policy</summary>
```yaml
- name: Alert when issue has no assignees
conditions:
issue_type: issue
forbidden_labels:
- Missing_Assignee
ruby: resource[:assignees].empty?
state: opened
actions:
redact_confidential_resources: false
comment: |
{{author}}, This issue is missing an assignee.
labels:
- Missing_Assignee
- name: Remove Missing_Assignee label when there are assignees
conditions:
issue_type: issue
labels:
- Missing_Assignee
ruby: |
!resource[:assignees].empty?
state: opened
actions:
remove_labels:
- Missing_Assignee
```
</details>
1. **Past Due Issue Tracking**
#### Required USRM Finding Policies
Policy: Overdue issues require immediate attention and justification
The following checks are performed on a periodic basis using automation (Triage Bot) or agents to improve the quality of USRM findings and enable escalation:
- Trigger: Issues past their due date
- Action: Add `overdue` label and comment requesting updated timeline
- Exception: Issues with approved timeline extensions (documented in comments)
<details>
<summary>Example Policy</summary>
```yaml
- name: Comment on past due issues
conditions:
state: opened
issue_type: issue
forbidden_labels:
- overdue
- bot-ignore
ruby: |
past_due_date?
actions:
redact_confidential_resources: false
comment: |
{{author}} This issue is past due. Please review and update the timeline or mark as completed.
labels:
- overdue
```
</details>
1. **Due Date Enforcement**
Policy: All finding issues must have realistic timelines
- Trigger: Issues older than 7 days without due dates
- Action: Add `needs-due-date` label and request timeline from assignee
- Exception: Research or discovery issues may use milestone dates instead
<details>
<summary>Example Policy</summary>
```yaml
- name: Comment no due date issues
conditions:
state: opened
issue_type: issue
forbidden_labels:
- missing_duedate
ruby: resource[:due_date].nil?
actions:
redact_confidential_resources: false
comment: |
{{author}} This issue has no due date. Please review and update the timeline or mark as completed.
labels:
- missing_duedate
```
</details>
1. **Required Labels Enforcement**
Policy: All finding issues must have required labels for metrics and reporting
- Trigger: Required label is missing from issue
- Action: Add `missing-label` label and tag assignee for action
- Exceptions: Issues in backlog are ignored
<details>
<summary>Example Policy</summary>
```yaml
- name: Alert when an issue is missing required labels
Once you add the missing labels, please remove the `Missing_Labels` label. If you are not a member of SecCompliance, please kindly ignore this message.
labels:
- Missing_Labels
```
</details>
1. Required Labels Enforcement: All finding issues must have required labels for metrics and reporting
2. Due Date Encorcement: All finding issues must have realistic timelines
3. Past Due Issue Tracking: Overdue issues require immediate attention and justification
4. Missing Assignee Management: All finding issues must have designated owners
5. Automated Nudging: Automated nudging when issues remain inactive
### Remediation and Closure
@@ -622,11 +452,11 @@ The Finding Identifier is responsible for validating that the remediation is com
### Support Channels and Updates
Please reach out to `#security_help` in slack, or tag the finding coordinator in the respective issue. USRM updates will be published weekly in `#security_discuss`. Monthly recordings will be [published](https://drive.google.com/drive/folders/1uC1aVlSoy4-bfvc4MIpwtKSznvx1e8Up?usp=drive_link) (internal-only) with more in-depth analysis. Periodic meetings with Risk Source Owners will be conducted to reviews trends and gather feedback.
Please reach out to `#security_help` in slack, or tag the finding coordinator in the respective issue. USRM updates will be published in `#security_discuss`. Monthly recordings will be [published](https://drive.google.com/drive/folders/1uC1aVlSoy4-bfvc4MIpwtKSznvx1e8Up?usp=drive_link)(internal-only) with more in-depth analysis. Periodic meetings with Risk Source Owners will be conducted to reviews trends and gather feedback.
