Threat and Vulnerability

A threat is a potential harmful action or event. A vulnerability is a weakness that can enable harm. An attack is an attempt to exploit a path; these terms describe different parts of a security scenario.

Name the weak link

In a fictional service, the threat scenario is an unauthorized refund. A tool that trusts a supplied order identifier without checking ownership has a vulnerability. The tool interface is part of the attack surface.

This distinction helps assign work: the team can repair the missing ownership check and test requests for another customer's order.

Do not infer an attack from every error

A wrong answer may result from poor retrieval or outdated data without malicious activity. Investigate evidence of the cause while containing the impact. Fixing one vulnerability also does not remove every route to the same harmful outcome.

The distinction decides what gets fixed first

A list of known vulnerabilities is always longer than the capacity to fix them, so the practical use of this distinction is ordering. A vulnerability alone is a weakness; what makes it urgent is the threat that can reach it and what it would reach.

Four questions separate the list, and they are mostly about the environment rather than the flaw.

• Is it being exploited? Evidence of active exploitation changes the schedule more than any severity score, because it converts a possibility into an observed threat.
• Can an attacker reach it here? The same flaw in a component exposed to the internet and in one reachable only from an internal network with authentication are different risks. Reachability in your deployment, not in the advisory, is what matters.
• What does it get them? Compare the value of the assets involved, the authority and connections of the affected component, and the business impact of losing it. Access to a system holding regulated data, or to a component that can reach one, often ranks higher. A single stateless worker may rank lower, unless it holds broad credentials or is a critical dependency.
• Is something already in the way? A network rule, an authentication requirement, or a disabled feature can mean the path does not exist for you — which is a reason to schedule rather than scramble, and a reason to record why, since the mitigation may be removed later by someone who does not know it was load-bearing.

Two things follow for how patching is organized. Decide the response tiers in advance — what is applied within days, what waits for the next cycle — because deciding per vulnerability under pressure produces both unnecessary emergencies and real ones handled too slowly. And keep the reasoning: a vulnerability deferred because it is unreachable needs that judgment written down, so the next reviewer can check whether it still holds.

Public frameworks can structure vulnerability-response decisions. CISA’s Stakeholder-Specific Vulnerability Categorization (SSVC) is one example: its published introduction describes prioritization using exploitation and organizational impact. The questions above are an explanatory set, not a reproduction of its decision tree. Use a chosen framework consistently and record the deployment evidence behind each decision.

References

• OWASP: Threat Modeling
• CISA, CISA Releases SSVC Methodology to Prioritize Vulnerabilities (2022)