The Product Security Risk Register (PSRR) is a centralized framework for identifying, evaluating, prioritizing, mitigating, and monitoring systemic security risks in GitLab’s product. PSRR is driven by and follows the STORM process and Unified Security Risk Management (USRM) methodology from our Security Risk Team.
The PSRR reduces product security risk through:
The PSRR tracks systemic weaknesses, inadequate design choices, or functional logic that expose GitLab’s product to compromise and data leaks, focusing on risks with cascading consequences across the platform.
In Scope:
Out of Scope:
You can find this list in the STORM repository (internal), or consult the dashboard here (internal).
To create a new issue follow this link (internal). Make sure to reference the guide to defining well-articulated risks.
PSRR follows the USRM roles and Authority Matrix. The two key roles for PSRR risks are:
| Role | Responsibility |
|---|---|
| Business risk owner | Accountable for the overall risk related to the finding. Can make decisions on whether to remediate or accept the risk. Required approval level per USRM Authority Matrix. |
| Security risk owner | Security team member accountable for validating the risk treatment plan and implementing risk monitoring. |
The SPA team is additionally responsible for these activities:
PSRR follows the USRM workflow with product security-specific stages:
| Stage | Entry Criteria | Key Activities | Exit Criteria |
|---|---|---|---|
| Identified | Risk discovered through assessment, incident, or escalation | - Score risk using STORM methodology - Apply risk rating and scope labels - Identify Business risk owner and Security risk owner |
Risk scored with owner identified |
| Treatment plan defined | Business risk owner acknowledged risk | - Select risk response - Define KRIs and milestones - Set target dates - Obtain approvals (if needed) - Apply health labels |
Treatment plan approved with dates |
| In progress | Treatment plan approved, resources allocated | - Execute treatment activities - Onboard Technical Program Manager (if needed) - Hold regular syncs - Update health labels based on progress |
Remediation activities completed |
| Blocked | Work stopped due to dependency | - Document blocker in issue - Escalate to remove blocker - Update health-treatment label - Set target unblock date |
Blocker label removed |
| Monitored | Risk response is “Monitor” - no active remediation planned | - Track KRIs monthly - Review risk score quarterly - Assess for priority changes - Update if new incidents occur |
Risk priority increases OR risk accepted/closed |
| Risk accepted | Formal acceptance process | - Follow USRM risk acceptance procedure - Set periodic review per USRM schedule - Monitor for changes |
Acceptance recorded, review scheduled |
| Closed | Remediation validated or risk eliminated | - Security risk owner validates effectiveness - Document outcome - Close issue |
Risk within tolerance or eliminated |
PSRR follows STORM risk scoring methodology (Likelihood × Impact) with evidence-based adjustments using real-world data.
Start with STORM’s qualitative assessment:
Evidence is collected from related security events within the past 2 years:
Note: Evidence from only one source is sufficient - the scoring methodology accounts for incomplete data across sources.
Count total evidence items across all severities:
| Total Count | Modifier |
|---|---|
| ≥10 items | +2 |
| ≥5 items | +1 |
| 1-4 items | 0 |
| 0 items | -1 |
Application: final_likelihood = max(1, min(6, base_likelihood + modified))
Calculate weighted score using severity-based points:
severity::1: 3 points eachseverity::2: 2 points each| Weighted Score | Modifier |
|---|---|
| ≥10 points | +2 |
| ≥5 items | +1 |
| 1-4 points | 0 |
| 0 points | -1 |
Application: final_impact = max(1, min(5, base_impact + impact_mod))
Risk Score = final_likelihood × final_impact
This score (1-30) determines the RiskRating:: and psrr-risk-rating:: labels applied during the prioritised stage.
Manual validation of evidence and base score is applied if evidence-based modifiers and base scoring appear contradictory (for example, base likelihood=1 but ≥5 incidents, or base impact=1 but weighted score ≥10).
Key Risk Indicators are measurable metrics that track whether a risk is increasing, decreasing, or stable over time. KRIs are defined during the treatment-plan-defined stage and tracked throughout the risk lifecycle.
KRIs are reviewed during monthly PSRR reviews, see health KRI definitions.
| Your Situation | Primary KRI | Example Metrics | Thresholds |
|---|---|---|---|
| “New risk, zero incidents” | Implementation: Measure control adoption (Leading) | Control: 45% of images with SLSA provenance Exposure: 550 images without attestation Trend: +50 unprotected images this quarter |
Green: Coverage ≥95% OR trending down ≥20%/quarter Yellow: Coverage 75-94% OR flat Red: Coverage <75% OR increasing |
| “High incident frequency (≥5/quarter)” | Effectiveness: Incidents (Lagging) + Predictive (Bayesian) |
Historical: 30 leaks in 6 months, avg 500 unscoped secrets Current: 650 unscoped secrets Predicted: 6.5 leaks this month Actual: 5 leaks last month |
Green: Predicted ≤ baseline AND incidents decreasing Yellow: Predicted 1.5-2x baseline Red: Predicted >2x baseline |
| “Rare but severe attack” | Implementation: Measure exposure (Leading) |
Exposure: 23% of traffic on HTTP/1 protocol Critical: 2 authentication endpoints on HTTP/1 Trend: -5% reduction from last quarter |
Green: Trending down ≥20%/quarter Yellow: Flat or <20% decrease Red: Increasing |
| “I don’t have inventory” | Define alternative collection: Sampling or Experimentation |
Sampling: Audit 10% of repos (50 of 500) for exposed secrets → 8% found secrets Experimentation: Red team test of 5 critical endpoints → 2 bypassable |
Green: Sample shows <5% issues Yellow: Sample shows 5-15% issues Red: Sample shows >15% issues |
Note: Most risks should use multiple KRI types.
When observation is impossible or insufficient:
Sampling - Analyze representative subset:
Experimentation - Controlled tests to measure risk exposure:
A PSRR risk may be closed when all of the following are met:
Risk Score Within Tolerance
KRI Targets Achieved
Security risk owner Validation
PSRR extends USRM labels with product security-specific labels for risk categorization, scoring, workflow tracking, and health monitoring.
RiskRating::Critical - Score 26-30RiskRating::High - Score 21-25RiskRating::Medium - Score 11-20RiskRating::Low - Score 1-10psrr-risk-rating::<number> - Any score from 1-30 (such as psrr-risk-rating::25)psrr-scope::<category> - Examples: product-authnz, infrastructure, supply-chain, secrets-management, operationalDepartment::<group>|<section>|Engineering - Department following product categoriesDivision::<team> - Security division based on security team structureRefer to USRM labels
All three health labels are required for each PSRR risk:
| Health Domain | Labels | Red | Yellow | Green |
|---|---|---|---|---|
| Owner | health-owner::red|yellow|green |
No Business risk owner assigned | Assigned but inactive/needs replacement | Regular syncs (≥quarterly) |
| Treatment Plan | health-treatment::red|yellow|green |
No treatment plan or missing dates | Defined but delayed >1 quarter | On track, delays ≤1 quarter |
| KRI | health-kri::red|yellow|green |
Undefined or untracked | Defined, provides partial context | Defined, linked to impact/likelihood |
STORM Risk:1 through STORM Risk:5 - Risk mapped to one of STORM’s Top 5 Risks.STORM::Proposed - Risk proposed for escalation to STORM risk based on business impact and strategic alignment.PSRR adopts GitLab Triage Bot using recommended USRM policies to:
Product Security conducts monthly risk reviews with Engineering and Security leadership to discuss:
Monthly reviews ensure alignment between Product Security and Engineering on risk priorities and resource allocation.
PSRR risks may escalate to STORM based on business impact and strategic alignment. All PSRR risks are also linked to their STORM related risk.
71953a9b)
