{"id":7193,"date":"2025-02-04T09:00:00","date_gmt":"2025-02-04T15:00:00","guid":{"rendered":"https:\/\/www.darkreading.com\/vulnerabilities-threats\/managing-software-risk-world-exploding-vulnerabilities"},"modified":"2025-02-04T09:00:00","modified_gmt":"2025-02-04T15:00:00","slug":"managing-software-risk-in-a-world-of-exploding-vulnerabilities","status":"publish","type":"post","link":"https:\/\/ddi.mohflo.net\/index.php\/2025\/02\/04\/managing-software-risk-in-a-world-of-exploding-vulnerabilities\/","title":{"rendered":"Managing Software Risk in a World of Exploding Vulnerabilities"},"content":{"rendered":"
<\/a><\/div>\n
<\/div>\n

COMMENTARY<\/span><\/span><\/p>\n

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 \u2014 to deliver and act on even the most sensitive of data across all devices, and all the way to the network edge \u2014 is unyielding. A recent example that affects anyone who texts between Android and iPhone devices is the <\/span>Salt Typhoon attack<\/a><\/span>. 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.”<\/span><\/p>\n

In its <\/span>most recent analysis<\/a><\/span>, 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. <\/span><\/p>\n

That’s why organizations and development teams must evolve from “being prepared” to “managing the risk” of security breaches.<\/span><\/p>\n

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

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. <\/span><\/p>\n

Here’s a look at the challenges to each approach.<\/span><\/p>\n

The Vulnerability Patching Approach<\/h2>\n

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 \u2014 <\/span>before<\/span><\/span> cyberattackers can take advantage of the vulnerabilities themselves. <\/span><\/p>\n

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. <\/span><\/p>\n

The Guardrails Approach<\/h2>\n

The guardrails approach is more nuanced than the vulnerability patching approach, but it comes with its own set of challenges.<\/span><\/p>\n

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:<\/span><\/p>\n

\n