Managing Software Risk in a World of Exploding VulnerabilitiesManaging Software Risk in a World of Exploding Vulnerabilities

COMMENTARY

It's a perfect storm: The cost of a data breach is rising, known cyberattacks are becoming more frequent, security expertise is in short supply, and the demand for connectedness — to deliver and act on even the most sensitive of data across all devices, and all the way to the network edge — is unyielding. A recent example that affects anyone who texts between Android and iPhone devices is the Salt Typhoon attack. Meanwhile, industry and government regulations are tightening, demanding stricter proof of security measures and faster reporting of breaches, raising the stakes for "getting it wrong."

In its most recent analysis, Verizon Business found that organizations take an average of 55 days to remediate 50% of critical vulnerabilities listed in the Cybersecurity and Infrastructure Security Agency's (CISA's) Known Exploited Vulnerabilities (KEV) catalog. Unfortunately, cybercriminals respond far more quickly, with mass exploitations of the CISA KEV appearing on the Internet within a median of five days. 

That's why organizations and development teams must evolve from "being prepared" to "managing the risk" of security breaches.

Vulnerability risk management is not a new concept, but I am noticing that organizations are attempting to manage risk in one of two ways — by setting up guardrails (proactive) or patching (reactive). Neither is optimal.

The key is to balance the two, highlighting the critical importance of adopting a DevSecOps approach. "DevSec" solutions are focused on shifting security left by integrating security gates into the continuous integration and continuous delivery (CI/CD) pipeline. "SecOps" solutions are focused on detecting and responding to threats in the runtime environment. 

Here's a look at the challenges to each approach.

The Vulnerability Patching Approach

On its face, patching sounds simple enough: When a software vulnerability is revealed, patch it. However, that assumes that developers and security teams have the resources to quickly monitor for issues, create or identify patches, and then test and apply those patches — before cyberattackers can take advantage of the vulnerabilities themselves. 

AI will eventually help developers more efficiently identify vulnerabilities, but we're not at that point yet. Right now, AI and the demand for AI-enabled applications is only adding to the potential for unidentified vulnerabilities. AI code generation tools increase the likelihood of introducing hard-to-trace snippets of code from unidentified sources. While many of today's vulnerability scanners rely on identifying code packages rather than code snippets. 

The Guardrails Approach

The guardrails approach is more nuanced than the vulnerability patching approach, but it comes with its own set of challenges.

While organizations that focus on the patching approach take a more reactive stance, the guardrails approach is grounded in proactive protection and mitigating controls. These include:

All of these strategies are highly effective; however, it's often challenging for organizations to integrate these and other guardrails into their infrastructure. It is even more challenging to harden existing application pipelines. Striking the balance between security and innovation has gotten more difficult as pressure to improve security increases from all sides and the impact of a security breach reverberates up and down the supply chain.

Creating a Balanced Approach to Software Risk Management

Used together, patching and guardrails can help organizations maintain a balance between efficient vulnerability management and proactive security monitoring and management. 

Organizations should assess risk based on key factors for their business, including what mitigating controls they have in place in the runtime environment. While the Common Vulnerability Scoring System, with Base Metrics and Temporal and Environmental Metrics, offers some indication of the level of risk a known vulnerability creates, this data does not and cannot account for the specific context of a deployed application. Organizations need to account for additional factors such as external exposure and mitigating controls.

Using open source can help, since the community is committed to transparency and clear communication about newly discovered vulnerabilities and how to get fixes for them. In fact, in addition to prioritizing the use of open source, organizations should take their cue from the open source community and establish their own processes for sharing detailed information about identified vulnerabilities — internally but also with partners and vendors following principles of responsible disclosure. 

Responsible disclosure and open data are critical for customers and communities to fully understand the vulnerabilities that may impact them, as well as to ensure that the data necessary to make appropriate, informed decisions is widely available.

Offering multiple remediation options, such as software updates and/or patches, and automated guardrails at all stages of the application life cycle including CI/CD and runtime mitigations, provides flexibility in addressing vulnerabilities across diverse environments. By combining these elements, organizations can create a comprehensive vulnerability risk management program that effectively mitigates security risks across their entire IT infrastructure.