Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  1. Open a separate browser tab or window and log in to WhiteSource.

  2. Navigate to the Integrate page of the WhiteSource application. Expand the WhiteSource for GitLab Server bar to view the following fields:

    • GitLab Server API URL: Your GitLab Server instance's API URL. For example: https://GitLabDevServer.com/api/v4

    • GitLab Webhook URL: The URL of the WhiteSource webhook handler (the same URL as the system hook from Configure a System Hook).
      The webhook URL is used to create webhooks from GitLab projects the integration is installed for, to allow WhiteSource Remediate to receive issue related events.
      NOTE: If this webhook URL is on a local server, make sure your GitLab server is configured to allow outbound requests to local servers in Admin Area > Settings > Network > Outbound Requests. Here you can allow outbound requests to your entire local network or simply whitelist the WhiteSource webhook URL.

    • GitLab Webhook Secret: The webhook secret you entered when creating the system hook in Configure a System Hook.

    • GitLab Personal Access Token: The @whitesource user's personal access token created in the previous step.

  3. Click Get Activation Key to generate your activation key. A new Service user is created for this integration inside the WhiteSource Application with a WS prefix.  NOTE: Do not remove this Service user and ensure this user remains part of the Admin group. 

  4. Copy the newly generated Activation Key (You will need it in the next procedure).

  5. If you want WhiteSource Remediate to only open automatic fix MRs in specific scenarios, clicking Manage Workflow Ruleswill allow you to configure custom rules for when Remediate opens MRs.

...

  1. If you are integrating multiple repositories and want to apply global configurations, refer here before continuing in this procedure.

  2. Add the @whitesource user (the user you created during Creating a New GitLab User and a Personal Access Token) as a member with Maintainer permissions to the repositories you want WhiteSource to scan. This is how WhiteSource will determine which repositories will be scanned.

    If you would like WhiteSource for GitLab to scan an entire GitLab group, add the @whitesource user to the group to enable WhiteSource for GitLab for all of the projects within that group.
    NOTE: Adding the @whitesource user to a repository with any permissions less than Maintainer may create side-effects in the integration's functionality.

  3. Unless specified otherwise via the global configuration, an onboarding merge request is created for each repository to which the @whitesource user was added. This request contains a WhiteSource configuration file (.whitesource) that can be customized before merging the request. Once merged, a WhiteSource scan will be initiated.

  4. In order to disable scanning for a repository, remove the @whitesource user from the repository members.

...

Parameter 

Type

Description

Required 

Default

settingsInheritedFrom

String

When the global configuration is enabled, this parameter will specify the location of the whitesource-config repository from which it will inherit its configuration. It must contain the GitLab user name, repository name and branch (optional) of the repo-config.json file location. The default branch is 'master', but can be modified according to the location of the repo-config.json file in the whitesource-config repo. 

NOTE: You can override specific parameters that are relevant only in the specific repository by adding these after this parameter.

Examples:

Using only values defined in the global configuration:

Code Block
"settingsInheritedFrom": "whitesource-config@master"

Using values defined in the global configuration and overriding the scan settings parameters:

Code Block
"settingsInheritedFrom": "whitesource-config@master", 
"scanSettings": {
  "projectToken": "12345",
  "baseBranches": ["master","integration"]
}

No

N/A

...

Parameter 

Type

Description

Required 

Default

configMode

String

The configuration mode to be used for each scan. There are three options:

  • AUTO - Automatic mode. This will use the default WhiteSource configuration. 

  • LOCAL - Local mode. This will look for a local 'whitesource.config' file to be provided in the root folder of the current repository. The configuration file should be in the same format as the Unified Agent configuration file. NOTE: Not supported in the Global Configuration.

  • EXTERNAL - External mode. This will look for a configuration file specified according to the configExternalURL parameter. 

No

Auto

configExternalURL

String

The URL of the external configuration file (you can choose any filename). The configuration file content should be in the same format as the Unified Agent configuration file.

The following protocols are supported: 'ftp://', 'http://', 'https://'.

For example: 'https://mydomain.com/whitesource-settings/wss-unified-agent.config'

NOTE: This parameter is relevant only if configMode was set to EXTERNAL.

No

Empty

projectToken

String

Adds the ability to map a GitLab repository to a WhiteSource project. The parameter used needs to be the WhiteSource project token.

NOTE: Not supported in the Global Configuration.

No

Empty

baseBranches

Array

Adds the ability to specify one or more base branches for which scanning results will be sent to a new WhiteSource project.

Example usage: ["master", “integration"]

This will set both master and integration branches as base branches.

Note the following:

  • An Issue will only be created for the specified branch names.

  • Repositories which do not contain the baseBranches parameter will have issues generated for all branches.

  • For each specified branch, a WhiteSource project will be created. The name of the project will contain a suffix "_branchname". For example, MyApp_dev. This suffix will not apply to the default branch.

NOTE: This parameter is available only from version 20.7.1.

No

Empty 

In this case, the base branch only consists of the default branch.

enableLicenseViolations

Boolean

When enabled, a new WhiteSource License Check will be generated for each valid push.

NOTES:

  • This parameter is available only from version 20.11.2.

  • You must have it least one policy of match type By License Group defined with a Reject action in the WhiteSource UI.

  • The policy name in the WhiteSource UI must start with a “[License] “ prefix.
    For example, "[License] PolicyName".

No

false

...

Remediate Settings (remediateSettings)

Parameter 

Type

Description

Required 

Default

enableRenovate

Boolean

When enabled, Remediate will raise automated Merge Requests for outdated dependencies in addition to Merge Requests remediating vulnerable dependencies. Remediate will then perform all the functionality and support all the configuration options available in WhiteSource Renovate.

See Renovate configuration options for all configuration options.

Refer here for parameter usage.

No

false

transitiveRemediation

Boolean

Whether to enable transitive remediation for NPM repos.

When npm v6 (npm v7 is not currently supported) is used with a package-lock.json file, and vulnerabilities are found within transitive dependencies in the file, then in most cases Remediate is able to successfully remediate the vulnerability. Sometimes it may not be possible to successfully remediate because a parent dependency does not yet have a new release that allows the necessary fixed-in version of the transitive dependency.

No

false

Providing a Global Configuration File

...