What Does a Vulnerability Actually Need to Tell You?
Exposing a vulnerability is only the beginning of a security decision. You know something is wrong, but that doesn’t necessarily mean you have all the information about what it means, who should care, and what to do about it.
A security team still needs to answer a series of questions: What is actually affected? How serious is it? How exposed is it? How important is the affected Asset? Who owns it? What does an effective solution look like?
The better a security team can answer those questions, the better it can distinguish the vulnerabilities that require immediate attention from those that can be monitored or deferred. DefectDojo gives you the power to inject context into every Finding so you can easily tell the difference. Here, we’ll show you how, and where you can take it from there.
What Do You Need to Know?
Imagine that a scanner reports a “Critical” vulnerability affecting a software component. At first glance, immediately fixing it seems like the most obvious answer. But before that decision can be made, a security team may need to know more.
Understand the Finding
- What is affected? Is the Finding associated with an internet-facing production application, an internal service, a development environment, or something else?
- How serious is it? Severity provides an important starting point, but that alone may not capture the risk the vulnerability poses.
- Can it actually be exploited? Is there evidence that the vulnerability is being exploited in the wild? Is exploitation technically possible in the affected environment? Is the vulnerable component actually reachable?
Understand the Impact
- How important is the Asset? A vulnerability affecting a business-critical application may warrant a different response than the same vulnerability affecting a low-value development system.
Turn Risk Into Action
- Who owns it? Even the highest-priority Finding doesn’t become actionable until the person responsible for fixing it knows it exists.
- How should it be fixed? Is there a standard organizational procedure for resolving this specific kind of Finding?
- What should happen next? Should the Finding be remediated, assigned a specific SLA, escalated, accepted as risk, or handled automatically according to an established policy?
What’s Missing?
Addressing these questions establishes the scope, risk, prioritization, accountability, and the ensuing remediation workflow associated with each Finding. The challenge is that vulnerability data rarely includes all of the information needed to determine the appropriate response.
Maybe your security team has one tool providing CVSS scores, another providing exploit intelligence, another identifying cloud exposure, and another maintaining information about the affected application. Asset ownership and business criticality may live somewhere else entirely.
Instead of a single source of truth, a collection of disconnected sources provides only part of the answer to the question that arises when any new vulnerability is found: “What do we do about this?”
DefectDojo’s Solution: Context, Context, Context
DefectDojo brings these different dimensions of vulnerability context together so security teams can move from isolated Findings to a more complete picture of risk.
What Is Affected?
Assets tell you where a vulnerability exists, and the Rebuilt Asset Model offers a richer way to describe the Assets behind the Findings, including information such as version, identity, relationships, deployment context, exposure, and organizational metadata. This turns the Asset from a container for Findings into a source of information that helps explain their significance.
Organizations can also use Typed Custom Fields to capture information specific to their instance. So whether that’s internal classifications, ownership metadata, or other organization-specific attributes, you can capture the information that matters in the language your organization already speaks.
How Serious Is It?
Severity remains an important signal, but a “Critical” Finding on a low-impact development Asset may warrant a different response from a “High” Finding affecting a revenue-generating, internet-facing system.
Prioritization capabilities let teams put that severity in context by incorporating factors such as the importance, exposure, sensitivity, and revenue of the affected Asset:
- Business Criticality: A rating from “None” to “Very High.”
- Exposure: “External Audience,” “Internet Accessible.”
- Data Sensitivity: The number of user records the Asset can access.
- Revenue: The Asset’s estimated annual revenue, relative to the rest of its Organization.
Considering severity alongside these factors gives teams a more informed basis for deciding how urgently a Finding needs attention.
Can It Actually Be Exploited?
Just because a vulnerability can be exploited doesn’t mean it’s actually exposed. And conversely, not every exploitable vulnerability presents the same practical risk.
DefectDojo can enrich vulnerability data with Threat Intelligence and real-world exploit evidence (e.g., EPSS scores, KEVs, public exploits) to arrive at an assessment of Risk, while Reachability and Asset Exposure help teams understand whether the vulnerable code is reachable and whether the affected Asset is externally exposed.
Effectively, just because a threat exists doesn’t mean it will be targeted, or that it’s even possible to access. With these metrics in hand, you can tell the difference between a vulnerability that is theoretically exploitable and one that presents a credible risk in practice.
Who Owns It?
Knowing which vulnerabilities matter most is only useful if the right people can act on them.
DefectDojo supports assigning Findings to the teams or individuals responsible for addressing them, giving security teams a way to connect prioritization with accountability. Downstream Connectors can carry Findings into the systems teams already use for remediation, helping turn prioritization into a handoff rather than leaving security teams to communicate each issue manually.
How Should It Be Fixed?
Once the right person to address a vulnerability has been identified, teams also need guidance on how to resolve it. DefectDojo Findings can include remediation or mitigation information, giving teams a starting point for determining how to address an issue. Mitigation Policies take this a step further by letting organizations attach remediation guidance directly to Findings individually, in bulk, and even automatically. So the assignee responsible receives the solution at the same time as they become responsible for the problem.
What Should Happen Next?
Finally, context becomes most valuable when it can influence what happens next.
Not every Finding requires immediate remediation, but it can’t stay on the back burner forever. Service Level Agreement (SLA) configurations let organizations set remediation deadlines by Severity or Risk and apply them to each Asset, so teams can easily track what needs attention and when.
Conversely, some Findings may not be practical or necessary to fix right away, and Risk Acceptances give organizations a way to handle such cases. Developers can request an exception from the security team and set an expiration date, ensuring the Finding won’t quietly be forgotten. Each step of this process is recorded, maintaining a clear trail of the decision-making informing why the risk still remains.
These decisions don't always need to be made manually, either. Triage Engine lets you encode repeatable decisions like assigning SLAs or accepting risk into visual workflows, and expands further by allowing organizations to automatically route Findings, change their attributes, trigger notifications, create tickets, or apply other actions based on Finding and Asset context.
Rather than requiring analysts to manually interpret the same combination of conditions over and over, organizations can preprogram routine decisions into repeatable workflows that scale, leaving analysts the time to investigate the Findings that actually require judgment.
Putting It All Together
Now consider that “Critical” vulnerability again. On its own, that severity rating offers only a starting point, but the Asset data shows that it belongs to a production payment application that is exposed to the internet. Reachability information can help establish whether the vulnerable code can actually be reached. Threat intelligence can indicate whether exploitation is likely or already occurring in the wild, while mitigation policies give the assignee an approved path toward a solution. With additional information about the Asset’s business importance and the team responsible for it, security teams can make a more informed decision about urgency, assign responsibility, and configure the Triage Engine to trigger the appropriate workflow for this Finding and any others like it going forward.
The vulnerability hasn't changed, but the team is now standing on much firmer ground when deciding what to do about it.
Vulnerability Management Is Inherently Contextual
Effective vulnerability management means understanding what the Finding affects, how significant the risk is, who should address it, and what response makes sense.
DefectDojo helps security teams bring these considerations together, from assessing the significance of a Finding to assigning remediation guidance, managing deadlines and exceptions, and automating repeatable decisions. So instead of simply collecting more vulnerability data, you can turn that data into informed, actionable decisions.
Explore the DefectDojo documentation or request a demo to see how these capabilities fit into your vulnerability-management workflows.