Assess vulnerabilities and govern risk
DigiCert® Software Trust Manager provides centralized visibility into vulnerabilities and software risk across your software supply chain. It helps organizations identify, prioritize, and manage security issues by collecting vulnerability insights from connected repositories, packages, and artifacts.
The Vulnerabilities experience enables you to monitor detected security issues, assess their severity and potential impact, and track remediation progress. The Risk Assessment and Governance capabilities help security and compliance teams evaluate overall software risk, establish governance practices, and make informed decisions based on risk posture and organizational policies.
Together, these capabilities provide the visibility and governance controls needed to strengthen software security, improve risk management, and support secure software development practices across the organization.
Action | Start here when | Outcome |
|---|---|---|
Connect a repository and activate monitoring | A repository enters scope, is migrated, or changes ownership. | The repository, owner, releases, and monitoring status are registered, tested, and approved. |
Review release security posture and trends | A release is published, promoted to production, or reaches a scheduled review date. | Decision-makers understand current exposure, trend movement, and required follow-up actions. |
Triage a release-level vulnerability | A CVE, weakness, or component alert appears for a release. | The alert is validated, prioritized, assigned, and given a target date or escalated to incident response. |
Reassign a finding to the correct owner | The current owner is missing, incorrect, unavailable, or no longer accountable. | Accountability transfers with context, notification, acknowledgement where required, and an auditable timestamp. |
Accept risk for a defined period | A service owner cannot complete normal treatment by the required date. | Residual risk is scoped, justified, approved, monitored, and scheduled for re-evaluation. |
Re-evaluate an accepted risk | Expiry, threat change, new release, scope change, incident, or control change. | The prior decision is closed, replaced, or renewed for a justified period using current evidence. |
Mark a finding invalid | Validation shows the reported condition is absent, unreachable, incorrectly mapped, or otherwise non-applicable. | The finding is marked invalid for a defined scope with evidence, rationale, and audit history. |
Use the decision timeline and notifications | A decision, reassignment, suppression, acceptance, invalidation, scan result, or status change occurs. | Stakeholders receive actionable updates and the authoritative record retains a complete decision history. |
These concepts apply to every workflow and should be reflected in field labels, permissions, reports, and audit evidence.
Concept | Description |
|---|---|
Repository | The canonical source location linked to a business service, owner, release inventory, and monitoring configuration. |
Release | An immutable or versioned software state identified by a release number, tag, build identifier, or equivalent. Decisions must remain attributable to this exact state. |
Dependency | A component included in or required by a release, preferably identified through a manifest or software bill of materials. |
Alert | A scanner or intelligence signal requiring validation. An alert is not automatically a verified vulnerability. |
Finding | A normalized, retained record used for analysis, assignment, decision, and evidence. |
Vulnerability | A verified weakness that can contribute to loss of confidentiality, integrity, availability, safety, or compliance. |
Risk decision | A recorded treatment decision based on likelihood, impact, controls, and business context. |
Risk acceptance | A bounded, independently approved decision to retain residual risk until a fixed expiration, subject to conditions and review triggers. |
Invalid finding | A reproducibly demonstrated false-positive or non-applicable condition, limited to a defined release and deployment scope. |
Decision timeline | The attributable history of state changes, owners, rationale, approvals, evidence, and notifications. |
Verification scan | A current on-demand scan used to support closure, reopening, or a refreshed risk decision. |
Stage | Required action | Decision gate |
|---|---|---|
1. Connect | Register the repository, owner, releases, access, and monitoring configuration. | Is coverage complete, healthy, and tested? |
2. Review | Confirm the active release, data freshness, posture indicators, and trend. | Is there a material alert or adverse change? |
3. Triage | Validate applicability and enrich technical and business context. | Is this a verified vulnerability, incident, duplicate, or invalid finding? |
4. Decide | Assign, remediate, mitigate, transfer, accept, or invalidate with authority. | Is the treatment proportionate, owned, and time-bound? |
5. Verify | Run current checks and reconcile the full affected population. | Does evidence support closure or must work reopen? |
6. Govern | Retain history, notify stakeholders, monitor exceptions, and review patterns. | Are closure, evidence, and systemic follow-up complete? |
Before proceeding, ensure that the following prerequisites are in place:
Connect a repository and enable monitoring. This is to establish traceable monitoring coverage for a source repository and its releases, including release inventory, dependencies, vulnerability detection, ownership, and monitoring health.
Review release security posture and trends. This is to assess the current production release and compare its security posture with earlier releases without relying on an aggregate score alone.
Confirm you are working on the intended repository, release, environment, and affected population.
Use an attributable user identity and the minimum permissions required for the action.
·Preserve evidence at a durable location and link it to the authoritative record.
·Escalate immediately when active exploitation, credential compromise, data loss, safety impact, or material service disruption is plausible.
·Apply the stricter of policy, regulatory, contractual, or incident-driven deadlines.
Open the vulnerability alert.
Navigate to Release Security > Monitoring dashboard > Vulnerabilities. Locate the required vulnerability in the alert list and select it to open the vulnerability details. Review the severity, vulnerability ID, affected dependency, version, first-seen information, and other available vulnerability details.
Review the affected release and dependency.
From the vulnerability details, review the affected repository, release, dependency, and associated vulnerability information. Confirm that the dependency is present in the affected release and determine whether the vulnerability applies to the deployment.
Review the vulnerability details.
Use the information available in the vulnerability details to evaluate the risk, including severity, exploitability, affected assets, and other available evidence. Use this information to determine the appropriate risk treatment.
Record a risk decision.
From the vulnerability details, open Risk decision and select the appropriate action. If accepting the risk, provide the required justification and expiration information, acknowledge the risk, and select Accept risk. Record sufficient information to explain and support the decision.
Track the vulnerability.
Navigate to Release Security > Monitoring dashboard > Vulnerabilities to monitor the vulnerability and its current risk-decision status. Use the available filters to locate vulnerabilities by their relevant status or attributes and track items that still require action.
Verify the vulnerability status.
Return to the vulnerability details after remediation or another risk treatment is completed. Review the latest vulnerability and release information and verify that the affected deployment has been addressed or has an approved risk decision before considering the vulnerability resolved.
Use the Accept risk action when you have reviewed a vulnerability and determined that the associated risk can be accepted. Depending on your user role and the current risk decision, the available actions may vary.
A vulnerability can have one of the following risk decisions:
Risk decision | Available actions |
|---|---|
Not yet reviewed |
|
Pending review |
|
Risk accepted |
|
Invalid finding |
|
Note
A technical justification is required to accept a risk. All risk decision actions are recorded in the audit trail. . The audit trail maintains the history of actions associated with the vulnerability.
The actions available under Action depend on the user's role and the current risk decision. Suppress is available when accepting a risk or marking a vulnerability as invalid.
Navigate to Secure release > Repository tab.
Select repository name.
Select the Releases tab and select the release for which you want to view the vulnerabilities
Select the Vulnerabilites tab.
Locate the vulnerability for which you want to traige and assign an owner for risk decisions.
Alternately, you can also navigate to Secure release> Monitoring dashboard > Vulnerabilities. Locate the vulnerability and select the alert name to open its details. Review the vulnerability information and current Risk decision.
If the risk decision is Not yet reviewed:
Select Action > Assign. The side rail window opens.
Select the person responsible for reviewing the vulnerability,
Enter any relevant Notes. and select Assign.
After assignment, the risk decision changes to Pending review.