Dependency Resolution
To analyze your application’s source code thoroughly, Sentinel Source needs to have access to all the application’s dependencies (internal and third-party).
Scope
Unless binary analysis is enabled for a specific binary, all assets provided in the form of source code are considered to be in scope, while all assets provided in binary form are considered to be out of scope.
-
For more information on using source code versus binaries to resolve dependencies, see General Scanning Principles.
-
For more information on binary analysis, please see Binary Analysis - an End to End Task Aid.
Package Managers
To facilitate the automated delivery of application dependencies that are not stored in an application’s source code repository, Sentinel Source supports popular package manager tools such as Maven, NuGet, Gradle, NPM, Yarn, Composer, and Bower. These tools are highly customizable, and many applications will require additional configuration to ensure that the package manager can download application dependencies successfully. For more information on how to provide package manager configuration files, see Asset Scan Configuration.
In addition, it is possible that the application developers have structured their projects in ways that vary from the best practices of their package management system, or that may require additional custom steps to succeed. Under these circumstances, it may be difficult to replicate the package manager process on the scanning appliance. If so, you can provide an archive of the dependencies as an additional codebase or you can leverage build automation to deliver the application’s source and dependencies as a single archive.
For more information on adding dependencies as an additional codebase, see Adding a Codebase.
To arrive at the ideal scanning configuration for your application, it is important to combine an understanding of Sentinel Source’s default behaviors and options with a detailed understanding of the application being scanned and the development practices used to build it. A basic understanding of the scanning and dependency resolution process will assist you in communicating the scanning requirements to internal teams, who have the necessary detailed understanding of the applications to be scanned. This helps you to self-onboard applications successfully.
Black Duck’s Rapid Deployment Solutions team and the Black Duck Threat Research Center’s SAST configuration team are available to assist in this, in order to ensure that you realize maximum value from your scans.
Scan Dependency Resolution Lifecycle Basics
-
The Sentinel Source appliance receives a scan request from Sentinel’s scan scheduling infrastructure.
-
The Sentinel Source appliance uses the provided codebase information to download the repository or archive contents onto disk.
-
The Sentinel Source Engine recursively discovers relevant package manager files.
-
Maven: pom.xml
-
Nuget: packages.config
-
Gradle: build.gradle
-
NPM: package.json
-
Composer: composer.json
-
Yarn: yarn.lock
-
Bower: bower.json
-
-
For each discovered package manager file, the relevant command is issued to download the application’s dependencies and save them into a scan-instance-specific location on the Sentinel Source appliance.
| Sentinel Source does not use the package manager to run a full build of the application. If your application requires a full build to assemble all dependencies you may need to provide dependencies as an additional codebase instead of relying on the package manager. |
-
The Sentinel Source Engine recursively discovers relevant binary files in the local copy of the repository and in the location that package manager downloaded assets were placed. All binaries are added to the class path of the scan.
-
The Sentinel Source Engine loads and parses all source code found in the repository. During this parsing, code references are resolved with the following order of preference:
1st: Source code declarations
2nd: Binaries on the class path
3rd: WhiteHat rulepacks -
If a code reference cannot be resolved by any of the above sources, some portion of the code surrounding the unresolved code reference will be removed from the data-flow analysis portion of the scan. This removal allows Sentinel Source to continue the scan instead of failing like a typical compiler.
| Any scan where dependency issues are encountered will still succeed, but coverage will be incomplete. Black Duck cannot determine the extent of the coverage or lack thereof until all application dependencies have been provided. |
-
Any issues relating to unresolved code references or missing dependencies will be shown in the Continuous Dynamic Portal UI under the File Coverage section of each application’s overview page.
-
For more information on the information provided in the File Coverage section, please see File Coverage.
-
This information can also be retrieve via the Continuous Dynamic API, for additional information on the API please see Continuous Dynamic API Introduction and Resources.
-