This article provides an introduction to the finding entity in Nucleus including an overview of finding types and subtypes as well as how findings are grouped and represented in the Nucleus platform.
What is a finding?
The finding entity in Nucleus is a normalized schema used for representing the results identified by an automated security scanning tool or manual assessment conducted by a human (such as a penetration test or bug bounty program). Findings were designed to be flexible and versatile so that results from any source can be succinctly represented and recorded within Nucleus for triage, workflow, prioritisation, reporting and remediation purposes.
Examples of findings may include:
- The presence of one or more CVE’s on an asset
- A logic flaw within code
- A system or cloud infrastructure misconfiguration
- A check for compliance or non-compliance with one or more compliance frameworks (e.g. CIS Benchmark)
- A security flaw in a system identified during a manual assessment
Types and sub types
Findings have strict types: Vulnerability, Compliance, and Vuln-Compliance. Almost all findings will be of type vulnerability or compliance, and each has its own experience and set of workflows within the Nucleus platform.
Occasionally the findings identified by a source tool fit the criteria for being both vulnerabilities and compliance findings. When this occurs, Nucleus normalizes those findings to the Vuln-Compliance type, and the finding appears in both experiences and can be used in both workflows.
Examples of a finding that will be of type Vuln-Compliance are:
- A vulnerability that is also a check within the PCI Compliance framework
- The presence of a secret key in a code base, which also violates a policy in a compliance framework
Findings also have inferred sub types which are identified by the data that has been set on them. For example, if a vulnerability has the Path, Package and Version fields set, the vulnerability sub type can be inferred to be a package or dependency vulnerability. Similarly if a finding has the Port and Service fields, it can be inferred to be a network or infrastructure scan finding.
Definitions and instances
Security scanning tools check for the occurrence of specific security issues across different assets.
In Nucleus, each specific security issue is known as the unique finding and can be thought of as the definition of the finding without any asset specific context. A finding instance in Nucleus is therefore any occurrence of the unique finding on an asset.
Correspondingly, the fields on the Nucleus finding entity correspond to either the finding’s definition or the instance of the finding itself. For example, the finding’s name, description and recommendation will be consistent across all finding instances, and are therefore unique finding fields. Equivalently, the package name, version and path on the filesystem are different for each occurrence of the finding and are finding instance fields. See Finding Fields for a full list of fields.
Bobby Drop Tables configured his company’s cloud compute security scanning tool to scan for the presence of the widely known Log4j security vulnerability CVE-2021-44228 across all virtual machines within their AWS cloud environment. After the scan completes, the vulnerability was discovered three times across on two virtual machines:
Virtual Machine 1 - Two different vulnerable versions of the Log4j package installed in different locations
Virtual Machine 2 - One vulnerable version of the Log4j package installed in a single location
In this example, CVE-2021-44228 is the unique finding, and each of the three occurrences of the finding is a finding instance.
Definitions and instances are central to the Nucleus Platform experience. Throughout the user interface, findings are primarily grouped by and visualised through the lens of each unique finding. User can then navigate into each unique finding to view information about it, and further drill down into each finding instance.
How are unique findings determined?
Nucleus conducts extensive research into each security scanning tool when creating a connector to identify how the tool scans for findings and presents them to their end users. This presentation is then replicated as closely as possible to ensure a continuous experience between Nucleus and the source tool.
Below are three examples that illustrate different unique finding structures in Nucleus depending on the presentation in the source tool.
Endpoint Detection & Response Platforms
Endpoint detection and response platforms commonly scan for and identify individual CVEs present on the scanned system. In these situations, the user interface of the EDR platform will show assets, and on each asset a list of CVEs. Similarly they may show a list of CVEs, and then for each CVEs, the asset that were detected with it. 


This example therefore matches the example above, where each CVE is a unique vulnerability, and each occurrence on an asset is the finding instance.

Traditional Network Scanning Tools
Traditional network vulnerability scanning tools such as Tenable and Qualys perform checks that programatically test for the presence of a set of CVEs or misconfigurations, and then present them as a rolled up security finding. For example, Tenable refers to each check as a Plugin, and Qualys refers to each check as a QID. 


In these situations, the user interface in the source tools are situated around the check, and so each check is a unique finding.

Static Application Security Testing (SAST) Tools
SAST tools scan for the presence of common logic flaws within code. A scan will run checks for sources and sinks to identify if a particular vulnerability (e.g. SQL injection) is present in the source code, and then present a rolled-up view of all occurrences of that vulnerability in different locations in the code. 

In these situations, the specific check will correspond to the unique finding in Nucleus.