WhiteSource for GitHub Enterprise



これは制御リリースです。詳細については、support @ whitesourcesoftware.comにお問い合わせください

序章

WhiteSource for GitHub Enterpriseは、WhiteSourceアカウントの一部としてリポジトリをスキャンするGitHubEnterpriseアプリです。 ショーのGitHub Enterpriseリポジトリにおける高レベルのセキュリティの概要は、すべてのオープンソースコンポーネントとディスプレイこれらのコンポーネントのすべての脆弱性を検出することがGitHubのエンタープライズ内の統合された製品です。

脆弱で古いオープンソースコンポーネントに関する情報を提供し、スキャンされたリポジトリのGitHub EnterpriseIssuesタブで包括的な最新レポートを生成します。さらに、スキャンされたリポジトリをWhiteSourceポータルで表示できるようになります。

WhiteSource for GitHubEnterpriseはWhiteSourcefor 一部であり 、開発者統合が 含ま れ、自動修正プルリクエストとWhiteSource Remediateによる自動依存関係更新(WhiteSource Renovateの一部として)が 含まれます。

前提条件

WhiteSourceサーバーソフトウェアをインストールする前に、次の要件に対応する必要があります。

  • 動作中のWhiteSourceアプリケーションと管理者権限を持つユーザーへのアクセス。

  • 展開には、次の2つの環境が含まれます。

    • イメージが構築される環境を構築します。

    • イメージがデプロイされるデプロイメント環境。

構築環境

ビルド環境は、関連するWhiteSourceDockerイメージがデプロイされるデプロイメント環境と同じにすることができます。

ビルド環境には、次の要件があります。

ハードウェア要件

  • CPU:デュアルコア、2Ghz以上(IntelまたはAMD)

  • RAM: 16GB

  • ストレージ: 16 GB

環境要件

  • ビルド手順の全期間中のインターネット接続。

  • コンテナオーケストレーションプラットフォーム(Kubernetes、ECS、Rancherなど)を使用する場合は、ELK、Splunkなどのログコレクションが適切に配置されていることを確認してください。コンテナにオーケストレーションプラットフォームを使用していない場合、ログは指定されたフォルダに収集されます。 

  • 管理者権限を持つユーザー:オペレーティングシステムがWindowsの場合、管理者権限が必要です。オペレーティングシステムがLinuxの場合は、root権限が必要です。

  • Dockerサーバーバージョン18以降。次のように入力して、Dockerのバージョンを確認できます。

1 docker-バージョン
  • WhiteSourceが提供するソフトウェアとファイル:

    WhiteSource

    • tar.gzまたはzipファイルとして配信されるDockerディストリビューションアーティファクト(たとえば、agent-4-github-enterprise-19.4.2.tar.gz  またはagent-4-github-enterprise-19.4.2.zip)。

対象環境

関連するWhiteSourceDockerイメージがターゲット環境にインストールされます。この環境には、以下が必要です。

ハードウェア要件

  • CPU:デュアルコア、2Ghz以上(IntelまたはAMD)

  • RAM:16GB

  • ストレージ:16 GB

環境要件

  • 管理者権限を持つユーザー:オペレーティングシステムがWindowsの場合、管理者権限が必要です。オペレーティングシステムがLinuxの場合は、root権限が必要です。

  • Dockerサーバーバージョン18以降。次のように入力して、Dockerのバージョンを確認できます。

1 docker-バージョン20
  • ポート5678は常に開いている必要があります。このポートは、GitHub EnterpriseServerからWebhookを受信するために使用されます。

  • WhiteSource for GitHub Enterpriseの操作には、WhiteSourceアプリケーションへのアクセスが必要になる場合があります。

アプリへのアクセスは、Webブラウザまたはユーティリティ(cURL、wgetなど)を使用してHTTP GETリクエストを発行することで確認できます:
https:// <your-base-url> / healthCheck
https:// saasなど) .whitesourcesoftware.com / healthCheck

返されたステータスが200(OK)であることを確認することをお勧めします。
これは単なる検証URLです。アプリのサブドメインの下にあるすべてのパスとエンドポイントに対してアクセスが開かれている必要があります。

  • プロキシサーバーが利用可能な場合は、次のプロキシ設定を取得する必要があります。

    • URL

    • ポート番号

    • ユーザー名とパスワード(認証されたアクセス用)

  • 有効なSSL証明書とその証明書を含むKeyStore。

ビルドマシンのユーザーステップ

インストールの準備

Linuxの場合は「tar.gz」ファイル(「agent-4-github-enterprise- <version> .tar.gz」)をダウンロードするか、Windowsの場合は「zip」ファイル(「agent-4-github-enterprise- <version> .zip」)をダウンロードします。 ')

インストールと構成

Windowsでは、 「agent-4-github-enterprise- <version> .zip」を空のディレクトリに解凍します。 Linuxでは、「agent-4-github-enterprise <version> .tar.gz」を空のディレクトリに抽出します。  
抽出により、次のフォルダーが作成されます。

  • wss-configuration:UI構成ツールおよび関連する構成ファイルテンプレート

  • wss-deployment:デプロイメントテンプレート(たとえば、Helmチャートを使用して統合をデプロイする)

  • wss-ghe-app:WhiteSource GitHubEnterpriseサーバーアプリケーション

  • wss- remediate:WhiteSourceRemediateワーカー

  • wss-scanner:WhiteSource GitHubEnterpriseリポジトリスキャナー

  • build.sh/build.bat(Linux / Windows):関連するDockerイメージをビルドするビルドスクリプト。

スキャナーDockerfileの変更 

どのパッケージマネージャーがスキャナーイメージの一部であるか、およびパッケージマネージャーを追加する方法の詳細については、ここ を参照してください 。

Dockerイメージをビルドしてタグ付けする

Dockerイメージを構築する方法は3つあります。

wss-ghe-appwss-scanner、およびwss-remediateの合計3つのイメージが作成されます。

1.実行可能スクリプトファイルの使用

すべてのDockerイメージをビルドするための推奨される方法は、build.batまたはbuild.sh実行可能スクリプトファイル(Windows / Linux)を実行することです。
両方のファイルは、抽出されたagent-4-github-enterprise- <version> .zipまたはagent-4-github-enterprise- <version> .tar.gzファイルのルートにあり ます。

ウィンドウズ

  1. agent-4- github-enterprisezipファイルを抽出したメインフォルダーにあるbuild.batファイルを実行します。

  2. ビルドが成功したことを確認するには、docker imagesコマンドを実行し、wss-ghe-appwss-scannerおよびwss-remediateイメージが作成されたかどうかを確認し ます。

Linux

  1. 実行build.shを使用すると、抽出されたメインフォルダにあるファイルを、エージェント-4- githubのエンタープライズtar.gz形式のファイルを。

  2. ビルドが成功したことを確認するには、docker imagesコマンドを実行し、wss-ghe-appwss-scannerおよびwss-remediateイメージが作成されたかどうかを確認し ます。

2.手動でイメージを作成する

ビルドファイルの手順を手動で実行する場合は、次のコマンドを直接実行できます。

重要:ビルドファイルを既に実行している場合は、これらの手順をスキップして、ターゲットマシン:イメージの実行に進んでください。

1 2 3 4 5 6 7 8 docker build -t wss-ghe-app:<version> wss-ghe-app / docker docker build -t wss-scanner:<version> wss-scanner / docker docker build -t wss-remediate:<version> wss-remediate / docker # 例えば: docker build -t wss-ghe-app:19.5.2 wss-ghe-app / docker docker build -t wss-scanner:19.5.2 wss-scanner / docker docker build -t wss-remediate:19.5.2 wss-remediate / docker

:バージョン21.5.1以降、RemediateDockerfileはUbuntu18.04とUbuntu20.04の両方と互換性のあるイメージをサポートします。ベースイメージは、BASE_IMAGEビルド引数を使用して変更できます。例えば

1 docker build --build-arg BASE_IMAGE = ubuntu:18.04 -t wss-remediate:21.5.1 wss-remediate / docker

3.Dockerレジストリの使用

プライベートDockerレジストリを使用している場合は、次のコマンドを実行してイメージをレジストリにプッシュします。

1 2 3 4 5 6 7 8 docker push <registry> / wss-scanner:<version> docker push <registry> / wss-scanner:<version> docker push <registry> / wss-remediate:<version> # 例えば: docker push my-registry / wss-scanner:19.5.2 docker push my-registry / wss-scanner:19.5.2 docker push my-registry / wss-remediate:19.5.2

コマンドを実行すると、レジストリ内の画像を表示できるようになります。

WhiteSourceGitHubアプリを作成する

  1. GitHubエンタープライズインスタンスに移動し、[設定]> [組織]を選択し、開発者設定から[ GitHubアプリ]を選択します

  2. [新しいGitHubアプリ]ボタンをクリックします。

  3. GitHubEnterpriseのパスワードを入力します。

  4. [新しいGitHubアプリ登録]ページが表示されます。 

  5. 次のガイドラインに従ってフィールドに入力します。

    1. GitHubアプリ名:「WhiteSourceアプリ」。 :名前にアンダースコア(「__」)を含めることはできません。

    2. 説明: GitHubEnterpriseのWhiteSource

    3. ホームページのURL:https://www.whitesourcesoftware.com

    4. ユーザー認証コールバックURL:

    5. セットアップURL(オプション):

    6. Webhook URL: 有効なURLパターン。これは一時的な値であり、インストールプロセスの後の段階で変更されます。

    7. Webhookシークレット: シークレット値(文字列)を生成して入力し、この値をどこかにコピーしてください。後で必要になります。 

    8. 権限:
             注: 以下で指定されていない権限フィールドはそのままにしておく必要があります(「アクセスなし」)

      1. リポジトリ管理:読み取り専用

      2. チェック:読み取りと書き込み

      3. リポジトリの内容:読み取りと書き込み

      4. 展開:読み取り専用

      5. 問題:読み取りと書き込み

      6. リポジトリメタデータ:読み取り専用

      7. ページ:読み取りと書き込み

      8. プルリクエスト:読み取りと書き込み

      9. リポジトリWebhook:読み取り専用

      10. リポジトリプロジェクト:読み取りと書き込み

      11. セキュリティの脆弱性アラート:読み取り専用

      12. コミットステータス:読み取りと書き込み

      13. 組織のメンバー:読み取り専用

      14. 組織プロジェクト:読み取りと書き込み

      15. 組織のフック:読み取り専用

    9. イベントをサブスクライブする:次のイベントを選択します
      。実行
      iiを確認します。スイート
      iiiを確認してください。問題
      iv.メンバー
      v.メンバーシップ
      vi.組織
      vii.プルリクエスト
      viii.
      ixを押します。チーム
      x。チーム追加

    10. このGitHubアプリはどこにインストールできますか? すべてのGitHub組織がこのアプリをインストールできるように、[任意のアカウント]を選択することをお勧めします。または、自分の組織に限定することもできます。

  6. GitHubアプリ作成 ]ボタンをクリックします。 

  7. NS

  8. GitHubアプリを作成する

  9.  ボタン。 

  10. (オプション)GitHubアプリを編集し、アプリのロゴをアップロードします。

WhiteSourceの「統合」ページのフィールドに入力します

別のブラウザタブまたはウィンドウを開き、WhiteSourceにログインします

  1. WhiteSourceアプリケーションの「統合」ページに移動します。[WhiteSource for GitHub Enterprise]バーを展開して、次のフィールドを表示します。

    1. GitHub URL: GitHubEnterpriseインスタンスの宛先URL。例:https//GitHubEnterprisedev.com

    2. GitHub API URL:  GitHubURL値に「/ api / v3」を加えたもの-<GitHubURL> / api / v3

    3. GitHubアプリケーションID:  GitHub EnterpriseサーバーのUIから、[設定]> [組織の設定]> [GitHubApps]に移動します。GitHubAppsの横にある[編集]をクリックします。スクロールについてセクション。GitHub ID値をコピーしGitHubアプリケーションID入力フィールド値として貼り付けます。次のフィールド(Github Webhookシークレット)で必要になるため、このページは編集モードで開いたままにしておきます

    4. Github Webhookシークレット:GitHubアプリケーションのインストール手順の 一部として生成したWebhookシークレットを貼り付けます。

    5. GitHubのアプリケーション秘密鍵:ではプライベートキーセクション、クリックした秘密鍵を生成します。生成されたprivate_key.pem ファイルを保存します。このファイルを任意のエディターで開き、その内容をコピーします。内容をGitHubアプリケーションの秘密鍵入力フィールドに貼り付けます。注:キーは暗号化されており、その値はWhiteSourceに公開されません。

  2. [アクティベーションキーの取得]をクリックして、アクティベーションキーを生成します。この統合のために、WS プレフィックスを使用してWhiteSourceアプリケーション内に新しいサービスユーザーが作成され ます。  :このサービスユーザーを削除せず、このユーザーが管理者グループの一部であることを確認してください。 

  3. 生成されたアクティベーションキーをクリップボードにコピーします。次のセクションで使用する必要があります。

展開設定の構成

wss-configurationディレクトリからUI構成ツールを実行します

UI構成ツールを使用すると、特定の構成要件に従ってデプロイメントファイルを構成できます。 

  1. ChromeまたはFirefoxWebブラウザを介し てwss-configurationディレクトリ内にあるファイルindex.htmlを開きます。WhiteSource設定エディタの ページが表示されます。

  2. [ファイルの選択 ]ボタンをクリックし、wss-configuration / config / prop.jsonにあるファイルを選択して、テンプレートJSON構成ファイルをロードします 。[全般 ]タブがエディターに表示されます。

  3. [全般]タブをクリックして、前のセクションでコピーしたアクティベーションキーを入力します。

  4.  [プロキシ]タブを表示するには、[ホーム ]タブの[詳細プロパティ]チェックボックスをクリックします。必須ではないプロキシフィールド(ユーザー名やパスワードなど)は空白のままにする必要があります。

  5. [エクスポート]をクリックして、JSONファイルをprop.jsonという名前で保存します。このファイルは次のセクションで使用されます。

JSONファイルは、構成を保存し、特定のセクションの構成を組織内の適切な専門家に割り当てることができるようにするために編集を終了していなくても、いつでもエクスポートできます(たとえば、データソースセクションが割り当てられる場合があります)。組織のDBAに)。

構成ファイルをエクスポートするときは、ファイル名「prop.json」を付けることが重要です。

構成ファイルの属性の詳細

セクション

ラベル

名前

タイプ

必須

説明

サンプル値

セクション

ラベル

名前

タイプ

必須

説明

サンプル値

全般的

アクティベーションキー

Bolt.op.activation.key

ストリング

はい

WhiteSourceアプリケーションで生成されたアクティベーションキー



プロキシー

HTTPプロキシホスト

proxy.host

ホストアドレス

いいえ

HTTPプロキシホスト。無効にするには空白のままにします。デフォルト値:空



プロキシー

HTTPプロキシポート

プロキシポート

整数

いいえ

HTTPプロキシポート。無効にするには空白のままにします。デフォルト値:空



プロキシー

プロキシユーザー

proxy.user

ストリング

いいえ

プロキシユーザー名(該当する場合)

ユーザー

プロキシー

プロキシパスワード

proxy.password

ストリング

いいえ

プロキシパスワード(該当する場合)

abc123

高度

コントローラのURL

controller.url

ストリング

いいえ

デフォルト名(wss-ghe-app)が変更された場合に、アプリコンテナのURLを変更する機能。デフォルト値:http:// wss-ghe-app:5678

http:// wss-ghe-app:5678

問題

問題を作成する必要があります

Bolt4scm.create.issues

ブール値

いいえ

組織のすべてのリポジトリで問題の作成をグローバルに有効/無効にする機能。デフォルト値:true 
注:バージョン20.5.1.3からのみサポートされます)



問題

ビルドステータスを作成する必要があります

Bolt4scm.create.check.runs

ブール値

いいえ

グローバル組織のリポジトリのすべてにわたる/無効ビルドステータスを有効にする機能。デフォルト値:true 
注:バージョン20.5.1.3からのみサポートされます)



ターゲットマシン:コンテナを実行します

Dockerを使用したデプロイ

ターゲット環境で、ディレクトリ(たとえば、 '<path / to / config / dir>')を作成し、以前に構成エディターを使用して編集およびエクスポートした構成プロパティJSONファイル(prop.json)をそのディレクトリに追加します。
次に、ネットワークブリッジを作成し、DockerまたはKubernetesを使用して次のDockerコンテナを実行する必要があります。

ネットワークブリッジを作成します(すべてのコンテナーは同じネットワーク内で実行する必要があるため、これにより、異なるコンテナー間にプライベートネットワークが作成されます)。

1 docker network create -d bridge my_bridge

'wss-ghe-app'アプリコンテナを実行します。

1 2 3 4 docker run --name wss-ghe-app --network my_bridge -p 9494:9494 -p 5678:5678 -v <path / to / config / directory>:/ etc / usr / local / whitesource / conf wss-ghe-アプリ:<バージョン> # 例えば: docker run --name wss-ghe-app --network my_bridge -p 9494:9494 -p 5678:5678 -vc:/ tmp / ghe /:/ etc / usr / local / whitesource / conf / wss-ghe-app: 19.5.2

'wss-scanner'スキャナーコンテナを実行します。

1 2 3 4 docker run --name wss-scanner-ghe --restart = always --network my_bridge -p 9393:9393 -v <path / to / config / directory>:/ etc / usr / local / whitesource / conf / wss-scanner :<バージョン> # 例えば: docker run --name wss-scanner-ghe --restart = always --network my_bridge -p 9393:9393 -vc:/ tmp / ghe /:/ etc / usr / local / whitesource / conf / wss-scanner:19.5。 2

'wss-remediate'サーバーコンテナを実行します。

1 2 3 4 docker run --name remediate-server --network my_bridge -e LOG_LEVEL = debug -p 8080:8080 -v <path / to / config / directory> /prop.json:/etc/usr/local/whitesource/conf/prop .json -v / tmp:/ tmp wss-remediate:<バージョン> # 例えば: docker run --name remediate-server --network my_bridge -e LOG_LEVEL = debug -p 8080:8080 -vc:/tmp/ghe/prop.json:/etc/usr/local/whitesource/conf/prop.json -v / tmp:/ tmp wss-remediate:19.5.2



修復サーバーポートの変更

ポート8080が使用できない場合は、「dockerrun」コマンドの最初のポートエントリのみを変更することで、別のポートを使用できます。例えば:

docker run --name remediate-server --network my_bridge -e LOG_LEVEL = debug -p 8082:8080 -vc:/tmp/ghe/prop.json:/etc/usr/local/whitesource/conf/prop.json -v / tmp:/ tmp wss-remediate:19.5.2

ヘルムチャートを使用した展開

wss-deploymentフォルダーは、次の構造で構成されています。

    • 構成

    • テンプレート

      • config.yaml

      • wssScmIntegration.yaml

    • Chart.yaml

    • values.yaml

helmフォルダーをwss-deploymentからターゲット環境にコピーします。内部指揮/コンフィグフォルダ、構成プロパティJSONファイル(追加prop.jsonをあなたは以前に編集して設定エディタを使用してエクスポートすることを)。

Chart.yaml

このファイルには、チャートに関する情報が含まれています。

注:このファイルは編集しないでください。

Values.yaml

このファイルは、WhiteSource統合イメージの名前とバージョンを表します。

1 2 3 4 5 6 7 8 9 10 11 wsscanner: image: {image} version: {version} wsscontroller: image: {image} version: {version} wssremediate: image: {image} version: {version}

各イメージ宣言(wssscanner、wsscontroller、wssremediate)について、{image}と{version}を実際にビルドされたイメージの名前とバージョンに置き換えます。  注: wsscontrollerの場合は、wss-ghe-appイメージの名前とバージョンを使用します。

Dockerリポジトリ認証が必要な場合は、オプションのパラメーターimagePullSecretsをこのファイルに追加できます。

configs / prop.json

ではヘルムフォルダ、という名前の新しいフォルダを作成コンフィグを(し、それに構成プロパティJSONファイルを追加prop.jsonあなたは以前に編集し、設定エディタを使用してエクスポートすることを)。

templates / config.yaml

これは、configs /prop.json ファイルを指す構成ファイルです。

注:このファイルは編集しないでください。

テンプレート/wssScmIntegration.yaml

これは、統合をデプロイするためのすべてのパラメーターを含む構成ファイルです。

注: このファイルには、サービスを区切る3つのダッシュ( "------")があります。それらを削除しないでください。

統合によってWebhookURLにパブリックにアクセスできるようにするには、ロードバランサーサービスをファイルに追加する必要があります。このようなサービスの例を以下に示します。

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 apiVersion: v1 kind: Service metadata: name: lb1 namespace: acme annotations: external-dns.alpha.kubernetes.io/hostname: helm.acme.io service.beta.kubernetes.io/aws-load-balancer-backend-protocol: http service.beta.kubernetes.io/aws-load-balancer-ssl-ports: "443" service.beta.kubernetes.io/aws-load-balancer-ssl-negotiation-policy: "ELBSecurityPolicy-TLS-1-2-2017-01" service.beta.kubernetes.io/aws-load-balancer-ssl-cert: arn:aws:acm:us-east-7:834027593108:certificate/4720e07a-a231-4fd5-9c4a-12ab1450567d spec: type: LoadBalancer ports: - port: 443 name: https targetPort: 5678 selector: app: wss-controller

GitHubアプリのWebhookURLの提供

この段階で、一時的なWebhookURLを永続的なWebhookURLに置き換える必要があります。 

  1. アプリの設定を編集します。

    1. 次の形式でWebhookURLを入力します:
      http:// <docker-wss-ghe-app-destinationURL>:5678 / payload。

    2. [変更を保存]ボタンをクリックします。

アカウントとリポジトリを選択します

  1. 作成したアプリの「パブリックリンク」をコピーして移動し、[構成]ボタンをクリックします。

  2. スキャンするアカウントを選択します。

  3. 複数のリポジトリを統合していて、グローバル構成を適用する場合は、この手順を続行する前に、ここを参照してください。

  4. 選択した各アカウントでスキャンするリポジトリを選択します。次のいずれかのオプションを選択します。

    1. すべてのリポジトリ(デフォルト):アカウントのすべてのリポジトリをスキャンするオプション。

    2. 選択したリポジトリのみ:スキャンする特定のリポジトリを選択します。

  5. [保存]をクリックしますグローバル構成で特に指定されていない限り、選択したリポジトリに対してオンボーディングプルリクエストが作成されます。このリクエストには、プルリクエストをマージする前にカスタマイズできるWhiteSource構成ファイル(.whitesource)が含まれています。プルリクエストがマージされると、WhiteSourceスキャンが開始されます。

.whitesourceファイル

WhiteSource構成ファイル(.whitesource)は、スキャンが有効になっている各リポジトリーに追加されるJSONファイルです。WhiteSourceスキャン用の設定可能なパラメータを提供します。.whitesourceファイルは、リポジトリのデフォルトブランチにのみ追加されます(変更されない限り、マスターブランチです)。

.whitesourceファイル
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 { "scanSettings": { "configMode": "AUTO", "configExternalURL": "" "projectToken": "", "baseBranches": [] }, "checkRunSettings": { "displayMode": "diff", "vulnerableCheckRunConclusionLevel": "failure" }, "issueSettings": { "minSeverityLevel": "LOW" } }

パラメーター

全体設定

パラメータ 

タイプ

説明

必須 

ディフォルト

パラメータ 

タイプ

説明

必須 

ディフォルト

settingsAliExpressFrom

ストリング

ときにグローバルコンフィギュレーションが有効になっている、このパラメータはの場所を指定しますwhitesource-コンフィグそれはその設定を継承元となるリポジトリを。これには、GitHubユーザー名、リポジトリ名、およびrepo-config.jsonファイルの場所のブランチ(オプション)が含まれている必要があります。デフォルトのブランチは「master」ですが、whitesource-configリポジトリ内のrepo-config.jsonファイルの場所に応じて変更できます。 

注:このパラメーターの後にこれらを追加することにより、特定のリポジトリーにのみ関連する特定のパラメーターをオーバーライドできます。

例:

グローバル構成で定義された値のみを使用します。

1 "settingsAliExpressFrom": "whitesource / whitesource-config @ master"

グローバル構成で定義された値を使用し、スキャン設定パラメーターをオーバーライドします。

1 2 3 4 5 "settingsAliExpressFrom": "whitesource / whitesource-config @ master"、 "scanSettings":{ "projectToken": "12345"、 "baseBranches":["master"、 "integration"] }



番号

該当なし

スキャン設定(scanSettings)

パラメータ 

タイプ

説明

必須 

ディフォルト

パラメータ 

タイプ

説明

必須 

ディフォルト

configMode

ストリング

各スキャンに使用される構成モード。3つのオプションがあります。

  • AUTO-自動モード。これは、デフォルトのWhiteSource構成を使用します。 

  • LOCAL-ローカルモード。これにより、現在のリポジトリのルートフォルダにあるローカルの「whitesource.config」ファイルが検索されます。設定ファイルは、UnifiedAgent設定ファイルと同じ形式である必要があります注:グローバル構成ではサポートされていません。

  • EXTERNAL-外部モード。これにより、configExternalURL パラメーターに従って指定された構成ファイルが検索されます。 

番号

自動

configExternalURL

ストリング

外部構成ファイルのURL(任意のファイル名を選択できます)。設定ファイルの内容は、UnifiedAgent設定ファイルと同じ形式である必要があります

次のプロトコルがサポートされています: 'ftp://'、 ' http://'、 ' https://'。

次に例を示します。'https//mydomain.com/whitesource-settings/wss-unified-agent.config '

:このパラメーターは、configModeEXTERNALに設定されている場合にのみ関係 します

番号

projectToken

ストリング

GitHubリポジトリをWhiteSourceプロジェクトにマッピングする機能を追加します。使用するパラメーターは、WhiteSourceプロジェクトトークンである必要があります。

注:グローバル構成ではサポートされていません。

番号

baseBranches

配列

スキャン結果が新しいWhiteSourceプロジェクトに送信される1つ以上のベースブランチを指定する機能を追加します。

使用例:  ["master"、 "integration"]

これにより、マスターブランチと統合ブランチの両方がベースブランチとして設定されます。

次の点に注意してください。

  • 課題は、指定されたブランチ名に対してのみ作成されます。

  • baseBranches パラメーターを含まないリポジトリーでは 、すべてのブランチで問題が発生します。

  • 指定されたブランチごとに、WhiteSourceプロジェクトが作成されます。プロジェクトの名前には、接尾辞「_branchname」が含まれます。たとえば、  MyApp_dev。このサフィックスは、デフォルトのブランチには適用されません。

注: このパラメーターは、バージョン20.7.1からのみ使用できます。

番号

この場合、基本ブランチはデフォルトブランチのみで構成されます。

enableLicenseViolations

ブール値

有効に すると、有効なプッシュごとに新しい WhiteSourceライセンスチェックが生成されます。

ノート:

  • このパラメーターは、バージョン20.11.2からのみ使用できます。

  •  WhiteSourceUIの拒否アクションで定義されたライセンスグループ別の 一致タイプのポリシーが少なくとも1つ必要 です。

  • WhiteSource UIのポリシー名は、「[License] 」プレフィックスで始まる必要があります。たとえば、「[License] PolicyName」です。

番号

NS

enableIaC

ブール値

有効に すると、有効なプッシュごとに新しい WhiteSourceIaCチェックが生成されます。これにより、クラウドインフラストラクチャの構成がスキャンされ、展開される前に構成の誤りが検出され、問題の作成を通じてこれらの構成が警告されます。

ノート:

  • 現在、Terraform構成ファイルのみがサポートされています。

  • 有効にすると、有効なプッシュが行われるたびに、ブランチ(ws-iac-scan-results / {whitesource_scan_token})が一時的に作成され、スキャンの完了後に削除されます。

番号

NS

実行設定の確認(checkRunSettings)

パラメータ 

タイプ

説明

必須 

ディフォルト

パラメータ 

タイプ

説明

必須 

ディフォルト

ディスプレイモード

ストリング

非ベースブランチで実行されたスキャンのWhiteSourceセキュリティ情報を表示する方法:

  • diffに設定されている場合-現在のコミットとそのベースブランチコミットの間で検出された脆弱性の差分のみが表示されます。注:この値は、baseBranches構成を使用している場合にのみサポートされます。

  • ベースラインに設定されている場合-リポジトリインベントリ全体で検出されたすべての脆弱性の概要が表示されます。

番号

差分

脆弱なチェック実行ConclusionLevel

ストリング

このアプリは、GitHub Checks APIを利用して、任意のリポジトリブランチでコミットとプルリクエストのチェックを提供します。このパラメータは、WhiteSourceセキュリティチェックが完了したときの結論ステータスを定義します。 

パラメータが「success」に設定されている場合、WhiteSourceセキュリティチェックの終了ステータスは、チェックが失敗した場合でも常に「Success」になります。このようにして、WhiteSource Security Checkがセキュリティの脆弱性を検出した場合でも、リポジトリメンバーはプルリクエストをマージできます。

パラメータが「failure」(デフォルト)に設定されている場合、WhiteSource Security Checkがセキュリティの脆弱性を検出した場合、またはスキャン中にエラーが発生した場合、WhiteSource SecurityCheckの終了ステータスは「Failure」になります。この構成が定義され、 ブランチ保護ルールが追加されると、プル要求を承認するためのポリシーが適用されます。この設定では、リポジトリの管理者のみが、「失敗」ステータスの1つ以上のチェックを含むプルリクエストのマージを承認できます。 

マージポリシーの開始も参照してください 。

番号

失敗

licenseCheckRunConclusionLevel

ストリング

このアプリは、GitHub Checks APIを利用して、任意のリポジトリブランチでコミットとプルリクエストのチェックを提供します。このパラメータは、WhiteSourceライセンスチェックが完了したときの結論ステータスを定義します。 

パラメータが「成功」に設定されている場合、ホワイトソースライセンスチェックの終了ステータスは、チェックが失敗した場合でも常に「成功」​​になります。このようにして、WhiteSource License Checkがライセンスポリシー違反を検出した場合でも、リポジトリメンバーはプルリクエストをマージできます。

パラメータが「failure」(デフォルト)に設定されている場合、WhiteSource License Checkがライセンスポリシー違反を検出した場合、またはスキャン中にエラーが発生した場合、WhiteSource LicenseCheckの終了ステータスは「Failure」になります。この構成が定義され、 ブランチ保護ルールが追加されると、プル要求を承認するためのポリシーが適用されます。この設定では、リポジトリの管理者のみが、「失敗」ステータスの1つ以上のチェックを含むプルリクエストのマージを承認できます。

マージポリシーの開始も参照してください 。

番号

失敗

showWsInfo

ブール値

WhiteSource Check Run内(スキャントークンの後)にプロジェクトトークンなどの追加のWhiteSource情報を表示するかどうか。

WhiteSource情報は、コミットがベースブランチから発信された場合にのみ表示されます。
コミットが複数のブランチに存在する場合、表示されるWhiteSource情報は、元のベースブランチ(つまり、baseBranches パラメーターが定義された場所)のみを表し ます。

このパラメーターを有効にすると、次の非表示のJSONオブジェクトもCheckRun内に追加されます。



1 <!-<INFO> {"projectToken": "8cd2d2a8651145c087609e0a43f783e95f7008cb908541498348fed529572e01"} </ INFO>->



注:将来、追加のWhiteSourceデータがJSONオブジェクト内に追加される可能性があります。

番号

NS

発行設定(issueSettings)

パラメータ 

タイプ

説明

必須 

ディフォルト

パラメータ 

タイプ

説明

必須 

ディフォルト

minSeverityLevel

ストリング

検出された脆弱性で特定の重大度レベルが利用可能な場合にのみ、ユーザーが新しいGitHub課題を開くかどうかを決定できるようにします。

minSeverityLevelで使用可能な値:

  • NONE -いいえ、GitHubの問題は発生しません。

  • LOW-低/中/高の脆弱性が見つかった場合、GitHubの問題が発生します。

  • MEDIUM-中/高の脆弱性が見つかった場合、GitHubの問題が発生します。

  • HIGH-高い脆弱性が見つかった場合、GitHubの問題が発生します。

注: WhiteSourceセキュリティチェックの概要もこのパラメーターの影響を受けます。

番号

低い

displayLicenseViolations

ブール値

検出されたライセンスポリシー違反ごとに問題を生成するかどうか。

:このパラメータが関連している場合のみ enableLicenseViolations  (scanSettings)  I秒セット 真。

番号

NS

(のみ の場合 enableLicenseViolations  (scanSettings)  I秒セット 

修正設定(remediateSettings)

パラメータ 

タイプ

説明

必須 

ディフォルト

パラメータ 

タイプ

説明

必須 

ディフォルト

enableRenovate

ブール値

有効にすると、Remediateは、脆弱な依存関係を修正するプルリクエストに加えて、古い依存関係の自動プルリクエストを生成します。その後、Remediateはすべての機能を実行し、WhiteSourceRenovateで使用可能なすべての構成オプションをサポートします。

すべての構成オプションについては、構成オプションの更新を参照してください。

パラメータの使用法については、こちらを参照してください。

番号

NS

一時的な修復

ブール値

NPMリポジトリの推移的な修復を有効にするかどうか。

npm v6(npm v7は現在サポートされていません)がpackage-lock.jsonファイルで使用され、ファイル内の推移的な依存関係内に脆弱性が見つかった場合、ほとんどの場合、Remediateは脆弱性を正常に修正できます。親の依存関係には、推移的な依存関係の必要な固定バージョンを許可する新しいリリースがまだないため、正常に修正できない場合があります。

番号

NS

プライベートレジストリ設定(hostRules)

パラメータ 

タイプ

説明

必須 

ディフォルト

パラメータ 

タイプ

説明

必須 

ディフォルト

matchHost

string

スキャン中に資格情報が適用される場所を定義します。

ホスト内のネストされたパスにのみクレデンシャルを適用する場合はmatchHost 、ベースURLとして記述 します。
例:  https://registry.company.com/nested/path/

同じ資格情報がサブドメインではなくホスト上のすべてのパスに適用される場合は、のmatchHost ようなプロトコルで構成 します https://registry.company.com

最後に、ドメイン内のすべてのホストにクレデンシャルを適用するにmatchHost は、https:// プレフィックスのない値を使用し ます 。たとえば、 company.com または registry.company.comのなホストに適用されます beta.registry.company.com

番号

空の

hostType

string

プライベートレジストリの種類。サポートされている値:npm,maven,gradle,pypi,go

番号

空の

ユーザー名

string

資格情報がユーザー名とパスワードで構成されている場合に使用されます。

番号

空の

パスワード

string

string

クレデンシャルがユーザー名とパスワードで構成されている場合に使用されますこの命令で暗号化する必要があります。

matchHostパラメータで設定されたホストへの資格情報として適用される暗号化されたシークレット。パラメータ内に含める必要がありencryptedます:

コードブロック

1 2 3 "encrypted": { "password": "3f832f2983yf89hsd98ahadsjfasdfjaslf............" }

番号

空の

トークン

string

クレデンシャルがユーザー名とパスワードで構成されている場合に使用されますこの命令で暗号化する必要があります。

matchHostパラメータで設定されたホストへの資格情報として適用される暗号化されたシークレット。パラメータ内に含める必要がありencryptedます:

コードブロック

1 2 3 "encrypted": { "token": "3f832f2983yf89hsd98ahadsjfasdfjaslf............" }

番号

空の

グローバルな.whitesource構成ファイルの提供

注:バージョン20.5.1.3からのみサポートされます

カスタム.whitesource構成ファイルをwss-ghe-appコンテナーの一部として提供して、組織のすべてのリポジトリーにグローバルに適用することができます。そうすることで、新しく選択されたリポジトリのすべてのオンボーディングプルリクエストにファイルが適用されます。 この変更の前にすでに選択およびアクティブ化されているリポジトリは、このグローバル構成の影響を受けません。新しくオンボーディングされたリポジトリのみが影響を受けます。 

このグローバルな変更を適用するには、次のようにします。

  1. wss-ghe-appコンテナを停止し ます。

  2. では 、「WSS-GHEアプリ/ confに」フォルダの追加、 カスタム(prop.jsonファイルが置かれている)「.whitesource」ファイルを。

  3. wss-ghe-appコンテナを起動し ます。 

構成エラーの問題

構成エラーの問題を作成して実行を確認することにより、スキャンに影響を与える構成エラーについてユーザーに警告します。このようなエラーが発生した場合、次のことが発生します。

  1. ワークフローを停止します。スキャンまたはWhiteSourceセキュリティチェックの実行を作成しないでください。

  2. 「構成に失敗しました」チェック実行を作成します。

  3. 解析に失敗した構成ファイルごとに、「必要なアクション:WhiteSource構成ファイルの修正-{fileName}」というタイトルの新しいタイプの問題を作成します。エラーの原因がrepo-config.jsonファイルまたはglobal-config.jsonファイルの場合、問題はwhitesource-configリポジトリに作成されます。

処理されたエラー:

  • 構成ファイルの解析中にエラーが発生しました(.whitesource / repo-config.json / global-config.json json)

  • 継承構成にリポジトリやブランチがありません

スキャンの開始

WhiteSourceスキャンは、有効なGitHubプッシュ コマンドを介して開始されます  。有効な プッシュコマンド は、次の要件の少なくとも1つを満たしています。

  • pushコマンドのコミットの1つで、  WhiteSourceでサポートされている拡張子を持つソースファイルが追加/削除さ れました。 特定の言語とその拡張機能がサポートされているかどうかを確認するには、WhiteSource言語のページを参照してください 。 

  •  pushコマンドのコミットの1つに、パッケージマネージャーの依存関係ファイルの追加/変更が含まれますサポートされている依存関係ファイルの
    リストを参照して、依存関係ファイルがサポートされているかどうかを確認してください。

プッシュコマンド は複数のコミットで構成されている場合があります。

在庫ポストスキャン

WhiteSourceは継続的に新しい脆弱性を調査し、これらの調査結果で脆弱性データベースを更新します。これらの新たに発見された脆弱性がプロジェクトにできるだけ早く反映されるように、WhiteSourceは01:00 UTCにすべての統合プロジェクトのポストスキャンプロセスを開始し、過去24時間にデータベースに追加された脆弱性の新しい問題を開きます。 。

これは自動化された手順であり、ユーザーによるアクションは必要ありません。

スキャンの詳細の表示

結果は次の場所で表示できます。

  • 問題のGitHubプロジェクト内のタブ。

  • GitHubプロジェクトの[コミット]タブ内のWhiteSourceセキュリティ/ライセンス/ IaCチェック。

  • WhiteSourceUI。

  • 電子メール通知を介して。

[問題]タブの表示

Webブラウザを介してプルリクエストまたはプッシュコマンドを実行している場合は、Webブラウザを更新して、WhiteSourceによって生成された問題を表示します。 :有効なプッシュコマンドが開始された後、問題がスキャンされて表示されるまでに数分かかる場合があります。

Issues  ]タブには、WhiteSourceIntegrationが赤いセキュリティ脆弱性 ラベルで検出したすべての問題が表示されます。この独自のラベルは、WhiteSourceによってセキュリティの脆弱性が検出されたことを示しています。 

ワークフローの一部として、特定の問題に関連するラベルを追加し、解決された問題を閉じるオプションがあります。

手動で閉じられた問題は、ラベルや名前がGitHub APIを介して手動で変更または変更されていない限り、今後のWhiteSourceスキャン中に再度開かれることはありません。

問題の詳細の表示

詳細については、こちらをご覧ください。

WhiteSourceセキュリティチェックの表示

ステータスチェックインジケータは 、 [コード]タブの[コミット]サブタブにヘッドコミットごとに表示されます。特定のインジケータをクリックすると、ステータスの詳細を表示するポップアップウィンドウが開きます。

ポップアップウィンドウの[詳細]リンクをクリックすると、選択したヘッドコミットの[WhiteSourceセキュリティチェック]ページが表示されます。このページには、セキュリティレポートとともにヘッドコミットの終了ステータスが含まれています。

セキュリティレポートには、重大度とCVSSスコアに従って降順で検出されたすべての脆弱性が表示されます。脆弱性ごとに次の情報が表示されます。

  • CVE: 脆弱性に関連するCVEページへのリンク。折りたたみ可能な形式で表示されます(脆弱性の詳細については、矢印をクリックして展開/折りたたみしてください)。

  • 重大度:重大度の全体的なスコア(高、中、低)。

  • CVSSスコア

  • 脆弱なライブラリ

  • 推奨される修正 

  • 問題-WhiteSourceによって生成された関連する問題へのリンク(利用可能な場合)

指標の種類

次のChecksAPIステータスインジケーターは、ヘッドコミットに関するフィードバックとして利用できます。

  • キュー: スキャンは開始されておらず、開始するようにスケジュールされています。

    • 進行中: スキャンが進行中です。

    • 完了: スキャンが完了し、次のいずれかの結論が出されました。

      • 成功: パラメータ「vulnerable.check.run.conclusion.level」が「success」に設定されている場合、ヘッドコミットのステータスは常に成功です。コミットが失敗した場合でも、「Success」ステータスが表示されます。

      • 失敗: 完了したすべてのスキャンのデフォルト。パラメータ「vulnerable.check.run.conclusion.level」が「failure」(デフォルト)に設定されている場合、「failed」ヘッドコミットのステータスは「failure」であり、失敗したヘッドを含むプルリクエストのマージを承認するためのポリシーリポジトリ内の別のブランチとのコミットが実施されます。「失敗」ステータスは、セキュリティの脆弱性またはスキャン中に発生したエラーが原因で発生する可能性があることに注意してください。

      • ニュートラル: プッシュコマンドが無効な場合に結論が出ます。

チェックステータスインジケータのサンプル 

キューに入れられました

以下は、「キューに入れられた」ステータスのサンプルです。これは、セキュリティチェックがヘッドコミットの脆弱性のスキャンを開始しようとしていることを示しています。

進行中

以下は、「進行中」ステータスのサンプルです。これは、セキュリティチェックが現在ヘッドコミットをスキャンしていることを示しています。

成功の結論で完了

このステータスは、次の2つのシナリオで表示できます。

  1. パラメータ「vulnerable.check.run.conclusion.level」が「success」または「failure」に設定され、「success」ステータスがスキャンに提供されている場合、脆弱性は検出されず、スキャン中にエラーは発生しませんでした。このヘッドコミット。この場合、リポジトリ内の別のブランチへのこのコミットを含むプルリクエストのマージは自動的に承認されます。 




  2. パラメータ「vulnerable.check.run.conclusion.level」が「success」に設定されている場合。この構成では、ヘッドコミットのスキャンの「失敗」ステータスでさえ「成功」に変換されます。この場合、このヘッドコミットを含むプルリクエストのリポジトリ内の別のブランチへのマージは自動的に承認されます。 

    次のスクリーンショットは、パラメータ「vulnerable.check.run.conclusion.level」が「success」に設定されているため、スキャン中に発生したエラーを含むコミットの「success」インジケータを示しています。この場合、このヘッドコミットを含むプルリクエストのリポジトリ内の別のブランチへのマージは自動的に承認されます。 

失敗の結論で完了

「失敗」ステータスを表示します。この場合、リポジトリの管理者のみが、このヘッドコミットを含むプルリクエストをリポジトリ内の別のブランチにマージすることを承認できるため、自動的にマージされることはありません。



次のスクリーンショットは、「失敗」ポリシーが適用され、そのヘッドコミットの1つ以上が「失敗」ステータスになっている場合のプルリクエストページの表示のサンプルです。リポジトリの管理者のみが、プルリクエストと「失敗」ステータスのマージを承認できます。



中立的な 結論で完了

中立的な結論は、次のシナリオで発生します。

  • pushコマンドが無効でした。 有効なコマンドの詳細については、「スキャン開始」セクションを参照してください 。

WhiteSourceライセンスチェックの表示

コミットタブあなたはステータスと各スキャンの結果を表示することができます。ビルドページを表示するには、特定のビルドアイコンをクリックします。

指標の種類

次のコミットステータスインジケータは、ヘッドコミットに関するフィードバックとして利用できます。

  • 成功: ライセンスポリシー違反は検出されませんでした。 

  • 失敗: WhiteSourceスキャン中に1つ以上のライセンスポリシー違反が検出されました 

サポートされている構成ファイル

Terraform、CloudFormation、Kubernetes、ARMテンプレート、サーバーレス、Helm

WhiteSourceIaCチェックの表示

ではコード>コミット ページあなたは、ステータスと各スキャンの結果を表示することができます。WhiteSourceチェックを表示するには、特定のチェックアイコンをクリックします。

指標の種類

次のコミットステータスインジケータは、ヘッドコミットに関するフィードバックとして利用できます。

  • 成功: ライセンスポリシー違反は検出されませんでした。 

  • 失敗: WhiteSourceスキャン中に1つ以上のライセンスポリシー違反が検出されました。

WhiteSourceUIでの詳細の表示

  • WhiteSource UIでは、プロジェクトトークンを使用して.whitesourceファイルで特に指定されていない限り、WhiteSourceプロジェクトの名前は対応するGitHubリポジトリと同じで、プレフィックスは「GH_」になります。

  • GitHubリポジトリがGitHub組織の下にある場合、WhiteSource製品の名前は、「GH_」プレフィックスが前に付いたGitHub組織の名前と同じになります。それ以外の場合、名前は「GH_」が前に付いたGitHubユーザー名になります。

電子メール通知

電子メール通知は、GitHubエンタープライズアカウントにメールサーバーを定義した場合にのみ送信されます。

WhiteSourceスキャンが実行された後、生成された問題ごとに個別の電子メールメッセージが送信され、検出された脆弱性またはライセンスポリシー違反に関する情報が記載されます。

:電子メールメッセージの情報は、 [問題]タブに表示される情報と同じです。

APIを介したスキャン統計へのアクセス

詳細については、こちらをご覧ください。

ヘルスチェックAPI

詳細については、こちらをご覧ください。

マージポリシーの開始

概要

マージポリシーは、アプリとGitHub ChecksAPIの統合を利用します。これにより、リポジトリの管理者は、プルリクエストと「失敗」コミットステータスのリポジトリ内のターゲットブランチへのマージを承認できます。 
Checks APIの詳細について は、関連するGitHub ChecksAPIの紹介ページを参照してください

注: この統合は、同じリポジトリ内のブランチから作成された、または別のリポジトリから発信されたPRのマージポリシーをサポートします。

ブランチ保護ルールの追加 

WhiteSourceセキュリティチェックの結論に基づいてマージポリシーを有効にするには、最初にブランチ保護のために次のGitHubルールを追加する必要があります。

  1. リポジトリの「設定」→「ブランチ」に移動します。

  2. [ルールの追加]ボタンをクリックします。

  3. ルールを特定のブランチに適用するか、「*」を入力してすべてのブランチにルールを適用します。

  4. 次のチェックボックスを選択します。

    1. 「マージする前にステータスチェックに合格する必要があります」。

    2. この設定を表示できない場合は、「。whitesource」ファイルを変更して、コミットを実行してください。スキャンが完了するのを待ってから、この設定が表示されるまでGitHub設定ページを更新します。

最新のDockerイメージへのアップグレード

  1. WhiteSourceSupportからGitHubEnterpriseバージョンの最新のWhiteSourceを入手してください。

  2. 新しいバージョンからこれらの3つのDockerイメージをビルドします-ここを参照してください

    • wss-ghe-app

    • wss-スキャナー

    • 修復サーバー

  3. 以前のバージョンから現在実行中のDockerコンテナを停止します。

    1 docker stop <wss-ghe-app> <wss-scanner> <remediate-server>
  4. 以前のバージョンからDockerコンテナを削除します。

    1 docker rm <wss-ghe-app> <wss-scanner> <remediate-server>
  5. 既存のprop.jsonファイル(プロパティ "bolt.op.activation.key"に関連付けられているpropertyValue)からアクティベーションキーを取得し、クリップボードにコピーします。

  6. ここの手順に従い、コピーしたばかりのアクティベーションキー値を使用して、新しいprop.jsonファイルを生成して保存します。 

  7. コンテナを実行します-ここを参照してください

  8. オプション)新しいwss-ghe-appコンテナーのURLが以前のコンテナーと異なる場合は、ここのガイドラインに従ってGitHubアプリのWebhookURLを更新し ます。

:バージョン20.4.2以降。remediate-dbイメージとコンテナーは不要になりました。以前のバージョンからアップグレードする場合は、手順3の一部として、コンテナーを停止してイメージを削除できます。

プライベートレジストリと認証済みリポジトリの処理

現在、NPMとMavenのプライベートレジストリのみがサポートされています。

サポートされているプラ​​イベートレジストリのリスト:

  • NPM

  • Yarn

  • Maven

  • Gradle

  • PIP

  • Go

プライベートレジストリと認証されたリポジトリからの依存関係をスキャンするには、WhiteSourceにNPMトークンなどの資格情報を提供する必要があります。シークレットスコープが組織全体の場合、これらの資格情報は、リポジトリごとに、または共有グローバル構成で、暗号化されたシークレットとして.whitesourceファイルに追加する必要があります。

暗号化された秘密を作成します。暗号化する各シークレットは、GitHub組織またはリポジトリにスコープする必要があり、その使用はアプリ内のものに制限されます。

  1. GPGを使用してPGPキーを生成します。コマンドgpg --full-generate-key を使用し、プロンプトに従ってキーを生成します。現時点では、復号化にパスフレーズを使用することはサポートされていないため、パスフレーズなしでキーを生成することをお勧めします。名前とメールアドレスは重要ではありません。

    1. 出力からキーIDをコピーするgpg --list-secret-keys か、コピーを取り忘れた場合は実行 します。これはあなたの公開鍵です。

    2. 実行 gpg --armor --export-secret-keys YOUR_NEW_KEY_ID > ws-private-key.asc して、装甲(テキストベース)秘密鍵ファイルを生成します

    3. 実行 gpg --armor --export YOUR_NEW_KEY_ID > ws-public-key.asc して、装甲(テキストベース)公開鍵ファイルを生成します

  2. 修復およびスキャナーに環境変数を使用して秘密鍵を提供します(環境変数の詳細については、高度な技術情報のドキュメントを参照してください)。それを行う方法には2つのオプションがありますが、1つのオプションのみを使用する必要があります。

    1. WS_HOST_RULES_PRIVATE_KEY-秘密鍵自体の値。

    2. WS_HOST_RULES_PRIVATE_KEY_FILE_PATH-秘密鍵を含むファイルへのパス。このファイルは、実行中のコンテナーにマップする必要があります。

  3. お気に入りのエディターでindex-enterprise.htmlを開きます。

  4. 「COPY_YOUR_PUBLIC_PGP_KEY_HERE」というテキストを見つけて、新しく生成した公開鍵に置き換え、ファイルを保存します。
    const publicKeyString = `COPY_YOUR_PUBLIC_PGP_KEY_HERE`;

  5. シークレットを作成したら、それを.whitesourceファイルのhostRulesパラメーターに追加してください。

hostRulesの例:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 { "hostRules": [ { "matchHost": "registry.npmjs.org", "hostType": "npm", "encrypted": { "token": "3f832f2983yf89hsd98ahadsjfasdfjaslf............" } }, { "matchHost": "https://custom.registry.company.com/maven/", "hostType": "maven", "username": "bot1", "encrypted": { "password": "p278djfdsi9832jnfdshufwji2r389fdskj........." } } ] }

  • コメントを含むキージェネレータの出力全体をコピーして、文字列に貼り付けます。

    つまり、「----- BEGIN PGP PUBLIC KEYBLOCK -----...」を含めます。

  • 文字列は、引用符ではなくJavaScriptのバッククォートを使用します。これは、複数行の文字列を許可して、改行を改行文字に置き換える必要がないようにするためです。公開鍵にスペースを導入し、暗号化が失敗する可能性のあるエディターによる自動インデントに注意してください。

  • PGP方法論の非対称公開鍵暗号を使用します 。組織/グループ、リポジトリ、生の値-暗号化ページで提供するすべての情報は、このアプローチで保護されます。

アンインストール

次の手順を実行すると、このアプリを簡単にアンインストールできます。

  1. GitHubのアカウント設定の[アプリケーション]セクションに移動し、[WhiteSourceアプリ]アプリケーションの横にある[構成]ボタンをクリックします。

  2. 「WhiteSourceBoltforGitHub」ページが開きます。[WhiteSourceアプリのアンインストール]ボタンを表示するには、下にスクロールします。 

  3. [アンインストール]ボタンをクリックします。WhiteSourceアプリをアンインストールすると、すべてのリポジトリから削除されます。

  4. 必要に応じて、[承認済みGitHubアプリ]タブに移動し、[WhiteSourceアプリ]アプリの横にある[取り消す]ボタンをクリックします。