Prioritize vulnerabilities
After you scan your software, DigiCert® Software Trust Manager automatically generates a Threat detection report.
When Common Vulnerabilities and Exposures (CVEs) are detected in your software, it is recommended that you perform an impact analysis for the reported CVEs, and then work on how to resolve the CVE.
Follow these guidelines to navigate you through the Threat detection report and identify factors you may want to consider in your impact analysis to prioritize identified CVEs in your software.
View scan report
To view your Threat detection report:
Sign in to DigiCert ONE.
Navigate the Manager menu (top right) > Software Trust.
Select Threat detection.
Click on the scan alias to view more details.
Identify deployment risks in your software
To review deployment risks:
In the Threat detection report, scroll to Deployment risks to view a list of all deployment risks found in your software.
Identify the status column.
Nota
Only critical (P0) risks will result in a Fail status. All other risks (P1-P4) found in your software will be displayed with a Pass status. Learn more
Click on the Deployment risk ID to review the following:
Files impacted lists all components impacted by the vulnerability.
Problem provides a description of the deployment risk.
Next steps provides a solution to mitigate the risk.
More information provides details regarding the severity, type of deployment risk, and the effort required to mitigate the risk.
Identify common vulnerabilities in your software
To review a CVEs:
In the Threat detection report, scroll to Common vulnerabilities and exposures (CVE) to view a list of all CVEs found in your software.
Identify the Severity column.
Nota
Only high severity CVEs will result in a Fail status. All other risks (Medium-Low) found in your software will be displayed with a Pass status. Learn more
Click on the CVE ID to review the following:
Components and dependencies impacted lists all components impacted by the vulnerability.
Description provides a description of the vulnerability.
Nota
The information provided here, is pulled directly from the National Vulnerability Database (NVD). It is possible for new vulnerabilities to be published without a description or solution. In these events, it may be useful to refer to the documentation below to determine how to interpret the information you have and refer to common methods to resolve a vulnerability.
To view solutions provided in the NVD:
Click on the link in the CVE ID field.
Scroll down to References to Advisories, Solutions, and Tools.
Review solutions provided by different sources.
More information provides information regarding how the severity of the vulnerability was calculated:
Field
Description
Attack vector
Attack vector measures the access required for an attacker to exploit a vulnerability.
Attack complexity
Attack complexity measures the level of difficulty required for an attacker to exploit a vulnerability.
Privileges required
Privileges required measures the permissions required for an attacker to exploit a vulnerability.
User interaction
User interaction measures whether an attacker requires a user to perform a specific action to exploit a system.
Scope
Scope measures whether a vulnerability in one system or component impacts other resources beyond its security scope. It may be useful to evaluate if a vulnerability in a less important artifact could affect your critical artifacts.
Confidentiality impact
Confidentiality measures the potential of an attacker accessing sensitive information during a successful exploit of the vulnerability.
Integrity impact
Integrity measures if an attack could modify a system component by adding, changing, or removing information therefore impacting the trustworthiness and accuracy of information.
Availability impact
Availability measures the potential ability of an attacker to disrupt or prevent access to your services or data after a successful exploit of the vulnerability.
Software artifact
The vulnerability location affects the potential impact and the scope of the vulnerability if it is successfully exploited. By identifying the specific areas of weakness, you can focus on hardening those points and reducing the potential entry points for attackers.
Here are some factors you may want to consider when evaluating a vulnerable artifact:
Is the vulnerability in a critical component and dependency?
The significance of a vulnerability can depend on the criticality of the system, component, or dependency it affects. For example, a vulnerability located in a widely used and critical component may have a higher potential impact compared to one in a less essential component. By knowing the exact location and function of the component, you can better understand the extent of possible damage.
Nota
Refer to the instructions above to identify the artifacts affected with a specific vulnerability.
Can the vulnerability affect a critical component and dependency?
Assess the value and criticality of the artifacts or resources that could be affected by the risk. Highly valuable and critical components and dependencies may require a higher level of protection, while less critical components and dependencies may be more acceptable to risk.
Nota
Scope measures whether a vulnerability in one system or component impacts other resources beyond its security scope. It may be useful to evaluate if a vulnerability in a less important artifact could affect your critical artifacts.
Vulnerabilities in your own software
When you as the software publisher are trying to prioritize vulnerabilities in your own software, it's essential to have a systematic and risk-based approach. This allows you to allocate resources efficiently and address the most critical security issues first. Here are some key factors they should consider:
Vulnerability severity
Assess the severity of each vulnerability.. Focus on addressing high and critical severity vulnerabilities first, as they pose the greatest risk to users and the software's security.
Nota
Identify the severity of your vulnerability in the Threat detection report:
Deployment risk severity is shown in the Priority field.
CVE severity is shown in the Severity and Score field.
Potential impact
Consider the potential impact a vulnerability could have on your users, data, and the overall system. Vulnerabilities that could lead to data breaches, unauthorized access, or system compromise should be given higher priority.
Exploitation likelihood
Evaluate the likelihood that a vulnerability will be exploited by attackers. Vulnerabilities that are easier to exploit or have known exploits published should be addressed urgently.
Affected users and environment
Analyze the number of users affected by the vulnerability and the environments in which your software is deployed. Critical vulnerabilities impacting a larger user base or widely used environments should be prioritized higher.
Attack surface
Assess how easily an attacker can access the vulnerable component. Exposed components accessible from the internet or high-risk network segments deserve increased attention.
Age of vulnerability
Consider the age of the vulnerability and whether it has been publicly disclosed or exploited. Older vulnerabilities with known exploits might require immediate attention.
Internal expertise
Consider the availability of in-house expertise to address specific vulnerabilities. Some issues may require specialized knowledge, and prioritizing them based on the team's capabilities is prudent.
Customer feedback and use cases
Take into account customer feedback and real-world use cases to identify critical vulnerabilities that might not be apparent from standard vulnerability assessment processes.
Compliance requirements
Consider whether certain vulnerabilities need to be addressed to comply with industry regulations or contractual obligations.
Business impact
Assess the potential business impact of the vulnerability. Critical systems, sensitive data, or revenue-generating functionalities should be protected with higher priority.
Dependencies
Take into account any third-party libraries or components used in the software that might introduce additional vulnerabilities. Addressing these dependencies promptly can mitigate risks.
Mitigation options
Evaluate whether there are temporary mitigations that can be applied until a permanent fix is available.
By considering these factors, you can develop a risk-driven approach to prioritize vulnerabilities effectively, ensuring that resources are allocated to address the most critical security issues first. Additionally, fostering a culture of security awareness and responsiveness within the development team can further enhance the overall security posture of your software.
Vulnerabilities in third-party code used in your software
When you as a software publisher integrates third-party code or libraries into your software, you need to be particularly diligent in prioritizing vulnerabilities. Here are some crucial considerations:
Risk assessment
Conduct a comprehensive risk assessment of the third-party code. Evaluate the impact of potential vulnerabilities on the overall security of the software. Consider factors like data exposure, privilege escalation, and potential for remote code execution.
Vulnerability severity
Prioritize vulnerabilities in the third-party code based on their severity. Address high and critical severity issues first, as they can pose significant risks to the software and its users.
Nota
Identify the severity of your vulnerability in the Threat detection report:
Deployment risk severity is shown in the Priority field.
CVE severity is shown in the Severity and Score field.
Dependency tree
Understand the dependency tree of the third-party code to identify which components are directly integrated and which are indirectly brought in as dependencies. Prioritize vulnerabilities in the direct dependencies first, as they have a more immediate impact.
Active vs. deprecated libraries
Determine whether the third-party library is actively maintained and supported. Deprecated or abandoned libraries may not receive security updates, making them riskier to use.
Patch availability
Check whether patches or updates are available for the vulnerable third-party code. Prioritize vulnerabilities with available fixes, as they can be addressed more easily.
Vulnerability disclosure date
Take into account the disclosure date of the vulnerability. Known and publicly disclosed vulnerabilities may already be targeted by attackers, warranting higher priority.
Popularity and adoption
Consider the popularity and adoption rate of the third-party library. Widely used libraries may attract more attention from attackers, so their vulnerabilities should be addressed promptly.
Security history of the library
Research the security history of the third-party library. Libraries with a history of frequent vulnerabilities or slow response to issues may require special attention.
Expert review
Seek expert opinions, such as security researchers or penetration testers, to identify potential vulnerabilities and their priority for fixing.
Code reachability
Determine how reachable the vulnerable code is from the software's entry points. Vulnerabilities in code accessible from external sources or user inputs may be more critical.
Compliance requirements
Consider whether addressing specific vulnerabilities in third-party code is necessary to comply with industry standards or regulations.
Testing and verification
Ensure that any updates or fixes to the third-party code are thoroughly tested and verified to avoid introducing new issues.
Communication with third-party developers
Establish communication with the developers of the third-party code to learn about their security practices and plans for addressing vulnerabilities.
Mitigation strategies
Implement temporary mitigations if an immediate fix is not available. This could include limiting access or functionality related to the vulnerable code.
By taking these factors into account, a you can prioritize vulnerabilities in third-party code effectively and minimize security risks associated with using external libraries in your software. Additionally, maintaining a regular update and monitoring process for third-party components can help ensure a more secure and resilient software product.
Impact on business continuity
Assess your organization's ability to recover from a potential incident. Most organizations require specific data to remain confidential, accurate, and available. This applies to a wide variety of organizations, such as: healthcare services, e-commerce and online businesses, financial, emergency response, critical infrastructure, industrial control, transportation, and aviation systems.
Evaluate whether the vulnerability poses any compliance issues or legal ramifications to your organization. While some risks may have minimal operational impact, they could still have severe legal consequences.
Data sensitivity
Assess if the vulnerability exposes highly sensitive information, this can increase the potential impact, especially if the data is personal, financial, or classified.
Nota
Confidentiality measures the potential of an attacker accessing sensitive information during a successful exploit of the vulnerability.
Data accuracy
Assess if the vulnerability could lead to unauthorized modifications or tampering of data, this can increase the impact the vulnerability has on the reliability and trustworthiness of critical information.
Nota
Integrity measures if an attack could modify a system component by adding, changing, or removing information therefore impacting the trustworthiness and accuracy of information.
Data availability
Assess if the continuous and reliable functioning of the affected system or service is critical to your organization's operations. This implies that any disruption or unavailability of the system can have severe consequences, leading to significant financial losses, reputational damage, and even potential safety risks.
Nota
Availability measures to the potential ability of an attacker to disrupt or prevent access to your services or data after a successful exploit of the vulnerability.
What is your organizations risk tolerance?
Consider your organization's risk appetite and tolerance level. If your organization has robust disaster recovery and business continuity plans in place, it may be more inclined to accept certain risks with lower potential damage. Some organizations may be more risk-averse and choose to address even minor risks, while others with a higher risk appetite may be more willing to accept certain risks.
You may also consider performing a cost-benefit analysis to weigh the potential damage against the cost of remediation. If the cost of fixing the vulnerability exceeds the potential losses from exploitation, accepting the risk might be a reasonable approach.
Common frameworks for evaluating vulnerabilities
Below are two commonly used decision-making tools that could help you assess whether to prioritize a vulnerability.
Cost-benefit analysis
Assess the financial costs associated with addressing the vulnerability and compare the cost with the anticipated benefits gained from mitigating the risk. This approach helps you determine if accepting the risk is the most cost-effective approach, especially if the vulnerability's potential damage is minimal compared to the cost of fixing it.
Cost
Evaluate expenses related to the development, testing, and deployment of security patches or updates, as well as any potential downtime, loss of productivity, and resource allocation required for the remediation process.
Benefit
Evaluate the risk that the vulnerability poses to your organization. Consider how much damage this vulnerability could have on your organization, how much safer your organization is if you reduce the likelihood of a successful exploit, potential data breaches, financial losses, damage to reputation, and legal liabilities.
Nota
Impact measures consequences of a vulnerability being exploited by combining the score of these three factors: confidentiality, integrity, and availability.
Risk-benefit analysis
Assess the potential risks associated with not addressing a software vulnerability and compare the potential risks with the benefits of remediation. The goal is to determine if accepting the risk is the most productive approach, especially if the vulnerability is difficult to exploit.
Risk
Evaluate probability of a successful exploit, the potential impact of the exploit on the organization's artifacts and data, the likelihood of reputational damage, and any regulatory or legal consequences that may arise from a breach.
Benefit
Evaluate the risk that the vulnerability poses to your organization. Consider how much damage this vulnerability could have on your organization, how much safer your organization is if you reduce the likelihood of a successful exploit, potential data breaches, financial losses, damage to reputation, and legal liabilities.
Nota
Attack complexity measures the level of difficulty required for an attacker to exploit a vulnerability.