The standard means of assessing vulnerabilities may not be enough. Here’s how you can reinforce your open source security and prioritize remediation of vulnerabilities
What’s your role in the vulnerability management process? If you’re a developer, you might often wonder: “Is this remediation work that I’m being asked to do really necessary?” If you’re a security engineer, and your job is to provide lists of security issues to developers to remediate, you might wonder: “Are these the highest priority security issues that our developers need to address?” The key question for everyone is: How should organizations decide which security vulnerabilities are highest priority to address? And is the Common Vulnerability Scoring System (CVSS) sufficient to safeguard your codebase? As the open source community gathers for KubeCon 2022, we look at why security is a significant talking point, and how priority scoring can take your security to the next level.
Here at WhiteSource, we’re looking forward to meeting delegates from the open-source and cloud computing fields at KubeCon, which will take place in Valencia from May 16 – to May 20, 2022. KubeCon has always been a great forum to share insights and collaborate with fellow experts, and we expect this year’s conference to be no exception. Given the headlines surrounding recent breaches to open source code such as Log4j and Spring4Shell we expect that cybersecurity and vulnerability management will generate plenty of discussions
See us at Booth #S61 KubeCon for more interesting discussions about risk assessment
These breaches have demonstrated how exposed major organizations can be when vulnerabilities present cybercriminals with opportunities to attack and disable the software and steal valuable information. In 2021, total damages from global cybercrimes, including those targeting open source, were estimated at $6 trillion, with this number expected to reach $10.5 trillion by 2025. As attacks continue to grow in line with the increased use of open-source software, companies of all sizes acknowledge that they must invest in a vulnerability management program to protect their infrastructure, applications, and data adequately. But are standard methods of identifying, classifying, and mitigating vulnerabilities sufficient to give developers and security leaders peace of mind, or do we need to take a fresh approach?
Most organizations implement a vulnerability management program that is based on the Common Vulnerability Scoring System (CVSS) rating, as recorded in the Common Vulnerabilities and Exposures (CVE) list or National Vulnerability Database (NVD). The goal is to understand better how to prioritize the remediation efforts of some vulnerabilities over others. However, using a vulnerability score on its own is insufficient because it lacks contextual risk factors needed for each unique environment. CVSS is a static scoring system that doesn’t include real-world risk in its assessment. A CVSS score has no relation to the actual assets that it effects and how it will affect them. In fact, the same CVE might have different effects on different assets. Enterprises need to assess the business risk associated with each technical vulnerability, which includes CVSS as just one factor for consideration.
The effectiveness of CVSS as a risk assessment tool is compromized because it can’t prioritize the vulnerabilities that are most dangerous to your particular organization or context. No two organizations are identical, and what may be a serious vulnerability to the codebase may be negligible to another. Furthermore, the overwhelming number of vulnerabilities in container images introduces a particular challenge to organizations — how to identify the most significant risks to your business and know what to tackle and remediate first.
For organizations looking to save time, create more efficient remediation workflows, and lower their risk posture, risk-based vulnerability management should be a future-proof solution that provides companies with genuine security resilience. According to Gartner and Forrester, risk-based prioritization will define future vulnerability management programs.
Although CVSS is the industry standard for assessing the severity of vulnerabilities, it’s not the most effective tool for risk management. We constantly see that the scores of CVEs, as recorded in the CVE list/NVD, fail to reflect the accurate CVSS rating of a given issue when evaluated in its full context. Several contextual factors can help us gain visibility into the risk of a vulnerability and the impact that it will have on our systems. The CVSS score addresses the theoretical level of a CVE exploitability and only classifies 60 percent of the vulnerabilities as high or critical severity. From that number, only 2.5 percent of the vulnerabilities have actual exploits in the wild that are available for attackers to use.
Your vulnerability management system needs to scan continually, monitor, and evolve across a broad range of attack vectors, helping you understand and prioritize the risks to every asset and focus your efforts on the most important things. In addition, it should prioritize results based on context: for example, accurately showing the impact of a specific vulnerability on your environment.
A risk-based approach allows organizations to implement a dynamic tool that supports strategic decision-making and focuses on business value. In addition, the power of the risk-based approach to optimize risk reduction at any level of investment is enhanced by its flexibility, as it can adjust to an evolving risk-appetite strategy as needed, allowing you to apply the right level of control to the relevant areas of potential risk.
It’s becoming clear to organizations that NVD’s CVSS score alone does not provide an effective way to reduce risk exposure. At the same time, security tools identify an ever-growing amount of vulnerabilities in open source packages, container images, and proprietary code. The more tools employed, the more complex the picture becomes, with endless confusing data. This problem is exacerbated by increasing pressure on developers to deliver quickly. Developer resources are stretched to their limits trying to deliver software in accordance with market dynamics, and they don’t want security processes and vulnerability scanning to impede their work. Using threat modeling, a mostly manual and costly process, to identify risks and focus developers on the relevant vulnerabilities becomes even harder and ineffective in such conditions.
Salvation can come from prioritizing vulnerabilities right from their detection, based on their business impact. Adding the business information to any scrutiny of vulnerabilities adds critical context to identifying and assessing them and helps align all relevant functions across the software delivery chain. Using a Business Priority Score, developers will have the contextual data from the detection and be able to validate and fix relevant risky vulnerabilities first.
This goes further than a CVE. For example, with a business priority score, you can tell if a particular CVE resides in a package installed in the DMZ and if that package interacts with financial services or personal information.
Compare that with another CVE in a package that runs in the DMZ and holds static data or another CVE used internally and not exposed to the web. The priorities become much clearer and can now be automated and agreed upon across your organization. With priority comes clarity. With clarity comes better accuracy and efficiency in identifying and mitigating vulnerabilities critical to your particular organization.
Learn more about how WhiteSource can help you protect your source code, data, and applications by prioritizing open source software vulnerabilities. Visit us at booth #S61 at KubeCon. We’d be glad to meet you.