General Scanning Principles
Source Code or Binaries
Prefer Source Code for Custom Code
Custom code should be scanned as source code, scanning it as a binary will result in the discovery of fewer vulnerabilities, because Sentinel Source does not decompile the binary by default. Dataflow analysis on binary files is limited. If you are attempting to scan a project or module that is dependent on another project or module that is written by your organization, it’s best to add the source code of the dependency. Alternatively, custom rulepack work can be purchased to allow the scanner to understand the security impact of specific calls to that dependency.
Prefer Binaries for Third Party Dependencies
Third party dependencies should be scanned as binaries, particularly for large frameworks. Black Duck is constantly writing and improving our rulepacks to support popular frameworks and specific libraries that our scans indicate are in use by customers. Therefore, scans are faster and more targeted on the customer’s code when these third party dependencies are loaded as binaries.
Multi-Module Projects (Maven)
Multi-module projects contained in a single repository or folder
For multi-module projects that are contained within a single repository location or folder, only a single codebase is needed. For example, OWASP AppSensor is a multi-module maven project that can be scanned in its entirety simply by pointing the scanner to the project’s clone-able URI (https://github.com/jtmelton/appsensor.git).
If you need to scan modules separately (for example, according to internal development ownership), it can be done, but this will require more configuration effort than a single scan of all the modules. In this case, it is likely that core modules will need to be added to multiple scans in order to achieve good coverage.
The Black Duck TRC can curate results that are duplicated across scans according to your needs. You may also need to exclude specific files or folders to properly scope the scan to meet your organizational needs. For more information, see the Exclusions section.
Multi-module projects located in multiple repositories
For multi-module projects that are in multiple repository locations you will need to add a codebase for each module
For SVN, CVS, or TFS projects provide a URL for each module that will allow the scanner to checkout the folder that contains the pom.xml needed to download the module’s dependencies.
For GIT projects you may need to write exclusions for folders not intended to be part of scanning. This is because GIT does not provide a mechanism for checkout of specific folders. In this example, the scanner is configured to only scan three of AppSensor’s modules by excluding the rest of the folders. For more information, see the Exclusions section.
Exclusions
The Continuous Dynamic Portal UI provides a simple string matching mechanism for excluding files or folders. As illustrated above, this is provided as a comma-separated list to be matched against the location of every file before it is loaded into the scan.
To exclude a file named excludethis.java, simply input that filename followed by a comma. If you would like to exclude a folder ./excludethisfolder/, then provide that string (including the slashes) to ensure that it only matches against folders and not files.
Additionally if you have a nested or repeating folder structure, which is common in many Java projects (for example ./src/java/module/src/java), then ensure that you provide as complete a path as possible. This must be relative to the project root being checked out by the scanner, to avoid overly broad exclusion matches.
In some cases it may be difficult or overly complex to write string matches for every file that you would like to exclude. In this case, TRC can write regular expression-based matches for you to lessen the configuration workload.