A risk register is not exciting. It is a spreadsheet. But it is the spreadsheet that turns supply chain security from a collection of ad hoc reactions into a managed program. Without a risk register, every supply chain incident is a surprise. With one, you have already identified the risk, assessed its likelihood and impact, defined a mitigation plan, and assigned an owner.
Most organizations either have no supply chain risk register at all, or they have a generic IT risk register that treats software supply chain risks as a single line item. Neither approach is adequate given the complexity and frequency of supply chain threats.
What Belongs in a Supply Chain Risk Register
A supply chain risk register tracks risks specific to the software components your organization consumes, produces, and depends on. Each risk entry includes:
Risk Identification
Risk ID. A unique identifier for tracking.
Risk title. A concise description of the risk (e.g., "Dependency on abandoned npm package in payment service").
Risk description. A detailed explanation of the risk, including the threat scenario, the affected assets, and the potential consequences.
Risk category. Categories help organize risks and identify patterns. Common supply chain risk categories include:
- Dependency vulnerability: Known CVEs in third-party components
- Abandoned dependency: Components with no active maintenance
- Single-maintainer risk: Critical dependencies maintained by one person
- License compliance: Components with licenses incompatible with your use
- Build pipeline compromise: Risks to the integrity of your build and deployment process
- Registry availability: Dependency on package registries for builds
- Vendor risk: Risks from commercial software vendors
- Transitive dependency risk: Risks from components you do not directly control
Affected assets. Which projects, services, or systems are affected by this risk.
Date identified. When the risk was first identified.
Risk Assessment
Likelihood. The probability that the risk materializes. Use a consistent scale:
- 1 (Rare): Less than 5% chance in the next 12 months
- 2 (Unlikely): 5-20% chance
- 3 (Possible): 20-50% chance
- 4 (Likely): 50-80% chance
- 5 (Almost certain): Greater than 80% chance
Impact. The consequence if the risk materializes. Use a consistent scale:
- 1 (Negligible): No operational or financial impact
- 2 (Minor): Minimal operational disruption, less than $10K cost
- 3 (Moderate): Partial service disruption, $10K-$100K cost
- 4 (Major): Significant service disruption, $100K-$1M cost
- 5 (Critical): Complete service outage or data breach, greater than $1M cost
Risk score. Likelihood multiplied by Impact. Scores range from 1 to 25.
Risk level. Derived from the risk score:
- 1-4: Low
- 5-9: Medium
- 10-15: High
- 16-25: Critical
Risk Response
Response strategy. One of four standard responses:
- Mitigate: Implement controls to reduce likelihood or impact
- Transfer: Shift the risk to a third party (insurance, contractual SLAs)
- Accept: Acknowledge the risk and monitor without active mitigation
- Avoid: Eliminate the risk by removing the risk source (replace the dependency, remove the feature)
Mitigation plan. For risks being mitigated, describe the specific actions planned. Be concrete: "Migrate from package X to package Y by Q2 2024" rather than "Evaluate alternatives."
Residual risk. The remaining risk level after mitigation is applied. If the mitigation reduces likelihood from 4 to 2 but impact remains at 4, the residual risk score is 8 (Medium).
Ownership and Tracking
Risk owner. The person accountable for managing this risk. This should be a named individual, not a team.
Mitigation owner. The person responsible for executing the mitigation plan (may differ from the risk owner).
Review date. When this risk should be reviewed next. Critical and high risks should be reviewed monthly. Medium risks quarterly. Low risks annually.
Status. Current status of the risk and mitigation:
- Open: Risk identified, mitigation not started
- In progress: Mitigation underway
- Mitigated: Mitigation complete, residual risk accepted
- Accepted: Risk accepted without mitigation (with documented rationale)
- Closed: Risk no longer applicable
Populating the Register
Automated Risk Identification
Many supply chain risks can be identified automatically from your dependency data:
From SBOM analysis:
- Dependencies with known vulnerabilities (risk category: dependency vulnerability)
- Dependencies with no recent releases (risk category: abandoned dependency)
- Dependencies with a single maintainer (risk category: single-maintainer risk)
- Dependencies with restrictive licenses (risk category: license compliance)
From build pipeline analysis:
- Unpinned dependencies in build configurations (risk category: build pipeline compromise)
- Build steps that download artifacts from external sources without verification
- CI/CD configurations that grant excessive permissions
From vendor assessments:
- Commercial software vendors without SBOM transparency
- Vendors with poor patch release cadence
- Vendors without security certification
Manual Risk Identification
Some risks require human analysis:
- Concentration risks (many projects depending on the same library)
- Geopolitical risks (dependencies from regions with export restrictions or sanctions)
- Strategic risks (dependency on a competitor's open source project)
- Architectural risks (tight coupling to a specific vendor or framework)
Governance Process
Regular Review Cadence
Establish a regular cadence for risk register review:
Monthly: Review all critical and high risks. Update status, reassess likelihood and impact, and verify mitigation progress.
Quarterly: Review all risks. Add newly identified risks. Close risks that are no longer applicable. Report aggregate risk metrics to leadership.
Annually: Comprehensive review of risk categories, scoring methodology, and governance process. Update the risk appetite statement if organizational context has changed.
Escalation Criteria
Define clear escalation criteria:
- New critical risks are escalated to the CISO within 24 hours
- Risks that increase in score by more than 5 points are escalated to the risk owner's manager
- Mitigation plans that miss their deadline by more than 30 days are escalated
Metrics
Track these metrics from your risk register:
- Total risk count by level (Critical, High, Medium, Low)
- Risk trend over time (are aggregate risk scores increasing or decreasing?)
- Mitigation completion rate (percentage of planned mitigations completed on time)
- Mean time to mitigate by risk level
- Risk acceptance count and aging (how many risks are accepted and for how long)
- New risks identified per quarter (helps measure detection effectiveness)
Common Mistakes
Scoring inflation. If every risk is scored as critical, the register is useless for prioritization. Be honest about likelihood and impact. A vulnerability in an internal tool that is not internet-facing is not the same impact as one in a customer-facing API.
Missing residual risk. Every mitigated risk should have a residual risk score. Mitigation rarely eliminates risk entirely, and understanding the remaining exposure is important for decision-making.
Stale entries. A risk register that is not regularly reviewed becomes misleading. Closed risks that are still listed as open, or mitigated risks with outdated status, undermine confidence in the register.
No ownership. Risks without named owners do not get managed. Assigning risk to a team rather than an individual diffuses accountability.
How Safeguard.sh Helps
Safeguard.sh populates your supply chain risk register automatically by identifying vulnerable dependencies, abandoned packages, single-maintainer libraries, and license compliance issues across your portfolio. Each identified risk includes the affected projects, severity assessment, and available mitigation paths. The platform tracks mitigation progress as dependencies are updated and vulnerabilities are resolved, keeping the risk register current without manual data entry. For organizations building a supply chain risk management program from scratch, Safeguard provides the data foundation that makes the risk register actionable rather than aspirational.