Overview

This provides advanced technical information related to the repo integrations.

Supported Package Manager Dependency Files

• build.gradle

• build.gradle.kts

• cargo.toml

• dependencies.scala

• pom.xml

• setup.py

• requirements.txt

• Gemfile.lock

• package.json

• package-lock.json

• 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

• Podfile

• pyproject.toml

• poetry.lock

• pubspec.yaml

• yarn.lock

• Any metafile with one of the following extensions: 

  • asp

  • aspx

  • config

  • csproj

  • do

  • htm

  • html

  • jsp

  • shtml

  • tf

  • xhtml

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)

• Paket, NuGet (.NET)

• Composer (PHP)

• Poetry (Python)

• Packrat (R)

• Bundler (Ruby)

• Cargo (Rust)

• SBT (Scala)

• Cocoapods (Swift)

If a package manager you would like to scan is not mentioned above, please contact WhiteSource Support.

Required Open Ports

The wss-scanner Docker Container

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

• WhiteSource 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 WhiteSource 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:

    • WhiteSource SaaS API → Port 443.

    • 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

Other

Ports 9393 and 9494 are used for health checks, hence they should be accessible to any VM/server from which you would like to check the health of the containers.

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

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 WhiteSource 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

The old names are still supported for backward compatibility. If exist, the environment variables will take precedence over properties in the prop.json file.