Scanning Your Apps

Black Duck Binary Analysis has an easy-to-use browser interface. When you log in to Black Duck Binary Analysis, you will see the home page. The home page shows the group view. The group view contains three tabs:

User groups contains all the groups that you belong to.
Favourite groups contains groups that you have marked as favorites.
All groups contains the hierarchies of all groups that you are allowed to see.

You can filter groups by name and description.

Workflow

You can analyze an application by uploading a file or by providing an URL for the file.

To upload a file:

From within a group, select Upload in the menu bar.
Select Upload files.
Choose the file you wish to upload.

The web UI will time out after 30 minutes when uploading files, and the API interface will time out after 90 minutes. As soon as the file finishes uploading, Black Duck Binary Analysis begins its analysis. In general, results will be available in a few minutes, but the length of the analysis depends on the size of the upload.

To provide an URL for a file:

From within a group, select Upload in the menu bar.
Select Fetch from URL.
Enter the URL to the file you wish to scan. Supported protocols are HTTP, HTTPS, FTP, and Docker Registry HTTP/HTTPS. Docker registry supports image:tag syntax. If a tag is not specified, tag latest is used. Docker registry supports also the image@sha256:digest syntax for fetching images by digest.
Docker registry example:
```
docker-registry-http://index.docker.io/library/debian:buster
```
Docker registry digest example:
```
docker-registry-http://index.docker.io/library/debian@sha256:827e8e75aacb505fe83ee43a3d2ec94dabbc56fa1e8f3d9837b12fa4701ab888
```
Select Fetch file.

Note that the number of concurrent scans you are allowed to run can be limited by your organization's settings.

Scan Options

When you are uploading binaries, there are different options for scan which can enhance the scan results.These scan options are also available in Groups and Account Settings.

The options are:

Information Leakage: scans for information leakage in binaries.
Rapid Scan Static: scans for issues in static code using the Rapid Scan Static engine.
Code Similarity: scans for small libraries in embedded code. This is an experimental feature which can slow down the scans significantly.
Config file URL provides a URL to a remote analysis configuration file to be used for the scan. Using a remote config file will cause any config files within the uploaded binary to be ignored. Filename of the remote config file can be anything. This option is currently only available in the upload view and via the API.

SBOM Import

SBOM import is performed according to the instructions in the Workflow sections above. BDBA automatically detects the contents of the SBOM file and the results are displayed in the Vulnerability Analysis tab.

Go

Black Duck Binary Analysis can detect components and their versions from go binaries if they are compiled with a new go build system that embeds dependency information into binaries (disabled by "GO111MODULE=on"). You can also set Black Duck Binary Analysis to perform go.sum parsing even if information is available in the binary. If dependency information is not available inside the binary, Black Duck Binary Analysis can still read information from go.mod or go.sum, provided that they are included with the scan.

The scanner looks for the following paths:

{go-binary}.go.mod
{go-binary}.go.sum
{directory-to-go-binary}/go.mod
{directory-to-go-binary}/go.sum

Black Duck Binary Analysis also includes a go scanning engine for X86-architectures to scan go binaries that do not have dependency information embedded in the binary. This scanning technology predates embedded go.mod and is somewhat less accurate than dependency information inserted by the go tool chain. It is possible to enable and disable this scanning engine. However, when BDBA encounters X86 go binaries without embedded dependency information, it will be used.

Podlock

Black Duck Binary Analysis can detect the version from Podlock files and match them to found CocoaPods components.

The scanner looks for the following paths:

{executable_name}.Podlock.file
{executable_name}/Podlock.file

Dependency Detection

The detection of dependencies varies depending on the content of the binary package.

Maven pom - direct and indirect dependencies will not be reported.
- For example https://mvnrepository.com/artifact/org.apache.maven/maven-core/3.9.0, which contains the pom file /maven-core-3.9.0/META-INF/maven/org.apache. maven/maven-core/pom.xml, has <dependencies>
- When BDBA scans, it will not report any dependencies except maven-core3.9.0.
Signature scans - direct and indirect dependencies will not be reported.
Linux kernel modules, dotnet modules - no dependencies will be reported.
SBOM - will flatten the import of all components recorded in SBOM
- CycloneDX does not have a component dependency tag.
Components declared in go.mod, podlock, JS package.lock files will be imported, but will not be listed as indirect dependencies, but will be imported as components.
- go.mod indirect example:
```
ˆgithub.com/Azure/go-ansiterm v0.0.0-20210617225240-d185dfc1b5a1 // indirect
    github.com/Microsoft/go-winio v0.6.1 // indirect
    github.com/Microsoft/hcsshim v0.11.4 // indirect
```
```