SCW Trust Agent を Git ベースのソースコード管理ツールに接続するための複数のアプローチを提供しています。各アプローチには利点と制限があり、お客様の組織固有の環境とポリシーに基づいて決定することができます。
すべてのアプローチは、以下を含むコミット・メタデータのみを保存します:
- コミット作者名
- コミット著者のメールアドレス
- コミットのタイムスタンプ
- コミットで変更されたファイル拡張子のリスト
- 変更されたファイルに基づく、コミットに関連するプログラミング言語とフレームワークのリスト
この要約データは、ダッシュボードやレポートの生成、Secure Code Warrior の学習経路の最適化や設定したポリシーの適用などの自動化アクションを実行する目的で、SCW Trust Agent によって保存されます。
ソースコードは、正確なフレームワーク検出を容易にするために検査されますが、保存されることはありません。分析結果のみが、上記のようにファイル拡張子または言語とフレームワークのリストの形で保存されます。
オンプレミス
このアプローチは、あなたのチームによって設定・管理されるコンテナをあなたの環境内で実行することで、柔軟性とリスク軽減の組み合わせを提供します。これは、サード・パーティのプラットフォームをソース・コード管理ツールに直接接続するリスクを相殺する。
オンプレミス・コンテナは設定可能で、クラウドベースとオンプレミスの両方のソースコード管理プラットフォームで動作します。オンプレミス・コンテナは、指定されたリポジトリに自動的に接続し、要約されたデータをSCW Trust Agentにプッシュバックするために、定期的に実行することができます。このアプローチでは、組織のソースコードや、組織のソースコードにアクセスするためのキーが環境から離れることはありません。
- オンプレミスのDockerイメージは、以下の場所で公開しています。
に公開した。 - オンプレミスのDockerイメージは、Docker、Kubernetesなど、お好みのコンテナ・プラットフォーム、またはDockerコンテナをサポートするCIパイプラインで実行できます。
- 当社の顧客は通常、以下の3つのデプロイアプローチのいずれかを使用します:
- ラップトップまたはワークステーションからスケジュールに従ってコンテナを実行する。 - これは通常、最も単純な方法であるが、個人のラップトップまたはワークステーションが、通常のインポートを実行し続けるために利用可能である必要がある。手動スケジュールでアドホックに実行することも、cronやタスクスケジューラーなどのツールを使って自動化することもできる。
- 組織のコンテナ・プラットフォームでコンテナを一元的に実行する。 - この方法では、コンテナの設定と実行を一元管理することができます。コンテナは、すべての Git プラットフォームに接続し、すべてのリポジトリから一括してデータをインポートするように設定されます。しかし、リポジトリの数が多かったり、リポジトリのサイズが大きかったりすると、コンテナのディスク容量やネットワーク帯域幅が問題になる可能性があります。ディスク使用量を減らし、コミット・デルタのネットワーク・トラフィックを制限するために、コンテナ用の永続ファイルシステム・ボリュームを推奨します。
- 各リポジトリのCIパイプライン内でコンテナを実行する - このアプローチでは通常、スケーラブルにするために全リポジトリで共有する共通のCIプロジェクトが必要ですが、もしそれが利用可能であれば、全リポジトリが個別にコンテナを実行してデータをインポートするようにコンテナを設定するすっきりとしたソリューションが提供されます。具体的な方法は、あなたの組織で採用されているCIアプローチとツールに大きく依存します。唯一の要件は、CIツールがDockerコンテナをサポートしていることです。
- でコンテナを構成しなければならない:
- Git リポジトリへの HTTPS によるネットワーク接続。
- prod.securecodewarrior.com配下のサブドメインへのネットワーク接続性
- Git リポジトリをクローンするのに十分なディスク容量
- 永続ボリュームをマウントすることで、各コンテナの実行をリポジトリの完全なクローンではなくインクリメンタル・プルにすることができます。
- 以下の環境変数は、実行時にコンテナに渡さなければならない:
-
SCW_API_KEY- SCW Admin API キー。このガイドに従ってください。 このガイドを参照してください。 -
SCW_API_URL- SCW API エンドポイントの URL。以下を参照してください。 トラストエージェントの設定> Git Connections> Add Provider> On-Premises> Setup Details にアクセスしてください。を参照してください。以下に例を示します:REPO_URLS- カンマ区切りの Git リポジトリ URL のリスト。https://git.local/projects/project1.git,https://git2.internal/projects/projectX.git- 現在サポートされている Git リポジトリの URL は HTTPS のみです。
- URLでクレデンシャルを提供する別の方法が提供されています。
-
- 以下の環境変数はオプションで、実行時にコンテナに渡して特定の動作を制御することができる:
-
GIT_USERNAME- 認証情報を提供するための代替方法です。認証時にリポジトリに渡すユーザー名を指定します。- 注意: これは
REPO_URLS.異なるリポジトリに異なる認証情報が必要な場合は、認証情報のセットごとに個別のコンテナ実行が必要になる。
- 注意: これは
-
GIT_PASSWORD- 認証情報を提供するための代替方法です。認証の際にリポジトリに渡すパスワードを指定します。ほとんどの Git プラットフォームでは、API キーやアクセストークンをGIT_PASSWORDを指定する必要はありません。GIT_USERNAME.- 注意: これは
REPO_URLS.異なるリポジトリに異なる認証情報が必要な場合は、認証情報のセットごとに個別のコンテナ実行が必要になる。
- 注意: これは
-
スキップ証明書チェック- これをに設定する。に設定する。これは、ルート証明書と発行証明書が公開されていないため、内部で発行されたSSL/TLS証明書を持つシステムに接続するときに必要になることがあります。この問題が発生する可能性のあるシナリオを以下に示します:- 内部で発行されたSSL/TLS証明書を持つ内部ソースコード管理サーバーへの接続。このシナリオでは、トランスポートは暗号化されたままであり、トラフィックの内部的な性質が、この検証が防ぐように設計されているネットワーク攻撃の可能性を大幅に減少させることに注意してください。
- SSL/TLS 検査または傍受が実行され、SCW SSL/TLS サーバー証明書が内部で発行された SSL/TLS 証明書に動的に置き換えられている SCW サーバーへの接続。
-
- 例 環境変数をDockerに渡す例に渡す例を以下に示す。他のコンテナ・プラットフォームについてはドキュメントを参照してください。
- コマンドラインオプションで環境変数を渡す
docker run --pull=always -e SCW_API_KEY='your_api_key' -e SCW_API_URL='https://trust-agent.prod-us.prod.securecodewarrior.com' -e REPO_URLS='https://service_user:personal_access_token@git.local/projects/project1.git,https://service_user:service_password@git.local/projects/project2.git,https://git2.internal/projects/projectX.git' ghcr.io/securecodewarrior/trust-agent:latest
- ファイル経由で環境変数を渡す
docker run --pull=always --env-file env.list ghcr.io/securecodewarrior/trust-agent:latest
- コマンドラインオプションで環境変数を渡す
- オンプレミスコンテナは、毎日または毎週のスケジュールで実行することをお勧めしますが、組織固有の要件に基づいて頻度を調整することができます。
GitHubアプリ
この方法は、GitHub CloudやGitHub Enterprise Cloudをソースコード管理ツールとして使っている組織に特有のものです。GitHubのエコシステムフレームワークで動作するGitHub Appをインストールするシンプルなプロセスを含み、全体的に最も簡単なアプローチと考えられています。ただし、Secure Code Warriorが実際に保存するのは要約されたコミット・メタデータのみであるため、コミット・データにアクセスするためには、アプリがリポジトリのコンテンツにアクセスするための読み取りパーミッションが必要です。フレームワーク検出の目的で検査されたソースコードは、分析後に直ちに破棄され、保存されることはありません。ソースコードが検査されないことを希望される場合は、CSMにお知らせいただければ、この動作を明示的に無効にすることができますが、この場合、フレームワーク検出機能も無効になりますのでご注意ください。
- に移動します。 トラスト・エージェント設定画面に移動し プロバイダーの追加をクリックします。
- をクリックします。 接続をクリックします。
- をクリックします。 追加をクリックすると、新しいタブでインストールが始まります。GitHub 組織にアプリをインストールするには、組織管理者が必要です。
- 組織管理者でない場合は、組織管理者にアプリのインストールを依頼することができます。
- 組織管理者の場合は、以下の手順に従ってアプリがアクセスできるリポジトリを選択し、GitHub 組織にインストールしてください。
- インストールが完了したら トラストエージェントの設定画面に戻り、ステップ 2 の "Authorize" をクリックして Secure Code Warrior テナントを GitHub Organization にリンクします。
手動アップロード
この方法は、Git ベースのソースコード管理ツールとの直接の統合を必要とせず、SCW Trust Agent にアップロードするために要約されたコミットメタデータをエクスポートするその場限りの手動プロセスに依存します。その結果、SCW Trust Agent を試用するのに適した方法ですが、ポイントインタイムのスナップショットしか得られず、多数のリポジトリに対してスケーラブルではありません。
手動アップロードプロセスでは、選択したリポジトリをローカルシステムにクローンし、提供されたシェルスクリプトを実行して、SCW Trust Agent のウェブインタフェース経由でアップロードできるコミットサマリーを生成します。これは、選択した頻度で手動で実行できます。このアプローチでは、組織のソースコードや、組織のソースコードにアクセスするためのキーが環境から離れることはありません。
- ラップトップまたはワークステーション上のローカルに、SCW Trust Agent にインポートする Git リポジトリまたはリポジトリ(単一の親ディレクトリ内)をクローンします。
- 提供されたシェルスクリプト(参考のため以下に複製)を、ローカルにクローンした Git リポジトリまたはリポジトリの親ディレクトリにコピーします。
git-export.sh
SUBDIRS=$(find . -type d -name ".git" -exec dirname {} ˶;)
BASEDIR=$(pwd)
for SUBDIR in $SUBDIRS
する
cd $SUBDIR
PROJECT_NAME=$(basename -s .git `git config --get remote.origin.url`)
echo "$SUBDIR のコミットデータをエクスポート中"
git log --name-only --since="3 years ago" --no-merges --pretty=format:'- hash:%H
authorDate: %aI
authorEmail:e
authorName:an
modifiedFileExtensions:'| sed -e '/^[^ -]/ s/.*. \(.*)/ - \1/' | sed -e '/^[^ -]/d' | sed '$!N; /^(.*)\n \1$/!P; D'> $BASEDIR/scw_gci_$PROJECT_NAME.yaml
cd $BASEDIR
完了
- ラップトップかワークステーションで、作業ディレクトリをローカルにクローンしたGitリポジトリかリポジトリの親ディレクトリに変更します。
- 作業ディレクトリを git-export.shシェルスクリプトを実行します。
- YAML エクスポートはコミットデータの概要で、アップロードする前に調べることができます。
- YAMLファイルの内容を検査し、必要であれば情報を編集または削除する。
- に移動する。 トラストエージェント設定画面に移動し プロバイダーの追加をクリックします。
- をクリックします。 アップロード 手動アップロード
- アップロードするYAMLファイルを選択し、組織とリポジトリ名を指定して リポジトリのアップロード.組織名は、リポジトリをグループ化するためのフォルダとみなすことができます。エクスポートしたすべての YAML ファイルについて、この手順を繰り返します。
コメント
0件のコメント
記事コメントは受け付けていません。