Blackduck github

Blackduck github DEFAULT

Popular repositories

  1. detect_advisorPublic

    Detect Advisor - to pre-scan projects and advise options and optimisations for Synopsys Detect (Black Duck scanning)

    Python 5

  2. bd_export_spdx2.2Public

    The script is designed to export an SPDX version 2.2 JSON file from a Black Duck project.

    Python 4 2

  3. detect_rescanPublic

    Bash script to wrapper Black Duck Detect to reduce duplicate scan uploads between runs

    Shell 3 3

  4. bd_API_utilitiesPublic

    Various API scripts for Black Duck - for use alongside the hub_rest_api_python package

    Python 2

Contribution activity

October 2021

You can’t perform that action at this time.

You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.


Black Duck Scanner

A Github action for running Black Duck analysis on your codebase inside a Docker container.

Required parameters

projectNameYour project name in BlackDuck
versionPrefixVersion prefix
tokenBlack Duck token token
urlBlack Duck server url
sourePathsource path
extraArgsExtra arguments that will be passed to the detector

Sample Configuration

To prevent your token from showing in the runner's output, it is advised to store the token configuration inside of a github secret variable.

The listing below uses the secret from your project's configuration.

blackduck: name: BlackDuckruns-on: self-hostedsteps: - uses: philips-labs/[email protected]: token: ${{ secrets.BLACKDUCK_TOKEN }}projectName: Your project nameversionPrefix: You version prefixurl: /codeextraArgs:
  1. Air pro spray gun
  2. Fallen order sith
  3. Situated thesaurus

Black Duck Software, Inc.



  • ohloh-ui Public

    Web Application for the Ohloh Stack. Currently Rails 4.2.7 & Ruby 2.2.5

    Ruby 60 35 3 6 Updated

  • Java 74 Apache-2.0 33 0 5 Updated

  • blackduck-alert Public

    Processes notifications from BlackDuck and sends them to supported distribution channels

    Java 14 Apache-2.0 19 0 2 Updated

  • blackduck-java-api-examples Public

    Showcase of example scripts giving usage examples of how to call and utilise the blackduck-common Java API.

    Java 1 Apache-2.0 1 0 0 Updated

  • Java 1 2 0 2 Updated

  • Java 1 Apache-2.0 26 6 0 Updated

  • Go 5 Apache-2.0 15 8 2 Updated

  • sage Public

    A tool for inspecting the usage of a Black Duck instance and offering wisdom about how to make better use of the system

    Python 5 Apache-2.0 7 0 1 Updated

You can’t perform that action at this time.

You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.

BlackDuck Software (Securing Open Source) Explainer Video [Illustrate iT Video]

jenkinsci / blackduck-hub-plugin Public archive

This product is now deprecated. Please use Detect for all scanning and discovery solutions going forward.


Hub plugin for Jenkins. This plugin provides ability to run a scan using the BD Hub CLI on build input and/or output. You can scan multiple targets, fail builds based on Hub policies, and display Hub reports for a particular Build.


Build StatusLicense

Where can I get the latest release?

You can download the latest artifact from releases:


All documentation can be found on the wiki:


Github blackduck - v1.22

Bash script to wrapper Synopsys Detect for Black Duck scanning to reduce duplicate scan uploads between runs for use in frequent automated scan processes and optionally produce immediate project security summary reports.

This script is provided under an OSS license (specified in the LICENSE file) to allow users to report and manage unconfirmed snippets within a Black Duck project version.

It does not represent any extension of licensed functionality of Synopsys software itself and is provided as-is, without warranty or liability.

The script is intended to address issues caused by frequently calling the Black Duck Detect scanner within a CI/CD pipleine or automated build environment which can result in repeated scans being submitted and performance issues on the Black Duck server. It can also produce console and other optional outputs of project status after analysis.

Detect Rescan is not intended to replace Synopsys Detect, which should continue to be used for standard Black Duck scanning, except specific use-cases where it can be useful including within Developer pipelines within CI, or where the reporting features are useful.

It is used as a wrapper for the standard Synopsys Detect bash script on Linux or MacOS (or in Windows using a Bash sub-system), and does the following:

  • Processes supplied Synpsys Detect options to determine if a post-action is required (also looks at environment variables and options in a .yml if specified)
  • Downloads and runs Detect ( offline with supplied options to perform a scan
  • Identifies the BOM and Signature scan files from offline run (note the script should only be used for projects where 1 signature scan has been mapped)
  • Looks for previous scan data (see below for location of this data)
  • Compares scanned BOM files and upload files if different/new to previous scan
  • Checks last date/time for signature scan and uploads if more than specified period (24 hours by default) or new scan
  • If post-action or report required:
    • Waits for server-side scan and BOM completion
    • Runs Detect to perform post-action with no rescan
  • If or specified, produce summary reports (--markdown writes the file in MD format)
  • If specified, produce junit XML test output files (policies.xml and vulns.xml)
  • The script requires a bash shell to run.

  • The following additional programs must be installed in the environment and the script will check for them:

    • cksum (usually installed on MacOS & Linux)
    • curl Please refer to your platform documentation to install these. The program jq is also required but will be downloaded dynamically if not available.
  • The script uses a custom field ( of type ) in Project Versions by default to store previous scan data. The API key used for scanning will require the permission within the projects to be scanned (or be the project creator) to read and update this custom field.

  • Alternatively, if the option is specified, the script will write the file to the top-level folder of the project to be scanned which needs to be retained between runs. If the project location is not persistent, then the .bdprevscan file should be copied to a permanent location (and copied back before subsequent runs) or the script could be modified to write to a persistent location to ensure the file is saved between runs.

  • The script uses Synopsys Detect to perform scans, and has the same prerequisites including internet connectivity to download the script, connection to Black Duck server to upload scans, access to package managers for dependency analysis etc.

  • Detect_rescan should not be used for projects where more than 1 signature scan has been mapped.

  • Detect_rescan does not support Snippet or Binary scan types (Dependency and Signature scans are supported).

  • BOM Aggregation (using in Detect) is not recommended (although should be supported) as it will cause separate BOMs to be aggregated which will reduce the ability of the script to determine changes within sub-projects.

The default script operation is to store scan data in a custom field within Project Versions (unless the option is specified which will cause the scan data to be stored in the file in the project folder).

You will need to administer the server to create a new custom field within Project Version with the name and type .

As an administrator, perform the following in the Black Duck Web UI:

  1. Select the option
  2. Select the table
  3. Select
  4. Choose type
  5. Enter the name and click Save

Ensure the custom field is enabled before continuing.

The script can be downloaded and executed dynamically using the following command:

where DETECT_OPTIONS are the standard Synopsys Detect options and ARGUMENTS are the additional detect_rescan arguments (see below).

Alternatively the script can be downloaded and saved locally using:

The Black Duck server URL and API token are required and can be specified either as environment variables ( and ), in a project application-project.yml file (specified using ) or as command line arguments ( and ).

The script provides some options in addition to the standard Synopsys Detect arguments as follows:

The example output of the option is shown below:

Set the environment variable to any non-blank value to cause the script to output extra debug messages. Note this will also cause the Detect program to output additional information.

The script should be used in place of Synopsys Detect at the same integration points where a direct call is made to the script.

It is not suitable for use with Synopsys Detect CI/CD plugins and other integrations which do not call the (bash) script or which call the Detect jar directly.

The script operates under Linux/MacOS via bash, but can also be used under the Bash task in Azure DevOps on Windows. The script may also operate under the Windows Linux subsystem although this has not been tested.

The following sample yml task shows how the script can be used as a Bash step within an ADO pipeline. This would replace any other integration to call Synopsys Detect including the ADO plugin or direct call to This step can be used on either Linux, MacOS or Windows targets.

For Windows targets, the Windows Bash is not 100% compliant and the following modified yml may be required:

The option will cause to generate output files and which includes scan results in Junit format. The test data represents the OSS components identified in the Black Duck scan, with components which have 1 or more policy violation being marked as a failed test. Components without policy violation are shown as passed tests. The test data represents the outstanding vulnerabilities from the Black Duck project (remediated/ignored vulnerabilities) with open vulnerabilities being marked as a failed test.

The json file can be imported as test results using the CI features for Junit test analysis.

For example, in Azure DevOps, the following yml fragment can be used to import the policies.xml (or vulns.xml) file:

BlackDuck Software (Securing Open Source) Explainer Video [Illustrate iT Video]

Black Duck GitHub Pull Request Scanner (archived)


This solution is no longer supported with the general availability of GitHub Actions. Synopsys recommends evaluating the Synopsys Detect GitHub Action to determine if it's a better solution than the Black Duck GitHub Pull Request Scanner (GHPRS). As GitHub Actions become more prevalent, Synopsys will start to deprecate GHPRS. Email  [email protected] with any questions or opinions.

Version 1.0.2

The Black Duck GitHub Pull Request Scanner makes it easy to scan GitHub repositories without configuring a continuous integration (CI) tool. 
You might want to scan without using a CI tool in the following circumstances:

  • Your organization does not have a CI tool.
  • Your organization has a CI tool, but you don't have permission to configure it.
  • Your organization has multiple CI tools, and you’d like to run a direct scan without configuring multiple CI systems.

The Black Duck GitHub Pull Request Scanner is also useful for Black Duck demonstrations and testing before you modify your production CI system. 
The Black Duck GitHub Pull Request Scanner calls the Black Duck Detect utility, and leverages the open source Concourse CI tool to initiate a build, ensuring scan results from Black Duck Detect. 

The Black Duck GitHub Pull Request Scanner only triggers a scan from a pull request.

  • 1 quad-core Intel Xeon processor, 16 GB RAM, minimum 500 GB disk space.
  • Linux kernel versions 3.19 and later: 
    • RedHat Enterprise Linux versions 7.4 and later.
    • Ubuntu versions 15.04 and later.
    • SUSE Linux Enterprise Server versions 12 SP2 and later.
  • Docker with engine versions 1.13 and later.
  • Docker Compose versions 1.16 and later.
  • Java 8 JDK.
  1. Download and extract the archive from
  2. Using a Bash shell, navigate to the setup directory.
  3. Run   and respond to the prompts.

The setup process requests Black Duck account credentials. These credentials are stored and sent with scan information to Black Duck.

Securing the Black Duck GitHub scanner

Plain text is used for communication between the browser and Black Duck GitHub Pull Request Scanner (Black Duck GitHub Scanner), which is not secure.
However, GitHub tokens and private keys are sent back and forth by using this channel.
Do the following steps to secure your Black Duck GitHub Scanner installation.

  1. In a Bash shell, navigate to the setup directory in the directory where you cloned the repository.
  2. Copy a PKCS12 trust store file as .
    To generate a self-signed key, run the following command:

    keytool -genkey -alias hub-scm -storetype PKCS12 -keyalg RSA -keysize 2048 -keystore keys/ui/keystore.p12 -validity 36500
  3. Respond to the prompts, and make a note of the password because you use it in the next step.
  4. Add the following command to your shell environment, and substitute mypassword with the password from step 3.

    export UI_STARTUP_OPTS="-Dserver.ssl.key-store=/opt/keys/keystore.p12 -Dserver.ssl.key-store-password=mypassword -Dserver.ssl.keyStoreType=PKCS12 -Dserver.ssl.keyAlias=hub-scm"
  5. Restart the application by running the following command:
     followed by 

Starting the application

When setup is done, run the following command to start Black Duck GitHub Scanner.

When the system starts, you access it at http://(hostname):8666

Stopping the application

To stop the application, run the following command.

Uninstalling the application

To uninstall the application, run the following command.

When you run this command, delete the cloned repository.

This following list describes the actions that you can take by using the Black Duck GitHub scanner:

  • Logging in.
  • Configuring a source code management repository.
  • Configuring a monitoring repository.
  • Automatic scanning of pull requests.

  • Discontinuing monitoring.
  • Deleting an SCM.
  • Injecting files into builds.

  • Applying settings to multiple repositories.

The following section describes the items in the list:

Logging in

Log in to the application when the application is installed, configured, and running.
Log in with Black Duck instance accounts to which Black Duck GitHub Scanner is connected at setup. 

Accounts must have the codescanner role assigned to configure repositories because configuring a repository can result in code scanning.

Configuring a source code management repository

Use the following process to configure a source code management (SCM) repository:

  1. On the navigation bar, click SCMs.
    An empty list of SCMs displays.
  2. Click New to open the Add repository screen, and then complete the following fields:
    • Name: friendly name for this SCM repository.
    • API Token: this token enables the Black Duck GPRS to check GitHub for pull requests.
      Get a personal use token by logging into a GitHub account with permissions to access the relevant repositories.
      Then, complete the process for Creating a personal access token for the command line.
      • If only public repositories are monitored, the scope is sufficient.
      • If private repositories are monitored, you must be granted the entire  scope.
    • API Endpoint: If you use, use the default value (
      If you use GitHub enterprise on a private host, the API endpoint is .
    • Private Key: If you are only monitoring pull requests on public repositories, ignore this field.
      If at least one private repository on this SCM is monitored, this field must contain a private key with a corresponding public key registered to an account that is authorized to clone the scanned repositories.
      For more information about configuring SSH keys in GitHub, refer to Connecting to GitHub with SSH. 

      The private key can't have a passphrase.

    • GitHub host name: If you use, use the default value ( Otherwise, specify the host name or IP address of the installation. Omit thehttps://  part of the address.
    • Skip SSL Verification: When you use GitHub Enterprise configured with a self-signed certificate, attempts to connect to its API and to pull code from pull requests fail because of the untrusted certificate signer.
      Select this Check box to prevent that failure.
      Leave the box unchecked when using

Configuring a monitoring repository

When an SCM is configured, do the following tasks:

  1. Click Repos on the navigation bar to configure a repository to be monitored for pull requests.

    To add or edit repositories, Black Duck users must be assigned the codescanner role.

  2. Click New to create a new repository, and then complete the following fields.
    • Source: an SCM, as configured in the previous section.
    • Repository: A repository on that SCM. For example, to monitor the Scan-SCM repository on, the repository value is blackducksoftware/hub-scm. 
      To examine all dependencies, Black Duck GitHub Scanner builds the source code. The subsequent fields determine how the project is built. 
    • Build Type: A preset of common values for the fields that follow.
      For example, for most Maven projects built on Java 8, setting this value to Maven might be enough to configure the repository without modifying other fields.

      Only the build types that are shown in this box are supported.
      Only Gradle versions 3.1 and later are supported.
      For some build-type selections, you must configure specific Hub Detect properties.
      For example, for a project named python3, you must add --detect.python.python3=true to the detect arguments field.

The following advanced options might be required in special cases:

  • Build Image: Docker Black Duck name of an image on which the build is run.
  • Build Image tag: Docker Black Duck tag of the image on which the build is run.
  • Build Command: command required to build the repository and pull in all dependencies.
  • Project Name: name of a Black Duck project to which scan results are uploaded.
    The project can already exist on Black Duck, or it can be a new project.
    • If the project exists, the Black Duck user whose credentials are provided at configuration must have access to that project.
    • If name is left blank, Black Duck Detect provides a project name derived from the build metadata.
  • Version Name: The name of the version to be created in the Black Duck project, which might be specified even when the project name is not specified.
    • If the version name is left blank, it is named Pull Request X, where X is the numerical GitHub identifier of the pull request.
    • If the version name is specified, all pull request scans are written to one project version.

Automatic scanning of pull requests

All pull requests are submitted to a repository configured for monitoring as previously described. After configuration, an automatic build is triggered, and a Black Duck Detect scan is initiated by Black Duck GitHub Scanner.

Clicking Repos in the navigation bar displays a status indicator next to each repository.
The status values are as follows:

  • Never Built: no pull requests have been made on this repository since it was configured for monitoring.
  • In Progress: a new pull request is detected and is being built and analyzed.
  • Failed: the attempt to build or scan the most recent pull request failed.
  • Violation: the attempt to build and scan the most recent pull request succeeded, but one or more components violate the current policy as configured on Black Duck.
  • Success: the attempt to build and scan the most recent pull request succeeded and no policy violations are found.

Discontinuing monitoring

To stop monitoring a repository for pull requests, click Repos in the navigation bar and click the delete icon ( ) next to the name of the repository. When the repository disappears from the list, its pull requests are no longer monitored.

Deleting an SCM

To delete an SCM, click SCMs on the navigation bar and then click the delete icon () next to the SCM to be deleted.
You only delete those SCMs that don't have monitored repositories.
For SCMs that have monitored repositories, you must first delete those repositories on the Repositories screen.

Injecting files into builds

Building a project may require configuration or metadata files that reside outside the source repository.
For example, the configuration for the build system to use a specific binary artifact repository might be stored in a file that is not checked into GitHub.
Or, if the build must be executed from a specific shell script, that script can be uploaded.

Inject files into the build environment by using the following process.

  1. Click Files.
  2. In the Upload new files dialog, select a file to upload. The file size must be 1 MB or smaller.
  3. Specify a name for this file; this is a name that you can use to identify it, not the name of the file in the build environment.
  4. Click Submit.
  5. Next, click Repositories to navigate to the repository and the build in which you have injected this file.
  6. In File Injection, click the plus () icon to add a file injection. 
  7. Select the file you uploaded from the drop-down menu.
  8. In the Target field, type the absolute path to which the file is copied.
    The directory into which the file is to be placed must exist in the build image.
  9. When you have added the files to inject and specified their targets, click Submit.

Applying settings to multiple repositories

GitHub accounts and GitHub enterprise installations can contain multiple projects of the same kind. In other words, these projects can be built and scanned using identical settings.
Cloning enables you to apply the build and scan settings for one repository to many other repositories on the same GitHub server and account. 
To apply settings to multiple repositories, use the following procedure:

  1. Configure one SCM and repository. Ensure that it successfully builds and scans.
  2. From the Repositories tab, click the clone icon () to open The Clone Repository panel.
  3. In the Clone Repository panel, type the names of all repositories to be scanned using the same settings.
  4. Click + (plus icon) to add more repositories.
  5. Click Submit.

    Repositories that belong to other accounts not configured for the source repository can only be added when they are public repositories, or if the user whose private key and API token are configured in the SCM settings has access to those repositories.

To upgrade to a newer version of the application, use the following process:

  1. Pull or extract the upgrade version.
  2. Navigate into the setup directory using a Bash shell.
  3. Run the following command:

This step stops the application, and builds and installs the upgrade. 
When the upgrade is finished, the upgraded application automatically restarts. 
All configured SCMs and repositories are retained and unaffected by the completion of the upgrade.

Enabling build log capture

Because repositories monitored by Black Duck GitHub Scanner must be built before scanning, there is a possibility that one or more of the builds can fail.
To troubleshoot build failures, run the following command in your shell before you run the startup script.

export HUB_SCM_BUILD_LOG_DIR=/var/logs/mybuildlogs

Replace  with the directory that you want to store the logs.

The directory must exist before you run the application.
The application does not rotate or erase old logs, so if you want to keep using this setting, ensure that old logs are deleted periodically.

When running on MacOS, which is not officially supported, you can only specify a log directory that is available to Docker or a subdirectory of that directory.
To see the list of available shared directories, navigate to the Docker menu, select Preferences, and then select the File Sharing tab.

Avoiding Black Duck timeouts

When a build completes and Black Duck Detect performs a scan, it uploads the results of that scan to Black Duck and waits for Black Duck to respond with whether or not the contents of the scanned build violate the configured policy.
By default, Black Duck is given five minutes to process the scan and build a Bill of Materials (BOM). For very large projects or under heavy load, five minutes might be insufficient.
To increase this timeout, add the following line to Black Duck Detect Arguments.

Where N is the number of milliseconds that Black Duck Detect waits for Black Duck to respond with the policy status before failing the scan.
To increase the timeout from 5 minutes (300000 milliseconds) to 15 minutes, specify N as 900000.

Version 1.0.2
  • Updates Spring dependencies and internal Docker version.
  • Adds support for Black Duck's global_code_scanner role.
  • Adds support for Gradle 4.6.
Version 1.0.1
  • If you are using Black Duck Hub versions 4.5.0 or higher, you must use version 1.0.1 or later of the GitHub Pull Request scanner. Version 1.0.0 of the GitHub Pull Request scanner is not compatible with Black Duck Hub versions 4.5.0 and higher.
Version 1.0.0
  • First release of the product.

Now discussing:



Blackduck scans work by running the synopsys-detect tool against the code in your repository after the build has been run, and it gathers a list of the third party components in use through a combination of the build tool's package management metadata and a recursion of libraries on the file system, matching their signature against Blackduck's knowledge base.

Getting Access to Run a Blackduck Scan

Blackduck is available to be used by all internal DA users, but you need to login to the Blackduck site to setup your SSO account, create your personal token, and then request to be authorized to the relevant projects by the Security team

  1. Create a personal Blackduck token by authenticating to the Blackduck site with your DA Google account

  2. Click Create New Token and give yourself read and write access, giving a memorable name (- or similar) Copy the contents of this token and define in a local environment variable called BLACKDUCK_HUBDETECT_TOKEN

  3. Once you have created the token, send a mail to [email protected] to request access to the relevant GitHub projects you are working on with Blackduck.

Running Locally

Once you are setup with access, you will be able to run a scan of your project locally and see the results in the Blackduck Hub @

Basic Scan

  1. First run the full build of your project using your build tool of choice (e.g. SBT, Maven, etc)

  2. The most basic scan

where is typically either DACH-NY or digital-asset will be your actual repo name in one of these orgs is the name of the branch you are working on to be scanned

Adding a scan in CI for your project

In order to run a Blackduck scan for your project in CI, you will need to add the command which invokes the Blackduck scan run to the file which defines your CI process.

A synopsys-detect helper script (present in this repository) is provided to keep your project up to date with the latest Blackduck software, and to provide helpers to avoid repetition of boilerplate configuration settings, and provide a consistent project naming across Digital Asset's project.

Enabling scan in CircleCI

To enable the scan, add the command below to your CircleCI config file (usually .circleci/config.xml) as below

Enabling scan in Azure

This is a more complex multi-part scan taken from the open source DAML repo, which is a polyglot repo inclusive of multiple technologies. To scan this repo, the first pass scans for Haskell third party libraries, and the second pass scans for Bazel JVM libraries and NPM and Python libraries reported by the standard package management mechanisms.

Frequency of scan

It is possible to run a scan on every pull request, but this is often excessively time consuming or wasteful as most pull requests do not introduce new third party library versions. If you want to run the scan on every pull request, simply add in the task as outlined above into your main build pipeline.

It is also possible to only run the scan on master pull requests, but the disadvantage then is that you will not get early warning on any issues until changes are merged to master

The compromise that seems to work for most projects is to automatically have a daily scheduled job which runs the scan (so your scan results are reasonably up to date), causing that daily scan to fail if there is a policy failure, and email and/or slack notification of the daily scan failure triggers investigation and remediation of the problematic dependency by the project owner.

Additionally, you can create a rule that allows the blackduck scan to be run on any branch named blackduck-* so you are able to test and verify any changes you make to the scan job on a branch before being merged to master

Enabling daily scheduled scan

In order to schedule as a daily run (rather than on every pull request), you can setup a scheduled daily job similar tot he below

Generating NOTICES file

Whether the NOTICES file is generated or not as part of the scan is determined by the property, which is set to false by default (do not generate the file.

To generate the file, set this property to true, and the scan will wait for all Blackduck Hub server-side processing to conclude, and the full NOTICES file report to be returned before exiting the scan job. The NOTICES file will be output to the present working directory as . In most projects, we rename this output file to NOTICES and keep it in the root of the repo.

To automatically update this notices file when it changes, an approach similar to the below can be taken, assuming your CI service account has the ability to commit code back to a working non-master branch on the repo

Capturing output

Please include store_artifacts to capture output of the job for troubleshooting and support purposes, in case things are not working as planned

Failing build on policy failure

The addition of the following line will cause the scan build to fail if there are policy violations as a result of the scan

Scanning Docker Images

Docker images will not be detected and scanned by default if you have Dockerfiles in your repository, you need to explicitly tell Blackduck what docker images to look for to scan

An example for running a scan against a publicly available container on DockerHub is

The same approach can be taken to scan your repository's own images available locally, but you need to run this scan only after you have run

You can also target your scan to only focus on layers below a particular layer ID to not detect vulnerabilities on base layers that come from an image on which you depend, but rather to focus on vulnerabilities of layers you have added on top of the base layers.

Full details on Blackduck's Docker Scanning capabilities can be found @

Example with exclusions and targeted scans

Bazel Haskell Scan

Notices the defintion of BAZEL as and the specification of as the detect.bazel.dependency to look specifically for Haskell third party libraries

Bazel JVM Scan

Notices the defintion of BAZEL as and the specification of as the detect.bazel.dependency to look specifically for JVM third party libraries -- this will detect both Java and Scala libraries, in fact any third party library that is packaged as a maven-compliant dependency.

Reference on all scan properties

A full list of all properties of Detect and input and output codes can be found at

Detect Blackduck Detect Wiki

Getting Access to Blackduck Hub

Once you have created the token, send a mail to [email protected] to request access to the relevant GitHub projects you are working on with Blackduck.


1159 1160 1161 1162 1163