Advanced Technical Information

Overview

This provides advanced technical information related to the repo integrations.

Package Manager Files that Can Trigger a Repository Scan

Adding/changing/deleting one of the files on the list below will automatically trigger a scan of your repository using the Mend Repository Integration.

• build.gradle

• build.gradle.kts

• gradle.lockfile

• gradle.properties

• settings.gradle

• cargo.toml

• dependencies.scala

• pom.xml

• setup.py

• requirements.txt

• Gemfile.lock

• package.json

• package-lock.json

• yarn.lock

• pnpm-lock.yaml

• bower.json

• go.mod

• Gopkg.lock

• Godeps.lock

• vendor.conf

• gogradle.lock

• glide.lock

• composer.json

• build.sbt

• packages.config

• packrat.lock

• paket.dependencies

• Pipfile

• pipfile.lock

• Podfile

• pyproject.toml

• libs.versions.toml

• poetry.lock

• pubspec.yaml

• setup.cfg

• environment.yml

• Any metafile with one of the following extensions: 

  • asp

  • aspx

  • config

  • csproj

  • do

  • htm

  • html

  • jsp

  • shtml

  • tf

  • xhtml

• Cargo.lock

Technical Information for Self-Hosted Integrations

Modifying the Scanner Dockerfile

The wss-scanner image Dockerfile is located in the wss-scanner\docker\ folder.
By default, the following package managers are installed:

• Maven (3.5.4)

• npm

• Bower

• Yarn

• Gradle

• Pip and Pip3 (Python)

If you would like to add support for additional package managers, uncomment the relevant lines in the Dockerfile. The following package managers are available as part of the commented lines in the Dockerfile:

• Mix (Elixir)

• Hex (Erlang)

• Go Modules, Dep, godep, VNDR, govendor, gopm, glide (Go)

• Cabal (Haskell)

• Bazel (Java)

• Paket, NuGet (.NET)

• Composer (PHP)

• Poetry (Python)

• Packrat (R)

• Bundler (Ruby)

• Cargo (Rust)

• SBT (Scala)

• Cocoapods (Swift)

Note: When using the wss-scanner image’s Dockerfilefull, all of the package managers listed above are uncommented by default and will be installed. The Dockerfilefull is located in the wss-scanner\docker\ folder.

If a package manager you would like to scan is not mentioned above, please contact us at: https://www.mend.io/contact-us/.

Python Support

If you want to specify the Python version for your repository, you can choose one of the following versions included in your scanner Dockerfile: 2.7.18, 3.6.15, 3.7.12, 3.8.12, 3.9.9, or 3.11. For this you will need to perform the following procedure:

1. Ensure the relevant Python version is uncommented in your scanner container’s Dockerfile.

2. Add or edit the .whitesource configuration file in your repository.

3. Use the configMode parameter and set it to either LOCAL or EXTERNAL.

4. Create a whitesource.config file and add the following:

   CODE

   python.invokePipAsModule=true
   python.path=python3.9
   python.installVirtualenv=true

Note:

• For python.path, use one of the following values: 2.7, 3.6, 3.7, 3.8, 3.9, or 3.11.

• Alternatively, you can apply this globally across your repositories by using the Global Repo Configuration repo-config.json file.

Enable git LFS in the Scanner

To enable git LFS, uncomment the last two lines of this section of the Dockerfile:

# install git lfs
#ARG GIT_LFS_VERSION=v3.5.1
#RUN install-tool git-lfs

Note that this feature will only work once you switch to ‘git’ as a cloning engine instead of ‘Jgit’. To do this, set WS_GIT_CONNECTOR=true (this parameter is documented here).

You can also refer the official page of the extension at https://git-lfs.com/.

Required Open Ports

The wss-scanner Docker Container

The wss-scanner Docker container communicates with the following components using the following ports:

• Mend SaaS API → Port 443

• Your repository platform’s git protocol → The default is port 9418

• Private/public package registries (npmjs/pypi/ruby gems, etc.) which use the standard ports

The wss-gls-app/wss-ghe-app/wss-bb-app Docker Container

The wss-app Docker container communicates with the following components using the following ports:

• Your repository platform instance API → Check the port number with your repository platform Admin.

• The Mend SaaS API → Port 443

• The wss-remediate server Docker container port as configured by the user → The default is 8080.

The wss-remediate Docker Container

The wss-remediate Docker container communicates with the following components using the following ports:

• Inbound:

  • Requests are received via a single port (default is 8080) from the wss-app Docker container

• Outbound:

  • Internally:

    • Your repository platform instance over https (default port is 443)

  • Externally:

    • Private/public package registries (npmjs/pypi/ruby gems, etc.) which use the standard ports

Repository Platform

Your repository platform instance requires the ability to communicate with the following components using the following ports:

• wss-<integration_type>-app Docker container → Recommended is 5678

• wss-remediate Docker container → Recommended is 8080

• wss-scanner Docker container → Recommended is 9393

NOTE: All port numbers on the Docker containers are the user’s choice

Enabling HTTPS Support for the Webhook Interceptor

The app container supports two ways of enabling HTTPS protocol for the webhook interceptor:

• Using Java KeyStore containing valid certificate and private key, as environment variables:

  • WS_KEYSTORE_FILE_PATH - path to the keystore file

  • WS_KEYSTORE_PASSWORD - password for the keystore file

• Directly provide a certificate and private key files, as environment variables:

  • WS_HTTPS_CERT_FILE_PATH - path to the certificate file

  • WS_HTTPS_KEY_FILE_PATH - path to the private key file

App Container Startup Check

Available from version 21.1.2 of the integration

Upon startup, the app container provides a clear indication of the connectivity status between itself and the remediate container, the repository platform (SCM) API, and the Mend application server. The startup check also validates the activation key provided in the initial configuration. If needed, error messages are displayed. Each check results in one of three status types, as listed here:

• SUCCESS

• FAILED

• SKIPPED

When all checks are finished, a summary table will be written to the log, for example:

Environmental Variables

To view the environmental variables and their configurations related to the Mend Repo Integrations, refer to the Environment Variables for Self-Hosted Integrations documentation.

Automate Secret Encryption for Private Registries

You can encrypt secrets from the CLI, using the curl, echo, jq, gpg, grep and tr CLI programs.
Here is an example:

curl https://app.renovatebot.com/renovate.pgp --output renovate.pgp
echo -n '{"o":"your-organization", "r":"your-repository (optional)", "v":"your-secret-value"}' | jq . -c | gpg --encrypt -a --recipient-file renovate.pgp | grep -v '^----' | tr -d '\n'

The above script uses:

• curl to download the Mend Renovate hosted app's public key

• echo to echo a JSON object into jq

• jq to validate the JSON and then compact it

• gpg to encrypt the contents

• grep and tr to extract the encrypted payload which we will use

The jq step is optional, you can leave it out if you wish. Its primary value is validating that the string you echo to gpg is valid JSON and compact.

Note: Encrypted secrets must have at least an org/group scope, and optionally a repository scope. This means that Renovate will check if a secret's scope matches the current repository before applying it, and warn/discard if there is a mismatch.

Encrypted secrets usually have a single organization. But you may encrypt a secret with more than one organization, for example, org1,org2. This way the secret can be used in both the org1 and org2 organizations.

For more information on how to use secrets for private packages, refer to the Private package support documentation.