...

WhiteSource Remediate 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.com, WhiteSource for GitHub Enterprise, WhiteSource for Bitbucket Server, and WhiteSource for GitLab. Providing 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. 

WhiteSource Remediate provides the following capabilities:

...

Supported Package Managers

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

...

WhiteSource Remediate can be configured to work with the integration activation key using either the prop.json configuration file or using environment variables.

NOTE: The environment variable takes precedence over an activation key value specified inside a prop.json file. 

Providing the Integration Activation Key in prop.json

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.

Proxy Support

WhiteSource Remediate can be configured to work with proxy servers using either the prop.json configuration file or using environment variables.

...

• 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.

Renovate is designed for users who aim to keep their dependencies up-to-date, primarily for the reasons of:

...

{
  "remediateSettings": {
    "enableRenovate": true,
    "prBodyDefinitions": {
      "Age": "![age](https://badges.renovateapi.com/packages/npm/{{replace '/' '%2f' depName}}/{{{toVersion}}}/age-slim)",
      "Adoption": "![adoption](https://badges.renovateapi.com/packages/npm/{{replace '/' '%2f' depName}}/{{{toVersion}}}/adoption-slim)",
      "Passing": "![passing](https://badges.renovateapi.com/packages/npm/{{replace '/' '%2f' depName}}/{{{toVersion}}}/compatibility-slim/{{{fromVersion}}})",
      "Confidence": "![confidence](https://badges.renovateapi.com/packages/npm/{{replace '/' '%2f' depName}}/{{{toVersion}}}/confidence-slim/{{{fromVersion}}})"
    },
    "packageRules": [
      {
        "datasources": [
          "maven", "npm", "pypi"
        ],
        "updateTypes": [
          "patch",
          "minor",
          "major"
        ],
        "prBodyColumns": [
          "Package",
          "Change",
          "Age",
          "Adoption",
          "Passing",
          "Confidence"
        ]
      }
    ]
  }
}

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:

remediate-server:
  image: wss-remediate
  restart: always
  ports:
    - '8080:8080'
  volumes:
    - './conf/:/etc/usr/local/whitesource/conf/'
  environment:
    REMEDIATE_SERVER_ONLY: 'true'
remediate-worker:
  image: wss-remediate
  scale: 2
  depends_on:
    - remediate-server
  restart: always
  volumes:
    - './conf/:/etc/usr/local/whitesource/conf/'
  environment:
    REMEDIATE_SERVER_URL: http://remediate-server:8080