10 New DefectDojo Features Changing How Teams Manage Vulnerability Risk
Vulnerability management starts with collecting security data, but knowing what to do with that data takes much more context. Organizations need to accurately represent their environments, understand the Assets and vulnerabilities within them, determine which risks matter most, and turn those decisions into action.
Recent DefectDojo Pro releases have added capabilities across each of these stages, giving security teams more control over how they model their environments, interpret security data, prioritize risk, and automate what happens next. Below are 10 of those features and the points of friction they address.
Shape Your Workflow: Make DefectDojo Your Own
Recent releases let DefectDojo adapt to the way your organization is structured, rather than asking you to reshape your environment to fit the platform.
By default, deduplication compares a Finding only against other Findings in the same Asset. When the same thing is deployed in several places and modeled as separate Assets, each Asset reports a shared vulnerability as its own Finding. Dedupe Pools let you define a group of Assets whose Findings deduplicate against each other, so shared flaws can be viewed and addressed together instead of in isolation.
Every organization also uses terms that won't fit neatly into a security platform's predefined fields. With Typed Custom Fields, administrators can define their own fields across seven data types and six entity types, adapting DefectDojo's data model to their own processes, terminology, and reporting needs.
Custom Field values are also captured in the audit log, providing a record of how that information changes over time. Better yet, Triage Engine rules can read and write Custom Fields, turning them from simple data points into inputs for automated workflows.
Adding Context: Understand What You're Securing
Once DefectDojo reflects the way an organization is structured, the next step is making that environment itself more informative.
The Rebuilt Asset Model gives teams a more complete picture of what they're securing by allowing Assets to capture versions, identities, relationships, BOM snapshots, and deployment context. An Asset can now represent the thing a team is actually securing, rather than serving primarily as a container for its Findings.
For example, if 10 microservices use the same base container image, a vulnerability in that base image can otherwise appear as 10 distinct, unrelated problems. Typed relationships between those Assets expose the connection, helping teams understand the vulnerability's blast radius and identify where a single remediation could address multiple Findings.
The Asset Model establishes what an Asset is and how it relates to the rest of the environment. Cloud Security Posture Management (CSPM), part of Sensei, extends that context into the infrastructure itself to reveal how cloud resources are configured and where those configurations introduce additional risk.
When AppSec and cloud security live on different dashboards, security teams have to jump between tools, manually correlate data, and try to figure out which cloud misconfiguration actually threatens a particular application. CSPM connects your AWS accounts, Azure subscriptions, and GCP projects, finds misconfigurations such as publicly exposed S3 buckets and internet-facing security group rules, and brings them into DefectDojo as Findings linked to an Asset, alongside your code vulnerabilities, SAST and DAST results, and container scans. There, you can see a critical vulnerability next to the misconfigurations in the cloud environment around it and prioritize based on the context in which the issue actually occurs.
Asset Exposure (currently in Beta) adds another dimension by recording whether an Asset is reachable from outside the organization. Instead of treating a flaw on an internet-facing service as equivalent to the same flaw on an isolated internal system, DefectDojo factors external reachability into each Finding's priority. Native Asset Exposure reporting from Wiz, Shodan, Censys, and CrowdStrike Spotlight means that reachability data can come straight from the external intelligence and scanner sources teams already use.
From Findings to Insight: Learn What's Really Putting You at Risk
With added context for each vulnerability, security teams can move from understanding what they are securing to assessing what the data says about their actual risk and connecting the patterns that reveal which problems pose the largest threat.
For example, an organization might have thousands of Findings, but if some of them share an underlying cause, each one still looks like a separate issue rather than part of a web of related vulnerabilities. Cross-Domain Finding Correlation makes those relationships explicit by grouping Findings from multiple scanners around a shared root cause, such as the same CVE, the same software component and version, the same infrastructure resource, or the same weakness at the same URL. By connecting related Findings, correlation shows the broader impact of a vulnerability and identifies the one fix that clears many Findings at once.
A vulnerability's severity alone doesn't tell you how urgently it needs attention. Threat Intelligence Enrichment adds external threat intelligence to Findings, including EPSS scores and CISA Known Exploited Vulnerabilities (KEV) status, so security teams can spotlight vulnerabilities based on how likely they are to be exploited and whether they already are. Rather than treating every high-severity Finding as equally urgent, teams have the information they need to decide what deserves attention first.
Threat intelligence tells you how dangerous a known vulnerability is. PSIRT 2.0 (currently in Beta) answers a different question for product security teams: are we affected by a newly disclosed advisory? Its native advisory management ingests advisories from the feeds you choose and matches them against the software inventory of the products you maintain.
PSIRT teams often face thousands of public CVEs and heavy threat intelligence feeds. Feed Rules score, tag, and mute advisories before anything touches your inventory, filtering out irrelevant noise. Advisory-to-Case Conversion lets a team turn an incoming advisory into an actionable, tracked case, while a dedicated PSIRT permission gives analysts access to PSIRT without granting them global Maintainer rights. Together, these capabilities let teams manage security advisories natively within DefectDojo and connect them to the products they maintain.
Acting on Insights: Decide What Happens Next
Once security teams understand which problems matter most, they need a consistent way to decide what happens next.
When every vulnerability requires a person to review its context, determine its priority, identify its owner, and manually start the next step, triage becomes a bottleneck that consumes time better spent on issues requiring human judgment. Triage Engine addresses this by turning an organization's existing triage decisions into repeatable, rules-based workflows that automatically evaluate Findings and Assets and take a predetermined action.
In a graph-based visual editor, teams build Rules that run when scans are imported, when Findings change, or on a schedule, with branching logic that sends items down different paths based on customizable criteria.
For example, a Rule could identify critical Findings, assign them to the appropriate owners, send a Slack message alerting that team, and create a corresponding Jira ticket, while other Findings pass down different branches with separate actions based on severity, Finding attributes, or Asset context. Triage Engine also records a trace of every run, giving teams visibility into what changed and helping them spot errors when an automated action does not produce the expected result.
Even with automation, not every vulnerability can be fixed immediately. A Finding may have compensating controls in place, or the affected system may be approaching retirement, but teams still need a formal way to document and govern the decision to defer remediation. Risk Acceptances 2.0 (currently in Beta) gives teams a structured way to request, review, approve, and track accepted risk.
Requests land in a pending-review queue and move through a reviewable lifecycle, and a Finding stays active and counted until its acceptance is approved and put in force. Every state change is recorded along with who made it and why, and a durable per-Finding ledger keeps that history even after a Finding leaves the acceptance, so teams have a paper trail for audits. When an acceptance expires, its Findings can return to active status and restart their SLA, depending on how the acceptance is configured, so accepted risk doesn't quietly drop out of the remediation process.
Putting It All Together
Taken together, these updates show DefectDojo becoming more adaptable to how organizations model their environments and add context to them before deciding which risks matter most. From there, automation and governed risk acceptance help teams turn those decisions into repeatable action. The result is a vulnerability management platform that goes beyond collecting security data and connects it to the context, decisions, and workflows that make it useful.
Every feature above is available in DefectDojo Pro, and the Pro changelog covers each one release by release.