Select any application name to open its details panel on the right side of the screen. The panel explains why the application scored the way it did and everything needed to fix it, across six tabs: Exposure score, Fixes, Findings, Ownership, Dispatches, and Devices.
The top of the panel always shows a quick summary: open Critical and High findings, how many fixes would clear them, and how many devices are involved. If the application has someone to send work to, a Compile remediation work button appears at the bottom of every tab.
Exposure score tab
This tab shows the score and, in one sentence, the main reason for it — for example, how many Critical findings there are and whether any are being actively exploited.
The Exposure score tab breaks the score down by severity so you can see exactly where the points come from.
The table breaks the score down by severity (Critical, High, Medium, Low), showing how many findings are open at each level, the worst exploitation grade at that level, and how many points that level contributes.
How the Exposure score works
The score runs from 0 to 100. It is designed to reflect real-world danger, not just a count of findings:
- Severity matters most. Critical findings weigh the most, then High, Medium, and Low.
- Being exploited matters a lot. If the worst finding at a severity level is being actively exploited, that level's points are multiplied by 1.7. A working proof-of-concept attack multiplies them by 1.3. Anything on the CISA KEV list always counts as actively exploited.
- Volume has diminishing returns. The first ten findings at a level count fully; after that, each additional finding adds less. One hundred low-risk findings do not outweigh one finding that attackers are using today.
- Each severity level has a ceiling, so no single level can swamp the rest, and a lower severity can never outscore a higher one.
- Business rules can add up to 20 points if your administrators have set them up (for example, extra points when endpoint protection is missing). Rules can only raise a score. See Configuring Scoring and Routing.
The score goes down only when a finding is genuinely resolved: fixed and confirmed by a later scan, the device retired, or the finding withdrawn as a false positive. Findings on a device that has stopped reporting stay in the score — losing track of a machine is not treated as fixing it. Deferring or suppressing a finding in the scanner does not remove it either.
Some things are deliberately not part of the score: the business criticality label, how old a finding is, and EPSS (which is used only to break ties).
Fixes tab
The Fixes tab turns a long list of findings into a short list of actions. Each row is one patch or change, with how many findings it clears, how many devices it has to reach, and its worst severity and exploitation grade. The fixes that clear the most urgent work are listed first.
The Fixes tab: ten fixes clear 98 of this application's 160 open findings.
Expand a fix to see the exact findings it clears and the servers it needs to be applied to. Select Compile this fix to send just that fix to its owners. Findings with no published vendor fix are still listed and ranked, but nothing can be sent for them yet.
Findings tab
The Findings tab lists every individual vulnerability on the application. Switch between Open and Closed findings using the buttons at the top.
The Findings tab lists each vulnerability with its severity, exploitation grade, and whether a vendor fix exists.
Expand any finding to see three views of its status side by side: what the scanner reported, the industry-standard status, and DataBee's own conclusion. DataBee's conclusion is the one that counts. A closed finding is labeled with the reason, for example:
- Fixed — rescan verified — a later scan confirmed the fix. This is the strongest evidence.
- Fixed — reported, not rescan-verified — the scanner says it is fixed, but no follow-up scan has confirmed it yet.
- Cleared — not observed, Stale — asset stopped reporting, Closed — asset decommissioned, Closed — record purged, Retracted — false positive.
Only the two Fixed labels count as real remediation. A finding marked reopened was fixed before and has come back.
Ownership tab
The Ownership tab shows who is responsible: the application's Business owner, and the Remediation owners — the IT teams (ServiceNow assignment groups) that own each device, with a Compile button for each team.
The Ownership tab lists the business owner and each remediation team, with how many devices each one owns.
If some devices have no owner on file, the tab says so. Work for those devices cannot be sent until an owner is assigned in your CMDB.
Dispatches tab
The Dispatches tab shows every package of work already sent for this application and whether it is actually working. See Tracking what you sent.
Devices tab
The Devices tab lists the servers and other devices behind the application: operating system, when each was last patched and last seen, whether it is internet-facing, whether it has endpoint protection, its owner, and how many findings are open on it.
The Devices tab shows the health of each device. Turn on "Needs attention only" to see just the problem devices.
Sort by Most findings, Least fresh, or Hostname, or turn on Needs attention only to hide healthy devices. A device is behind on patching when it has gone 90 days or more without a patch. Never scanned devices are listed in your application list but have no scanner results, so their exposure is unknown, not zero. Because a fix only counts once a later scan confirms it, how often you scan sets how quickly progress shows up here; we recommend scanning application servers at least weekly. At the bottom, Reporting scanners lists which scanners cover this application; if only one does, Frontier AI Defense notes that its findings cannot be cross-checked.