Vulnerability scanners work by matching version banners and configuration details against databases of known CVEs. This approach is effective, but it can produce false positives — findings that look like vulnerabilities but aren't actually exploitable on your system. ShadowTrackr gives you several ways to deal with these.
The most common causes of false positives are:
Backported security patchesLinux distributions like Ubuntu, Debian and Red Hat backport security fixes to older software versions without changing the version number. For example, your server might report
OpenSSH_9.2p1 Debian-2+deb12u6 in its banner. A scanner sees the version number, matches it against the CVE database, and flags vulnerabilities that the distribution has already patched. The version string stays the same, but the vulnerability is gone.
Old TLS/SSL vulnerabilitiesTLS and SSL tests can flag older vulnerabilities that were serious when discovered but are fixed in virtually all modern deployments. These don't always show as fixed from the outside because the test methodology can't distinguish between a patched and an unpatched server, and there can be a large number of them across your certificates.
Environmental contextA finding might be technically accurate but irrelevant for your use case — for example, a test environment behind a VPN that intentionally uses a self-signed certificate.
To mark a specific CVE as a false positive on an asset, navigate to the asset's detail page and click on the CVE label. You'll see an option to mark it as a false positive for that particular asset.
Important: this option is only available on individual asset pages, not on report pages where a CVE may apply to multiple assets. Reports aggregate findings across assets, so you need to go to the specific asset to dismiss a finding.
Once marked, the CVE will still be recorded but will no longer appear in vulnerability reports. You can see an overview of all false positives in the
False Positives page, and delete them individually from there if needed.
ShadowTrackr automatically suppresses certain findings that are overwhelmingly likely to be false positives, so you don't have to dismiss them one by one.
Patched OpenSSH on Ubuntu, Debian and Red HatShadowTrackr detects when an OpenSSH banner indicates a distribution that backports security patches (Ubuntu, Debian, Red Hat) and automatically marks the associated CVEs as false positives. These distributions maintain their own security patch schedules and apply fixes without bumping the upstream version number, making version-based detection unreliable.
Old TLS/SSL CVEsThe following CVEs are automatically marked as false positive by default because they are almost always fixed in modern systems:
| CVE | Name | Description |
|---|
CVE: CVE-2011-3389 | Name: BEAST | Description: Browser Exploit Against SSL/TLS |
CVE: CVE-2013-0169 | Name: Lucky Thirteen | Description: CBC cipher timing attack |
CVE: CVE-2013-3587 | Name: BREACH | Description: HTTP compression side-channel attack |
CVE: CVE-2014-0224 | Name: CCS Injection | Description: ChangeCipherSpec injection attack |
CVE-2013-0169 (Lucky Thirteen) concerns CBC cipher vulnerabilities. While technically preventable by removing CBC ciphers, virtually all modern webservers have fixed this years ago. This CVE is marked as false positive and no longer appears in the vulnerability index, but it will still show on the certificate page with a notice that the webserver is possibly vulnerable.
You can override these automatic false positives in your
Settings if you need them visible.
ShadowTrackr offers two different ways to reduce noise, and it's important to understand the difference:
Ignoring an asset (see
Assets > Ignoring urls and hosts) removes the entire asset from your monitoring. ShadowTrackr will stop scanning it entirely. Use this when an asset is out of scope — for example a domain you no longer own, or a URL that belongs to a third party.
Marking a CVE as false positive keeps the asset monitored but suppresses a specific finding. The asset stays in your inventory and continues to be scanned; only the individual CVE is dismissed. Use this when the asset is in scope but a particular finding is inaccurate.
