Software

Business Context, Not Severity Scores Alone, Should Drive Security Priorities

Security teams face an overwhelming flood of vulnerability alerts that scanners cannot properly contextualize. Experts argue that understanding business impact—not just technical severity—is essential to deciding what to fix first.

6 min read

Jon Rose, who leads IOmergent, an advisory firm specializing in information security and risk management, contends that vulnerability severity ratings cannot serve as the sole basis for remediation decisions. Instead, he argues that teams must evaluate threats through the lens of business operations to determine which flaws warrant immediate attention.

The problem became apparent when a security researcher conducting a standard assessment of a 300-person B2B organization with international operations uncovered an internet-accessible database featuring inadequate authentication controls. The vulnerability carried critical severity and seemed like an obvious priority. Deeper investigation revealed the database was actually a throwaway system used to evaluate job applicants, not a repository of client information.

This scenario illustrates a fundamental challenge: automated scanning tools and security professionals lack the ability to independently assess the actual damage that would result from a breach. Many organizations now engage external partners to manage cloud vulnerability assessment and prevent security staff from becoming paralyzed by alert volume. The sheer quantity of findings from scanners creates substantial friction, demanding that engineers invest significant effort in understanding notifications, identifying false alarms, and coordinating fixes—time that could otherwise go toward developing products, serving customers, or expanding infrastructure.

The workload crisis extends beyond security. Product development teams navigate endless feature backlogs while engineering organizations carry accumulated technical debt they cannot fully address. Organizational restructuring has expanded individual responsibilities while shrinking team sizes, all while personnel must continuously oversee, troubleshoot, and guide AI systems. Some accounts describe work weeks exceeding 90 hours.

Security operations face a distinct problem: data overload. Systems ingest identity logs, firewall records, endpoint notifications, external threat feeds, and intelligence reports, generating vastly more material for analysis than existed just a few years ago. Each alert appears pressing, high-risk, and deserving of prompt action. With constrained resources, determining where to focus becomes the central question.

Rose has observed directly how widespread tooling and AI capabilities are generating more findings than teams can manage. "Within the span of security work, there's an unending list of things you could tackle, and you're pulled in so many different directions," Rose tells The New Stack. "But you have to be ruthless about prioritizing and investing your time."

The real bottleneck is not the ability to remediate issues but rather the allocation of limited resources. Determining where engineering and security personnel will generate the most value represents the most consequential decision security leaders make regularly. A numerical severity rating, applied in isolation without threat modeling and situational understanding, cannot answer the fundamental business question: which vulnerability demands fixing first? Transforming raw technical findings into business-informed priorities requires judgment that goes beyond scoring systems.

CVSS limitations: a starting point, not a decision

The Common Vulnerability Scoring System (CVSS) offers security teams a helpful reference point. Its foundational metrics evaluate a flaw's severity by examining attack vector, attack complexity, required access level, and potential effects on confidentiality, integrity, and availability. However, a severity score remains consistent regardless of deployment environment, preventing it from indicating whether a vulnerable component is publicly reachable, defended by additional safeguards, or integral to business operations.

Treating a base severity score as an automatic trigger for remediation work creates problems rather than solving them. CVSS does allow for Threat and Environmental metrics that incorporate changing exploitation circumstances and organization-specific factors. Nevertheless, risk-focused vulnerability management requires dependable visibility into the technical environment and consistent application of that contextual information.

"The piece that's missing from any of these tools is the grounding in the business, the understanding of what actually matters," Rose states.

Escalate the internet-facing medium

An effective prioritization approach downplays raw scores in favor of examining accessibility: can an attacker realistically interact with the vulnerable system?

"Is the affected service exposed to the public internet or not? Or is it isolated behind network controls and accessible only to a limited set of internal users?" Rose asks. "Often, issues will get flagged, but it's not in a position where it could be triggered."

The second consideration is impact. A flaw in a temporary test system may represent a legitimate security issue, but it carries less weight than a weakness in systems handling customer payments, storing confidential data, or generating primary revenue. A concerning severity rating does not necessarily translate to significant business consequences.

Teams should evaluate whether the vulnerability is drawing active attacker attention and what subsequent compromise could enable. A flaw appearing in CISA's Known Exploited Vulnerabilities catalog warrants priority examination because real-world exploitation is documented.

The Exploit Prediction Scoring System supplies a forward-looking perspective: a probability estimate for whether a particular vulnerability will face exploitation attempts within the next 30 days. While neither tool replaces business judgment, both help separate theoretical concerns from those requiring immediate action. However, as AI-powered exploitation becomes more prevalent, the interval between vulnerability disclosure and active exploitation is narrowing because creating and deploying exploits costs less.

Attack chains frequently involve multiple systems. A relatively minor vulnerability can become urgent if it provides access to elevated privileges, production environments, or customer records. Conversely, a high-severity finding can be deferred—temporarily—if it remains inaccessible, poses limited consequences, and sits behind effective protective measures.

"The speed and the depth of research and investigation into those security issues are going faster," Rose observes. "So it can change really quickly." The worst scenario involves acknowledged but unaddressed risk languishing in backlogs. Even excellent detection systems deteriorate when no one monitors trends. Teams should document exceptions, establish review schedules, and assign responsibility. Accepted risk remains risk; the distinction lies in making it deliberate, time-limited, and subject to periodic reassessment.

An operator capability, not a weekend project

Security operations increasingly depend on AI to rank and process threats, and they are discovering vulnerabilities at unprecedented rates. Yet the sheer quantity of findings overwhelms even the most capable human teams.

AI also simplifies identification of less apparent exploitation pathways and can introduce new ones. Research examining over 20,000 fixes produced by AI showed that large language models introduce nearly nine times as many new vulnerabilities as human developers, displaying patterns distinct from human-written code. The solution involves applying AI at the outcome level. For each alert, the objective is enabling SOC analysts to quickly obtain answers to standard questions: whether it is new or previously known, what systems are exposed, what data faces risk, whether it affects production or development, and how the situation has evolved.

"That's how teams get thousands of alerts down to 10 to 20 prioritized tickets," Rose tells The New Stack. "Effective programs start by aligning with executive teams to understand the business — where the company is going — so allocation and adjustments track the actual risk, not just the score."

As workloads expand, applying business-informed judgment consistently through someone accountable for outcomes deserves greater investment.

Source: The New Stack

Source: The New Stack · Reporting supplemented by The Silicon Ledger staff.