The same vulnerability can be urgent in one app and harmless in another because risk depends on context, not just on the flaw. Five things change the answer: which part of the library you use, where it runs, who can reach it, what it can touch, and what protections surround it. The published score cannot know any of these.
TL;DR
- A score describes a flaw in general. Your risk depends on your product.
- Five context factors decide the difference: usage, location, reach, access and protection.
- The same library in three products can deserve three different answers.
- Write the context into the decision so the answer can be checked and reused.
Definition: context. The facts about your own system that change how risky a flaw is: how you use the software, where it runs, who can reach it, what it can access, and what other safeguards sit around it. Security teams also call this the environment.
Why does one flaw get one score if the risk differs?
A vulnerability score is written once, for everyone. The group that maintains CVSS, FIRST, says the base score is meant to be published by the maintainer of the vulnerable product or a third party working for them, because the base metrics do not change over time and are common to all environments. The specification adds that consumers of the score should supplement it with temporal and environmental scores specific to their own use of the product.
The environmental part is where your context goes. The specification describes it as adjusting the severity to a specific computing environment, taking account of factors such as the presence of mitigations in that environment. In plain words: the number you read in a database was made without knowing your system. You are expected to adjust it.
Most teams skip that adjustment, because it takes thought. They read the base score and treat it as the answer. The result is that the same flaw gets the same urgency in every product, which means some products over-react and some under-react.
FIRST also says in its user guide that CVSS measures severity, not risk, and should not be used alone to assess risk. The five factors below fill in the rest.
What are the five context factors?
1. Usage: which part of the library do you use? A software library is a toolbox. A flaw usually sits in one tool. If one product calls that tool and another never does, they face different risks from the same toolbox. This is the question reachability analysis answers.
2. Location: where does it run? The same code behaves differently on a public web server, inside a company network, in a build pipeline, on a developer laptop, or in a browser. A flaw that lets a crafted file crash a server is serious when strangers can send files to that server. The same flaw on a laptop that opens just the user's own files is a small nuisance.
3. Reach: who can get to it? CVSS has a measure called attack vector. A flaw that can be used over a network has more potential attackers than one that needs physical access. The US directive BOD 26-04 treats public exposure as one of its four variables for setting urgency, and defines a publicly exposed asset as one accessible to unauthenticated or untrusted entities via public networks. If a product is not exposed, the same flaw can wait longer.
4. Access: what can it touch? If an attacker gets in, what do they find? A service holding customer records, payment keys or admin rights raises the stakes. A throwaway test box with fake data lowers them. The directive's idea of technical impact captures part of this: total control over the software, or partial control such as the ability to knock it offline.
5. Protection: what else stands in the way? Other safeguards can block the path. These include a filter that rejects odd input, a network rule that limits who can connect, a feature switched off, or an account system that requires login. Protection is not a reason to skip a fix forever, but it can change the order.
| Factor | The question | Raises urgency | Lowers urgency |
|---|---|---|---|
| Usage | Do we call the risky function? | Called on a normal path | Never called |
| Location | Where does it run? | Public server | Build tool or laptop |
| Reach | Who can connect? | Open to the internet | Internal network with limited access |
| Access | What does it hold? | Customer data, keys | Test data, nothing sensitive |
| Protection | What blocks the path? | Nothing | Feature off, strong filter, login needed |
What does one flaw in three products look like?
Here is a worked example. The library, the flaw and every number are invented to illustrate the idea.
Suppose an image library called PicTrim has a flaw. A specially made image file can make the library crash or run attacker code when it resizes the image. The flaw is rated 8.8 on a 10 point scale. Three products use PicTrim at the affected version.
| Product X | Product Y | Product Z | |
|---|---|---|---|
| What it is | Photo sharing site | Internal report builder | Developer command line tool |
| Calls the resize function | Yes, on every upload | Yes, for logos | No |
| Who supplies the image | Any visitor | Staff and contractors | Not applicable |
| Reachable from the internet | Yes | No | No |
| What it holds | User photos and accounts | Company reports | Nothing sensitive |
| Decision | Fix now | Fix in next cycle | Record, no action |
Product X takes images from strangers and resizes them on a public server. The flaw is called on every upload and the server holds user accounts. This is the worst case. The team should fix it now and check logs for odd uploads.
Product Y builds reports for staff. It calls the resize function to scale company logos, but the logos come from a folder the marketing team controls. Nobody outside can send an image. The risk is real but narrow. The team fixes it in the next normal update and notes that anyone who can write to the logo folder is the realistic attacker.
Product Z is a command line tool that never calls the resize function. The library is in the package list but the code path is dead. The team records "not called" with the evidence and sets a trigger to recheck if the tool ever starts resizing images.
Same library. Same flaw. Same score. Three answers, each easy to explain and to defend.
How do you capture the context for your own product?
Use these steps. They take about fifteen minutes for a small service.
- Name the product and the environment. Write "Product X, production, public web server."
- State how the library is used. List the functions your code calls. A search or a reachability result can supply this.
- State who can reach it. Trace the input. Does it come from users, from staff, or from your own systems?
- State what it can touch. List the data and rights available to that part of the system.
- List the protections. Name any filters, network rules, settings or logins that sit in the path, and state how you checked that they work.
- Pick a decision and write one sentence. For example, "Called on public uploads, runs on internet facing server, holds user data: fix now."
- Keep the context with the decision. Put it in the ticket or a status statement so a reviewer can check it.
If you share software with customers, this is also the content of a statement that a product is or is not affected. The OpenVEX format was created so a supplier can tell users about the applicability of a flaw to a product. It notes that scanners flag components that may already be patched, may not be present, or may not be able to run. A context statement turns that general idea into your specific answer.
Why does this matter for audits and customers?
Customers and auditors often ask why a flaw was not fixed. "The score was high but we did nothing" is hard to defend. "The score was high, the function is never called, here is the evidence and the date" is easy to defend. Context makes your decisions explainable, which is the difference between a decision and a shrug.
It also keeps you from the opposite mistake. A low score does not make a flaw safe in a product that holds sensitive data and faces the internet. The base score is a starting point, and your context moves it up or down.
What can Safeguard do to help?
Safeguard scans dependencies and builds an SBOM, the full list of pieces in a product, for each of your projects. Reachability analysis traces your own call paths into each vulnerable function, which answers the usage factor. Asset discovery helps you keep track of what you run and where, and policies and gates let you set rules for what blocks a release.
Autonomous remediation with fix pull requests is available. It is off by default and every category starts on Manual. A free scan is available at gold.safeguard.sh/scan.
For more on this topic, see exploitability preconditions beyond the version string and which signal should drive patching.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how the same dependency scan produces a shorter list once your own call paths are traced into each vulnerable function.
Quick check
Can I trust the score in a vulnerability database for my product?
Trust it as a measure of how bad the flaw is in general. Do not treat it as your risk. FIRST states that CVSS measures severity, not risk, and that consumers should add environmental information specific to their own use.
If a flaw is harmless in my product, do I still need to record it?
Yes. Write the context, the date and the owner. If your product changes, the record tells you which assumption to recheck. It also answers customer and auditor questions without a scramble.
Does being inside a company network make a flaw safe?
It lowers the number of people who can reach it, which can lower urgency. It does not make the flaw safe, because an attacker who gets inside the network may then reach it. Treat it as a reason for a later deadline, not for none.
Sources
- FIRST: CVSS v3.1 specification
- FIRST: CVSS v3.1 user guide
- CISA BOD 26-04: Prioritizing Security Updates Based on Risk
- OpenVEX specification repository
Last reviewed: 19 October 2026.
