Black Duck - Binary Analysis

Black Duck - Binary Analysis(BDBA), an integrated add-on for Black Duck, identifies the open-source security, compliance, and quality risks in the software libraries, executables, and vendor-supplied binaries in use within your codebase. BDBA supports expanded file type support including various firmware formats, filesystems/disk images, installation formats, and various compression and archive formats. With Black Duck - Binary Analysis, you can:

  • Analyze virtually any compiled software, firmware, mobile applications, or multiple installer formats, without needing to access the source.

  • Identify embedded open-source usage and risks within binary executables and libraries.

  • Manage code decay and improve software quality within binary dependencies.

  • Monitor new vulnerabilities in previously scanned binaries.

Architecture overview

BDBA integrated with Black Duck consists of these components that work together to provide Black Duck - Binary Analysis functionality.


BDBA Architecture

Black Duck Detect

Black Duck Detect uploads the binary file to the BDBA scanner located in the BDBA container on the Black Duck server. Black Duck Detect does not scan the binary file.

The binary file, sent to the customer's Black Duck server, is treated as confidential information by Black Duck in accordance with our customer agreements. By default, all communication with Black Duck servers is done via HTTPS. More specifically, all session data is encrypted using TLS1.2. Customer sites always initiate connections with Black Duck services; the hosted Black Duck services never call out to the Black Duck application. The customer's Black Duck servers contain the HTTPS certificate, the Black Duck application initiates all connection requests using the certificate’s public key.

Black Duck Detect always runs locally, on the customer's premises. Binaries stay within the company's network environment and are uploaded to a Black Duck - Binary Analysis container which is within the company's premises.

BDBA container

The BDBA scanner scans the binary file and generates a .bdio file. This file contains signatures of the binary file and is passed to the Black Duck web application. It then generates a Bill of Material, or “BOM”, which details the open-source components/versions and presents the associated risk factors – security risk, license risk, and operational risk. If also using Black Duck scanning methods at the same time, the binary results are unified into a single BOM with the Binary match type designating the BDBA identifications.

Once scanning is completed, the binaries are immediately deleted.

How BDBA identifies 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.