Understanding Results: The Vulnerability Analysis Tab

In the top-right part of the page, you can see the vulnerability analysis verdict. This is the overall verdict of your scan and can be one of the following:

• PASS: No known vulnerabilities were found during the scan.
• VULNS: Known vulnerabilities were found during the scan.
• N/A: No components or licenses could be identified.
• VERIFY: Possible vulnerabilities were found during the scan. The version of one or more components could not be detected, and the component has historical vulnerabilities. To verify these vulnerabilities, manually enter the version number for the component. Versionless components with no vulnerabilities can be set to be verified from Account settings > Bill of Materials > Versionless components. This setting changes the results of versionless components from PASS to VERIFY.

A summary at the top shows the number of components identified, the number of known vulnerabilities in those components, public exploitable vulnerabilities and the number of software licenses.

In the Identified Containers section, Black Duck Binary Analysis can show results that are sorted according to the layers of the image when you scan a Docker image. Although the results of the scan will be the same, this view allows you to distinguish between vulnerabilities in your code and in the code that belongs to the operating system included in the Docker image. The Identified Containers section is only visible if the scanned app includes a Docker image.

From the drop-down lists next to the Identified Containers section, you can toggle the container view as well as filter and sort results.

The Component section shows both the files and the known vulnerabilities contained by each identified component. These result from two separate analytical processes, one that identifies a list of components and another that compares the list of components to a database of known vulnerabilities.

The following labels may be displayed:

• EXPLOIT AVAILABLE An exploit is available for the component.
• NO MITIGATIONS No mitigations are available for the component.

Labels of known vulnerabilities may be displayed next to the vulnerability in some cases. The labels provide additional information about the vulnerability.

The following labels may be displayed:

• EXPLOIT & FIX AVAILABLE Both an exploit and a fix are available.
• FIX AVAILABLE A fix is available for the vulnerability.
• EXPLOIT AVAILABLE An exploit is available for the vulnerability.
• WONTFIX For Linux distributions. Vulnerability has been demoted for a Linux distribution. It either does not apply for its environment or has been fixed with a patch.
• DEMOTE For Linux distributions. Vulnerablity has been demoted to a warning. The parameters the vulnerability applies to are not in use.

You can refine the results in the Component section with the following methods:

• Search for components with the free text search bar.
• Group them by name or version.
• Filter by selecting from pre-existing filters, by component types, result matching methods, tags (if they exist) or licenses.
• Sort by name or vulnerability.
• Search for vulnerabilitiues with vulnerability ID with the free text search bar

The following figure shows the group, filter and sort menus.

The figure below displays an example of different filters.

Component information displays details of the component, including name, version, license and so forth.

SBOM fields provide additional information about the component origin, description, component CPE and package URL. You can edit this information with the Edit button. The information is displayed in the SPDX or CycloneDX exports of the results. The fields are populated from the uploaded SBOM file.

SBOM information can only be entered for components with identified versions.

The figure below displays the Component information and SBOM fields.

Upgrade guidance provides you with information on which component version to upgrade. If Black Duck Binary Analysis detects that there is a component version with less vulnerabilities, it will suggest that version.

• Upgrade guidance - minor: suggested higher minor version with less vulnerabilities.
• Upgrade guidance - major: suggested higher major version with less vulnerabilities.

This section explains the methods used to detect components.

Three of these methods can be applied to any type of component:

• hashsum: For Java and native components. Uses the checksum of a JAR file to find known components from Maven Central. Uses the checksum of a file to look up components originating from Linux distributions.
• signature: Matches file fingerprints to a database of known components. It works for native components (code compiled to a binary), .NET bytecode, Java bytecode, and Go binaries.
• distro-package-manager: Leverages information from a Linux distribution package manager database to extract component information. Also works with distribution package files such as .deb and .rpm. It works for components of any language.

One of these methods is only used for native components that are or contain macOS or iOS executables:

• cocoapod-package: Extracts information from native Objective-C and Swift binaries and matches them against known CocoaPods projects downloaded via the CocoaPods package manager. CocoaPods components are matched from MacOS and iOS applications.

The next three matching methods are only used for Java bytecode:

• pom: Uses the Maven group and artifact names from the JAR file's .pom file to match components.
• manifest: Uses the Maven artifact names from the JAR file's manifest file to match components.
• jar-filename: Uses the Maven artifact name retrieved from the JAR filename to match components.

Then there are methods used for language-specific or platform-specific components:

• python-package-manager: Uses metadata found inside Python Egg and Wheel packages to match components.
• ruby-package-manager: Uses found gemspec files to match components.
• pe32-fileinfo: Uses found Windows PE32 metadata embedded in binaries to match components. See Microsoft PE VersionInfo and FileInfo specifications

Then there are methods used for importing components declared in special files:

• config-file: Uses component definitions found in .bdba.yaml analysis configuration files in the scan.
• sbom: Uses component definitions found in SBOM documents present in the scan.

Some components which have been previously displayed as individual components are now displayed as submodules and are listed under Module files. This applies currently to the .NET component but can be expanded in future releases.

Black Duck Binary Analysis attempts to identify specific component versions (as described in the section above). When this is possible, Black Duck Binary Analysis finds the known vulnerabilities that apply to the specific version of the component and lists them as Exact match.

In some cases, a precise version number is unavailable, making it more difficult to match the scanned component with vulnerabilities. When this occurs, Black Duck Binary Analysis relies on the file's timestamp (the record that tells when compilation happened). Vulnerabilities discovered after the file's timestamp are presumed unfixed, because they were not known when compilation occurred. They are listed as Exact match (timestamp).

Historical vulnerabilities are those that have been reported against some version of a software component but do not apply to your version of that component, because it has been fixed.

The Ignored Components section lists the components the user has chosen to ignore for the current scan. The files and vulnerabilities of ignored components are displayed. The information is retrieved from the database of known vulnerabilities. The ignored components are selected through the GUI or the API.

How to manage component ignores in the GUI:

1. Select components in the Vulnerability Analysis tab and click on Ignore selected components to ignore them for the current scan.

   

2. After selecting the ignored components, the Ignore components modal is opened. You can select the scope and enter a description for the ignore.

   

3. You can remove components in the Ignored Components section with the Remove component ignores button.

   

Black Duck Binary Analysis identifies Linux Kernel configuration files discovered in the scan. You can click on the Kernel config files section to view identified configuration files. Clicking on the configuration file name displays the details of the configuration along with the file path.

The Kernel configuration options are listed below the file details. The values and expected values of the configuration options are presented. If you click on the name of the configuration option, the details and dependencies are displayed. The configuration option details are derived from CLIP OS data which is available from the associated link. For CLIP OS data, see https://docs.clip-os.org/clipos/kernel.html. If a KSPP link is available, additional information may be present. For KSPP, see https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings.

In addition to configuration files, Black Duck Binary Analysis identifies Linux kernel modules and their vulnerabilities. After scanning a Linux kernel, you can click on the Modules section to view identified modules. The user can see the details of the modules, including the size, whether they are built-in or loadable, timestamp and matching method.

Clicking on a module name displays the path of the module.

The vulnerability data for each component shows a severity score calculated according to the common vulnerability scoring system (CVSS) and the probability of vulnerability exploitation according to the Exploit Prediction Scoring System (EPSS).

You can toggle between CVSS 2, 3 and 4 using the CVSS version switch in the Actions list. Some of the numerical results change, because CVSS 3 and 4 use one additional category, called critical, in addition to low, medium, and high. It also relies on different rules for scoring vulnerabilities. Thus, the number of vulnerabilities in each category might change.

The EPSS score displays a percentage between 0 and 1 (0 and 100%). The higher the score, the greater the probability that the vulnerability will be exploited.

Note that CVSS 3 will display both CVSS 3.0 and 3.1 scores.

This section of the results indicates whether any components have been compiled without certain exploit mitigations. In the results, they are marked with a fire symbol after the component name and version.

Modern operating systems such as Linux and Windows offer exploit mitigations at compile time that, with zero developer effort, create executable code with mechanisms that make it harder for attackers to exploit vulnerabilities. Black Duck Binary Analysis reports when components are missing these exploit mitigations or contain dangerous execution configurations.

This information is included for each component, if applicable.

Techniques used on Unix systems:

• Execstack: The binary requires that the program stack and heap are marked as executable. As a result, any data that the program handles, including user and network input, can be interpreted as code and executed. This significantly lowers the bar for buffer overflows and other exploits to execute injected code. Also note that this feature runs contrary to most security features listed below that try to reduce the number of program areas which are writable and executable at the same time.
• WX: Writable XOR executable is the name of a security feature originally developed for the OpenBSD operating system, which is now also found in Linux and other operating systems. It is a memory protection policy whereby every page in a process' address space is either writable or executable, but not both simultaneously.
• RELRO: Relocations Read-only is a mitigation technique to harden the data sections of an ELF binary. RELRO Hardens ELF programs against function pointer overwriting by having the loader mark the areas of the relocation table as read-only for any functions resolved at load-time. This reduces the area of possible code path modification attacks.
• PIE: Position Independent Executables (PIE) are an output of the hardened package build process. A PIE binary and all of its dependencies are loaded into random locations within virtual memory each time the application is executed. This makes Return Oriented Programming (ROP) attacks much more difficult to execute reliably.
• RPATH: RPATH refers to a run-time search path hard-coded in an executable file or library, used during dynamic linking to find the libraries the executable or library requires. The RPATH header value may either override or supplement the system default dynamic linking search paths. Using RPATH in release binaries is usually considered an unsafe programming practice, and may under certain conditions lead to security exposure. An attacker may be able to supply their own shared files in directories where RPATH is pointing to, thereby overriding those that would be supplied by the operating system.
• Spectre: Spectre uses chunks for indirect jumps to avoid side channel issues due to speculative execution. This applies only to x86 architectures and requires that the executable be compiled with debug information for the feature to be discoverable.
• Stack Protector: Emits extra code that is used to check for buffer overflows in functions that might be vulnerable to that type of attack. See: https://gcc.gnu.org/onlinedocs/gcc-4.4.2/gcc/Optimize-Options.html#index-fstack_002dprotector-796.
• Fortify Source: Emits extra code that is used to check for buffer overflows in functions that might be vulnerable to that type of attack. See https://wiki.debian.org/Hardening#gcc_-D_FORTIFY_SOURCE.3D2_-O1.
• Immediate Binding: During program load, all dynamic symbols are resolved by the linker. This allows for the complete function table to be marked read-only, thus mitigating some function pointer overwriting attacks.

Techniques used on Windows systems:

• Data Execution Prevention (DEP): Buffer overflow attacks, in which an attacker forces a program or component to store malicious code in an area of memory not intended for it, are some of the most common exploits seen today. DEP is a Windows feature that enables the system to mark one or more pages of memory as non-executable. Marking memory regions as non-executable means that data in that memory region cannot be run as code, which makes it harder for exploits, including buffer overflows to succeed. DEP was introduced in Windows XP SP2 and has been included in all subsequent releases of Windows desktop and server operating systems.
• ASLR: Address space layout randomization (ASLR) is a technique that randomizes the memory locations used by system files and other programs, making it much harder for an attacker to correctly guess the location of a given process. The combination of ASLR and DEP creates a fairly formidable barrier for attackers to overcome in order to achieve reliable code execution when exploiting vulnerabilities. ASLR was introduced in Windows Vista and has been included in all subsequent releases of Windows. As with DEP, ASLR is only enabled by default for core operating system binaries and applications that are explicitly configured to use it via a new linker switch.
• SafeSEH: Safe Structured Exception Handling disallows the execution of exception handlers that have not been registered at compile time. Introduced in the Visual C++® .NET 2002 (also known as VC7) compiler, /SafeSEH is a compile-time flags that developers can use to make their applications harder to exploit.
• CFG: The Control Flow Guard verifies that indirect function calls go only to allowed targets, thus mitigating control flow diversion attacks.
• RFG (deprecated): Return Flow Guard verifies that each function's return address has not changed by comparing it to the return address written in the Thread Control Stack. Note that this protection is now obsolete and not available in latest Windows updates. Hence, it will not be reported anymore as missing mitigation in the results.
• CET Control-Flow Enforcement Technology (CET) uses a hardware backed shadow stack to check and enforce a non modified control flow. Currently, the hardware part is only available on x86 architectures.
• High Entropy ASLR: High Entropy Virtual Address verifies that at load time the 64-bit system with ASLR support can create randomized addresses into virtual address space. This makes it more difficult for attackers to find a particular memory region. See https://msdn.microsoft.com/en-us/library/jj835761.aspx.
• Enforced Code Integrity: Integrity check ensures that only signed binaries are executed. See https://docs.microsoft.com/en-us/previous-versions/dn195769(v=vs.140).
• Buffer Security Check: Buffer Security Check detects some buffer overruns that overwrite a function's return address, exception handler address, or certain types of parameters. See https://msdn.microsoft.com/en-us/library/8dbf701c.aspx.
• Authenticode: Authenticode code signing is the process of digitally signing executables and scripts to confirm authorship.
• Manifest Isolation: Manifest Isolation forces the linker to search and load a manifest file for each new process. See https://msdn.microsoft.com/en-us/library/daa1w5yk.aspx.

Under the Mobile apps tab you find requested permissions for binary code types where it is relevant, such as Android and iOS apps. The Mobile apps tab is only visible when a mobile application is scanned.

Application infomation displays details of the scanned application, including name, package, version and so forth.

By clicking on Permissions, you can see the permissions requested by the application.

The permission details are parsed from AndroidManifest.xml for Android and from info.plist for iOS.

In Android, permissions are divided into the following different categories:

• Potentially dangerous: Runtime permissions that system assigns the "dangerous" protection level
• Signature: The system assigns the "signature" protection level to signature permissions
• Not for use by third-party: Permissions are not for use by third-party applications
• Normal: The system assigns the "normal" protection level to normal permissions
• Third-party: Custom developer defined application permission
• Hardware features: permissions to access hardware features

In iOS, permissions are divided into the following different categories:

• Permissions
• Hardware features

By hovering over the information button next to the permission, you can see additional information about the rationale of the classification.

The following figure shows the mobile application information and related permissions.

This section shows the detected software licenses, including which components they apply to, and the type of licensing granted. Select a license to show the associated components.

If Black Duck Binary Analysis completes its analysis but finds no components, there are several possibilities to consider:

• Some or all of the executable code might be encrypted. Black Duck Binary Analysis cannot analyze encrypted bits. You'll need to obtain a plaintext executable and submit it to Black Duck Binary Analysis for analysis.
• Your uploaded file might use compression that Black Duck Binary Analysis does not support. Although Black Duck Binary Analysis does recognize and unpack a very wide variety of compression technologies, it does not support everything. If you believe this is the case, ask us about it.
• Keep in mind that Black Duck Binary Analysis cannot find components about which it does not know. Said another way, Black Duck Binary Analysis has a set of libraries it recognizes. If your uploaded file contains other third-party components, or proprietary components, Black Duck Binary Analysis will not be able to recognize them. You can view a list of all components known to Black Duck Binary Analysis by selecting Supported components from the Shortcuts pane on the Black Duck Binary Analysis home page. from the Black Duck Binary Analysis menu.
• If you expected to find a specific component, and it is not in Black Duck Binary Analysis's list of known components, ask us about it.

On the Black Duck Binary Analysis results page, at the bottom of the Details tab, the File statistics section provides some information about how Black Duck Binary Analysis was able (or not able) to pull apart the file you uploaded. The information in this section can help you determine if Black Duck Binary Analysis has encountered encrypted bits or an unsupported compression algorithm.