Unified Security Risk Management Program

Purpose

The Unified Security Risk Management (USRM) program ensures consistent identification, documentation, prioritization, treatment, and tracking of security observations, recommendations, and findings to improve efficiency, enable holistic visibility, and increase adoption rates of security recommendations. The process will also act as an input to security risk management processes across the org allowing for quicker decision making.

Scope

The program is designed to support any Security Division recommendations, findings, and observations. The onboarding of different sources into the USRM process will be deployed through a phased approach to ensure proper standardization and successful adoption across teams. These sources will then be mapped to individual STORM risks.

Coverage includes identified sources:

Roles and Responsibilities

Authority Matrix

When security findings are identified, the following management levels must be informed based on priority. These managers have authority to intervene if they disagree with the proposed remediation approach or determine an alternative treatment is more appropriate.

Procedure

The USRM workflow can be seen below:

Service Level Commitments

These commitments establish standardized timing expectations for each phase of the process. They ensure consistent response times across all security teams and provide clear expectations to business stakeholders regarding when they can expect actions and responses during the finding lifecycle.

Identification

Each team in Security has their own defined workflows. One of the outputs of these workflows is a finding being identified that requires action or remediation. In order to normalize findings in order to assess priority, the following steps should be completed.

Once identified, the finding should be opened in a issue following the team’s standard format and issue templates. The finding identifier is responsible for opening an issue in the related GitLab project. The finding identifier fills out all necessary information, remediation recommendations and submits the finding to the remediation manager for validation. The finding coordinator is responsible for managing the finding through the lifecycle. This includes ensuring linkages associated risk issues, validating the finding with the Remediation Manager, tracking all remediation progress and updating the GitLab issue with current information and status updates. Each finding will be assigned a risk rating, which should drive the priority of remediation.

Drafting Finding Description Guidance

The description should include the who, what, when, where, why, and how related to the finding. As a review step, if you knew nothing about this finding could you understand the finding, how it was identified, and the effect it has on objectives? Consider leveraging the 4Cs model:

• Condition - current state
• Criteria - desired state based on policy, requirement, control, regulation, etc.
• Cause - root cause of the observation
• Consequence - actual or potential effect on objectives/assets

For additional helpful risk drafting guidance from the Prod Sec department can be found here.

Required Labels

Required labels need to be applied to enable prioritization and reporting and metrics. These labels are as follows:

Optional Labels

Team-Specific Labels (preserve existing conventions)

Risk Rating

Many teams (example SIRT) have existing risk assessment methodologies. For those that don’t, please use the standardized GitLab priority and severity framework, adapted for security division requirements:

Priority Rating (Business Impact and Urgency)

Severity Rating (Technical Impact and Complexity)

Risk Assessment Guidelines

When assigning priority and severity ratings, consider these factors:

Priority Assessment Factors:

• Business Impact: Effect on operations, customers, and revenue
• Regulatory Requirements: Compliance deadlines and obligations
• Stakeholder Urgency: Leadership and customer expectations
• Resource Availability: Team capacity and competing priorities

Severity Assessment Factors:

• Technical Impact: System functionality and security posture
• Scope of Affected Systems: Number and criticality of impacted assets
• Exploitability: Ease of exploitation or occurrence
• Compensating Controls: Existing mitigations that reduce severity

Recommendations

Recommendations reflect how the finding will be addressed. ISO 31000 recommends applying one or more of the following approaches to treating risks:

• Avoid - Deciding not to start or continue with an activity that gives rise to the risk, or removing the risk source altogether
• Mitigate - Introducing controls that reduce either the likelihood of the risk occurring or the impact.
• Transfer - Sharing the risk with a third-party through contracts, outsourcing, or insurance.
• Accept - Making an informed decision to take the risk.

Recommendations should:

• Address the root cause - If this can’t be done, the recommendation should reduce the likelihood or impact of the risk.
• Be low-context.
• Achievable – Realistic given available resources, skills, and constraints.
• Actionable – Clearly states what needs to be done, by whom, and when.

Additional helpful guidance from the Red Team can be found here.

Remediation Plan

Using your recommendation, work with the appropriate owner group to develop a SMART remediation plan.

Business Risk & Security Risk Owner

Once the remediation plan is documented, both the Business Risk Owner and Security Risk Owner must be informed.

Business Risk Owner:

• Accountable for the overall risk presented by the finding and response decision
• Must be informed of the identified fionding and proposed remediation plan
• Has authority to approve the remediation approach or request modifications
• Can choose to formally accept the risk if remediation is not feasible or justified

Security Risk Owner:

• Represents the originating security team that identified the finding
• Reviews the proposed remediation plan to ensure it adequately addresses the security recommendation
• Provides technical validation and security acknowledgment
• Escalates concerns if the remediation approach leaves significant residual risk

Tagging both owners in the GitLab issue ensures proper visibility and accountability, which greatly increases the likelihood that the risk will be appropriately addressed.

Risk Acceptance

There may be instances where we decide to accept risk rather than avoid, mitigate, or transfer it. If risk acceptance is desired for a security finding, the remediation owner must provide:

1. Risk Description: Clear statement of the risk
2. Business Justification: Why acceptance is necessary
3. Compensating Controls: What mitigations are in place to reduce exposure
4. Expected Duration: How long acceptance is needed (maximum is 24 months based on risk rating)
5. Residual Risk: What risk remains after compensating controls

The finding coordinator validates that acceptance is appropriate based on our risk tolerance and compliance/regulatory obligations. Approvals are required from the department’s management team per the Authority Matrix.

Once approved, apply the risk-acceptance::active label and the appropriate risk level label. The issue remains open as an active risk acceptance that will be tracked and periodically reviewed.

Periodic Review Schedule

The finding coordinator performs periodic reviews at these intervals:

For each review, the finding coordinator will:

1. Evaluate if original conditions still exist
2. Assess whether severity has changed
3. Review changes to threat landscape or business environment
4. Confirm acceptance justification remains valid
5. Evaluate if remediation options have become available
6. Verify compensating controls are still effective

Security Acknowledgment

Security will validate that the following is in place:

• Treatment plan or risk acceptance
• Due date for follow-up/remediation testing
• Required labels
• Monitoring in place
• Finding is mapped to related risk issue

Monitoring

Recommendation Quality and Escalation

To ensure findings from security teams are accurate, current, and properly managed, we leverage triage bot. This bot will support issue quality, nudging/escalation, and timely resolution of security findings across the division.

Finding Coordinator

The Finding Coordinator is responsible for ensuring findings remain active, current, and have defined remediation timelines. These tasks are aided by the triage bot policies. They will also initiate escalations and ensure blockers are cleared. The finding coordinator role is filled by members of the SecCompliance and SecRisk teams. For more detailed responsibilities and procedures of the finding coordinator, please review the collapsed sections below.

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

- 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

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

  - 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

1. Past Due Issue Tracking

Policy: Overdue issues require immediate attention and justification

• Trigger: Issues past their due date
• Action: Add overdue label and comment requesting updated timeline
• Exception: Issues with approved timeline extensions (documented in comments)

  - 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

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

  - 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

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

  - name: Alert when an issue is missing required labels
    conditions:
      issue_type: issue
      forbidden_labels:
          - Missing_Labels
          - bot-ignore
      ruby: |
          [" list labels"].any? { |rl| !resource[:labels].any? { |l| l.start_with?(rl) } }
      state: opened
      actions:
        redact_confidential_resources: false
        comment: |
          {{author}} this issue does not have an appropriate project work labels.

          Please label it accordingly based on the Labeling Guide). The following labels are missing:
          #{ [" list labels"].map{ |rl| "- #{ rl } #{ resource[:labels].any?{ |l| l.start_with?(rl) } ? ':white_check_mark:' : ':x:' }"}.join("\n") }

          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

Remediation and Closure

The Finding Identifier is responsible for validating that the remediation is completed and effectively mitigates the finding. Once validated, the issue can be closed with appropriate documentation of the remediation evidence.

References

Support Channels

Please reach out to #security-help in slack, or tag the team managing the issue in the respective issue.

Internal Documentation

• Unified Security Risk Management Epic
• Security Risk Sources
• GitLab Issue Triage Guidelines
• StORM Program Procedures
• Observation Management Procedure
• Vulnerability Resolution SLAs
• GitLab Security Handbook

View page source - Edit this page - please contribute.