Versions Compared


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



WhiteSource Remediate is a feature of WhiteSource's repository integrations, which automatically opens fix Pull Requests for vulnerable open-source components, upgrading them to the lowest non-vulnerable version. WhiteSource Remediate is part of WhiteSource for DevelopersDeveloper Integrations and integrated with WhiteSource for GitHub.comWhiteSource for GitHub EnterpriseWhiteSource for Bitbucket Server, and WhiteSource for GitLab. In additionProviding additional capabilities for project dependency health, Remediate is integrated with WhiteSource Renovate (see below for details). Renovate enables you to save time and reduce risk by automating dependency updates in software projects. 


NOTE: A fix Pull Request is only generated for security vulnerabilities discovered on your repo's default branch, and for direct dependencies onlybase branches, including transitive dependencies in npm.

Supported Package Managers

Package Manager


Extra Details







Go Modules


Remediate will update both the go.mod as well as go.sum files, as well as any vendored files found within a vendor/ directory.



WhiteSource Remediate always updates both the package file (e.g. package.json) as well as any lock file (e.g. yarn.lock) in the same commit/fix Pull Request.
If a developer subsequently updates either file on the default branch, causing a git conflict with any of Remediate's Pull Requests, then Remediate will update the fix Pull Request to resolve all conflicts while still remediating the vulnerability.



Only SDK-style .csproj files are currently supported. By default, this includes:

  • .NET Core 1.0 and above

  • .NET Standard class libraries

  • Any .csproj in the SDK-style syntax

To convert your .NET Framework .csproj into an SDK-style project, follow this guide.
















NOTE: In WhiteSource for GitLab, mirrored repositories are not supported.


  1. From the WhiteSource web application, click the Integrate tab.

  2. Expand the WhiteSource for Developers option.

  3. From within the relevant repo integration settings, click Manage Workflow Rules. The Workflow Rules page is displayed.

  4. Click Add Rule. The Add Rule dialog box is displayed.

    Image RemovedImage Added

  5. Select a Product and/or Project scope from the Scope area or leave at the default (applies to all of your WhiteSource Products and Projects).

  6. Select a rule type from the Type dropdown menu.

  7. Click OK to create the rule.

Once you set up a Workflow Rule, WhiteSource Remediate will start monitoring your selected repositories for vulnerable dependencies and generate corresponding fix Pull Requests.



of GitHub.


com Credentials


If you are running Remediate against already, or making use of WhiteSource for, then you don’t need to provision credentials explicitly.


You can provide the integration's activation key to the Remediate container using a prop.json file.

Providing the Integration Activation Key using


Environment Variables

You can provide the integration activation key by using the W4D_BOLT_OP_ACTIVATION_KEY environment variable inside the Remediate container.


WhiteSource Remediate also supports the industry convention of HTTP_PROXYHTTPS_PROXY and NO_PROXY. This provides more flexibility if you need to also configure any internal/private registries in the no proxy list so is the recommended configuration approach. Such variables will be passed transparently to child processes.

Automated Dependency Updates for Improved Dependency Health

Although remediating vulnerabilities should be the highest priority for dependency updating, it is recommended to adopt a proactive dependency update approach using Remediate’s “Renovate” capabilities.

WhiteSource’s Renovate capabilities bring automated dependency updates to WhiteSource’s repository integrations. By enabling Renovate, more than 50 package manager formats can be detected automatically and dependencies within updated, including numerous Infrastructure as Code managers such as Terraform and Ansible.

The key advantages of automating dependency updates are:

  • Vulnerability fixes are often discretely released days or weeks prior to public disclosure, and you may be lucky enough to frequently update using Renovate prior to disclosure and avoid a vulnerability notification altogether

  • Even if projects are not completely up-to-date, being reasonably up-to-date means that applying vulnerability remediations is much lower risk and therefore can be done more quickly, lowering the average time-to-resolution for CVEs

  • For highly nested dependencies, such as Containers and Infrastructure as Code where vulnerable components may be deeply transitive, staying up-to-date (e.g. with Docker base image updates) is one of the best ways to stay secure anyway

Integration with WhiteSource Renovate

WhiteSource Renovate functionality can be enabled in WhiteSource Remediate via an option in the .whitesource configuration file.

With Renovate functionality enabled, Remediate will then raise PRs/MRs not only for vulnerable dependencies but also for outdated dependencies too.


Code Block
  "remediateSettings": {
    "enableRenovate": true,
    "prBodyDefinitions": {
      "Age": "![age]({{replace '/' '%2f' depName}}/{{{toVersion}}}/age-slim)",
      "Adoption": "![adoption]({{replace '/' '%2f' depName}}/{{{toVersion}}}/adoption-slim)",
      "Passing": "![passing]({{replace '/' '%2f' depName}}/{{{toVersion}}}/compatibility-slim/{{{fromVersion}}})",
      "Confidence": "![confidence]({{replace '/' '%2f' depName}}/{{{toVersion}}}/confidence-slim/{{{fromVersion}}})"
    "packageRules": [
        "datasources": [
          "maven", "npm", "pypi"
        "updateTypes": [
        "prBodyColumns": [

Remediate Worker Horizontal Scalability

To scale Remediate to allow it to utilize additional containers, in order to process multiple repositories concurrently, you can enable Remediate Worker Horizontal Scalability. In this mode, the Remediate “worker” logic (which processes repositories) is separated from the Remediate “server” logic (scheduler, job queue and webhook handling) in a many-to-one relationship.

The same Remediate Docker image is used for both Server and Worker functionality, as they are differentiated/configured using environment variables.

If you have already been running Remediate, you can keep that existing node as the new “Remediate Server”. All that is needed is to pass it the environment variable REMEDIATE_SERVER_ONLY: 'true' and that will be enough for it to know it should be in server-only mode and not run any worker jobs itself. This container will still be the one that the W4D controller needs to reach, e.g. to pass on webhooks.

Next, you should configure one or more Remediate Worker containers. To do so, start up a Remediate image and configure the environment variable REMEDIATE_SERVER_URL to point to the above Remediate Server’s API.

Here is a simple example of two Worker containers and one Server container using Docker Compose syntax:

Code Block
  image: wss-remediate
  restart: always
    - '8080:8080'
    - './conf/:/etc/usr/local/whitesource/conf/'
  image: wss-remediate
  scale: 2
    - remediate-server
  restart: always
    - './conf/:/etc/usr/local/whitesource/conf/'
    REMEDIATE_SERVER_URL: http://remediate-server:8080