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 partner-solutions@synopsys.com 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:
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. |
./setup.sh
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. |
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.
Copy a PKCS12 trust store file as keys/ui/keystore.p12
.
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 |
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" |
./shutdown.sh
followed by ./startup.sh
When setup is done, run the following command to start Black Duck GitHub Scanner.
./startup.sh |
When the system starts, you access it at http://(hostname):8666
To stop the application, run the following command.
./shutdown.sh |
To uninstall the application, run the following command.
./reset.sh |
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:
Automatic scanning of pull requests.
Injecting files into builds.
The following section describes the items in the list:
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. |
Use the following process to configure a source code management (SCM) repository:
repo:status
scope is sufficient.repo
scope.https://my-github-enterprise/api/v3
.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. |
When an SCM is configured, do the following tasks:
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. |
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. |
The following advanced options might be required in special cases:
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:
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.
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.
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.
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:
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:
Run the following command:
./update.sh |
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.
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 /var/log/mybuildlogs
with the directory that you want to store the logs.
The directory must exist before you run the application. |
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. |
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.
--detect.api.timeout=N |
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.