...
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 Developer 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
Package Manager | Language | Extra Details |
---|---|---|
Maven | Java | N/A |
Gradle | Java | N/A |
Go Modules | Golang | Remediate will update both the |
npm/Yarn | JavaScript | 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. |
NuGet | .NET | Only SDK-style
To convert your .NET Framework .csproj into an SDK-style project, follow this guide. |
pip | Python | N/A |
pipenv | Python | N/A |
poetry | Python | N/A |
setuptools | Python | N/A |
Composer | PHP | N/A |
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:
...
Code Block | ||
---|---|---|
| ||
{ "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:
Code Block |
---|
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 |