更新日:2024年12月25日

35分で読めます

GitHub Advanced SecurityプランからGitLab Ultimateプランへの移行ガイド

GitLab UltimateとGitHub Advanced Securityの共通点と違いを理解し、GitLab DevSecOpsプラットフォームへの移行を段階的に進めるための詳細ガイドです。

GitLabは、最も包括的なAIを搭載したDevSecOpsプラットフォームで、ソフトウェアデリバリーライフサイクル全体を1つのプラットフォームで実現することで、より安全で迅速なソフトウェアのリリースを可能にしています。GitHubでは、GitHub内の追加のセキュリティ機能を有効にするAdvanced Securityアドオンを提供してはいますが、GitLabと比較すると、ネイティブに提供するセキュリティ機能の深さと幅広さでは機能の範囲と深さが限定的です。SDLCのすべての領域にわたってセキュリティを強化すべくGitLab Ultimateプランへの移行を検討している組織は、このガイドを参考にして両製品を比較し、またGitLabプラットフォームに移行するためのチュートリアルとしてもお役立てください。 この記事には次の内容が含まれます

  • GitLab UltimateとGitHub Advanced Securityの比較
  • GitHubリポジトリをGitLabに移行する方法
  • GitHub Advanced SecurityからGitLab Ultimateへの機能別の移行方法
  • GitLab Ultimateのセキュリティ追加機能の紹介

GitLab UltimateとGitHub Advanced Securityの比較

GitLab Ultimateは、安全なソフトウェアをより速く提供したいと考えている企業向けの、GitLabの最上位サブスクリプションプランです。GitHub Advanced Securityは、追加のセキュリティ機能を有効にするGitHub Enterpriseのアドオンです。

GitLab UltimateとGitHub Advanced Securityの類似点

GitLab UltimateとGitHub Advanced Securityの両プランに次の機能が搭載されています。

  • 静的アプリケーションセキュリティテスト(SAST)、シークレットスキャン、依存関係スキャン
  • コンテキスト脆弱性インテリジェンスと解決策のアドバイス
  • 依存関係またはソフトウェア部品表のリスト(SBOM
  • セキュリティ指標と分析情報

GitLab UltimateとGitHub Advanced Securityの相違点

GitLab Ultimateは、次の点でGitHub Advanced Securityと異なります。

GitHubリポジトリをGitLabに移行する方法

GitLabには、GitHub.comまたはGitHub EnterpriseからGitHubプロジェクトをGitLabにインポートできるインポーターが組み込まれています。インポーターを使用すると、GitHubリポジトリだけでなく、イシュー、コラボレーター(メンバー)、プルリクエストなど他のオブジェクトもGitLabに移行できます。移行できるものの全リストについては、GitHubインポートされたデータのドキュメントを参照してください。移行は次の手順で行います。

  1. 左側のサイドバー上部で 新規作成(+) を選択する
  2. GitLab内セクションで新しいプロジェクト/リポジトリを選択する
  3. プロジェクトのインポートを選択する 迷路化したバージョンの中心にGitLabのアイコン
  4. GitHubボタンを押す
  1. これで、以下のいずれかが可能になりました
  • GitHubで認証を選択して、GitHub Oauthで認証する
  • GitHubのパーソナルアクセストークンを使う
    • https://github.com/settings/tokens/newに移動します
    • Noteフィールドにトークンの説明を入力します
    • リポジトリスコープを選択します
    • オプションとしてコラボレーターをインポートするには、read:orgスコープを選択します
    • トークンを生成ボタンを押します
    • GitLabのインポートページのパーソナルアクセストークンフィールドに、GitHubのパーソナルアクセストークンを貼り付けます
  1. 認証ボタンを押す
  2. 移行するアイテムを選択する
  3. 移行するプロジェクトと場所を選択する
  4. インポートボタンを押す インポートされたプロジェクトがワークスペースにあることをご確認ください。GitHubからGitLabへの移行に関するさらに詳しいガイダンスは、次の動画をご覧ください。

variables: SEARCH_MAX_DEPTH:10

semgrep-sast: variables: SAST_ANALYZER_IMAGE_TAG:"3.7"

gosec-sast: before_script: - | cat < ~/.netrc machine gitlab.com login $CI_DEPLOY_USER password $CI_DEPLOY_PASSWORD EOF

      **注:** 利用可能なSASTジョブは、[' SAST.gitlab-ci.yml `テンプレート](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Jobs/SAST.gitlab-ci.yml)にあります。設定については、[利用可能なSAST CI/CD変数のドキュメント](https://docs.gitlab.com/ee/user/application_security/sast/#available-cicd-variables)を参照してください。
#### SASTルールセットのカスタマイズ
GitLabはSASTアナライザーごとにコードを処理し、ルールを使用してソースコードの脆弱性を特定します。これらのルールは、スキャナーが報告する弱点の種類を決定します。
- Semgrepを基盤としたSASTスキャナーについては、GitLabが検出ルールの作成、保守、サポートを一括して提供しています。Semgrepオープンソースエンジン、GitLabの管理による検出ルール、脆弱性追跡と誤検出のためのGitLab独自の技術を集結しています。
- 他のSASTアナライザーの場合、ルールは各スキャナーのupstreamプロジェクトで定義されています。
スキャンされるリポジトリ内の設定ファイルを定義することで、SASTスキャナーの動作をカスタマイズできます。
- 事前定義されたルールを無効にする(すべてのアナライザーで利用可能)
- 事前定義されたルールを上書きする(すべてのアナライザーで利用可能)
- パススルーを使用してカスタム設定を合成することにより、事前定義されたルールを置き換える
SASTルールの設定の詳細と例については、[SASTルール](https://docs.gitlab.com/ee/user/application_security/sast/rules.html)と[ルールセットのカスタマイズのドキュメント](https://docs.gitlab.com/ee/user/application_security/sast/customize_rulesets.html)を参照してください。
### シークレットスキャン
GitHubは、流出したシークレットを見つけ、ブロックし、取り消すことができるシークレットスキャンをサポートします。[シークレット検出](https://docs.gitlab.com/ee/user/application_security/secret_detection/)を有効にすることで、GitLab内でも同じことができます。
GitLabでシークレット検出を有効にするには、次のテンプレートを'.gitlab-ci.yml `に追加するだけです。
```yaml
include:
  - template: Jobs/Secret-Detection.gitlab-ci.yml

    

テンプレートが追加されると、新しいコードがチェックインされる(またはパイプラインが実行される)たびに、シークレットスキャナーは既知のシークレットのソースコードをスキャンします。パイプラインでのシークレット検出は、コードの各要素を別々にスキャンします。「デフォルトブランチ」を除くすべてのメソッドでは、パイプラインシークレット検出はワークツリーではなくコミットをスキャンします。シークレットスキャンの仕組みについては、シークレット検出カバレッジドキュメントを参照してください。 マージリクエストを作成する際、シークレット検出はソースブランチで行われたすべてのコミットをスキャンします。SASTと同様に、検出されたすべての脆弱性から、修正プロセスを支援するため、以下の情報(ロケーションなど)や識別子を提供します。 シークレット検出の脆弱性の詳細 SASTと同様に、マージリクエストから直接、脆弱性の無視やイシューの作成など、検出された脆弱性に対するアクションを取ることができます。

シークレット検出ジョブのカスタマイズ

GitLabではシークレット検出ジョブの定義を上書きして、変数や依存関係、ルールなどのプロパティを変更できます。上書きするには、シークレット検出ジョブと同名のジョブを宣言します。次に、テンプレートをインクルードした後に新しいジョブを配置し、その下に追加のキーを指定します。たとえば、次のような設定です。

  • シークレット検出ジョブの実行ステージをsecurityに上書きする
  • 過去のコミットに対するスキャンを有効にする
  • シークレットアナライザーのバージョンを4.5に変更する
      include:
  - template: Jobs/Secret-Detection.gitlab-ci.yml

secret_detection:
  stage: security
  variables:
    SECRET_DETECTION_HISTORIC_SCAN: "true"
    SECRETS_ANALYZER_VERSION: "4.5"

    

注: 利用可能なシークレット検出ジョブは、SAST.gitlab-ci.ymlテンプレートにあります。利用可能な設定は、利用可能なシークレット検出CI/CD変数のドキュメントに記載されています。

シークレット検出ルールセットのカスタマイズ

シークレット検出アナライザーでは、GitLab UIに表示されるシークレットをカスタマイズできます。次のカスタマイズオプションは、個別または組み合わせて使用できます。

  • 定義済みルールを無効にする
  • 定義済みルールを上書きする
  • カスタム設定を合成する
  • リモート設定ファイルを指定する たとえば、.gitlab/secret-detection-ruleset.tomlというファイルをプロジェクトのルートディレクトリに作成すると、デフォルトのGitLeaksパッケージがテストトークンの検出を無視するように拡張されます。
      ### extended-gitleaks-config.toml
title = "extension of gitlab's default gitleaks config"

[extend]
### Extends default packaged path
path = "/gitleaks.toml"

[allowlist]
  description = "allow list of test tokens to ignore in detection"
  regexTarget = "match"
  regexes = [
    '''glpat-1234567890abcdefghij''',
 ]

    

定義済みのアナライザールールを上書きする方法については、シークレット検出のドキュメントを参照してください。

シークレット漏洩時の自動対応機能

GitLabシークレット検出は、特定のタイプの流出したシークレットを発見すると自動的に対応します。自動対応には次のようなアクションがあります。

  • 自動的にシークレットを失効させる
  • シークレットを発行したパートナーに通知し、パートナーはシークレットを取り消すか、その所有者に通知するか、またはその他の方法で不正利用からの保護につなげる GitLabは、パートナーが発行した認証情報がGitLab.comの公開リポジトリに流出した場合、パートナーへの通知も可能です。クラウドやSaaS製品を運用していて、このような通知の受け取りに興味があるという場合、GitLab Token Revocation APIから呼び出されるPartner APIを実装できます。 詳しくは流出したシークレットへの自動対応を参照してください。

サプライチェーンのセキュリティ

GitHubは、自動化されたセキュリティとバージョン更新、ワンクリックのSBOMにより、ソフトウェアサプライチェーンのセキュリティ確保、管理、レポートを可能にします。GitLabは依存関係スキャンと依存関係リスト(SBOM)機能を使って、サプライチェーンセキュリティのニーズを満たすことができます。 GitLabで依存関係スキャンを有効にするには、.gitlab-ci.ymlに以下のテンプレートを追加するだけです:

      include:
  - template: Jobs/Dependency-Scanning.gitlab-ci.yml

    

テンプレートが追加されると、新しいコードがチェックインされるたびに、依存関係スキャンがプロジェクトで使われているパッケージマネージャを自動検出します。そして、使用されている依存関係に既知の脆弱性がないかスキャンします。フィーチャーブランチとターゲットブランチの差分の依存関係のスキャン結果は、マージリクエストウィジェットに表示されます。マージリクエストウィジェットは、マージリクエストで行われた変更によって導入された依存関係スキャンの結果と解決策を表示します。マージリクエストの中で、検出された脆弱性は、識別子、証拠、解決策といった、修正を支援する関連情報を表示します。 依存関係スキャナーの脆弱性の詳細 SASTやシークレット検出と同様に、脆弱性の無視やイシューの作成など、これらの脆弱性に対するアクションをマージリクエストから直接実行できます。

依存関係スキャンの設定

ジョブの定義を上書きするには(たとえば、変数や依存関係のようなプロパティを変更するには)、上書き対象のジョブと同じ名前で新しいジョブを宣言します。テンプレートをインクルードした後に新しいジョブを配置し、その下に追加のキーを指定します。たとえば、次のコードでは以下の設定を行っています。

  • 脆弱な依存関係の自動修正を無効にする
  • 依存関係スキャンの実行前にビルドジョブの完了を要求する
      include:
  - template:Jobs/Dependency-Scanning.gitlab-ci.yml

gemnasium-dependency_scanning:
  variables:
    DS_REMEDIATE:"false"
  dependencies:["build"]

    

依存関係スキャナーの設定についての詳細は、アナライザーの動作をカスタマイズするドキュメントを参照してください。

SBOMの生成

GitLabの依存関係リスト(SBOM)で、プロジェクトやグループの依存関係や、既知の脆弱性を含む依存関係の重要な詳細を確認できます。このリストには、プロジェクトにおける依存関係が集約されており、既知のものや新たに検出されたものの両方が含まれています。依存関係リストは、依存関係スキャナーがデフォルトブランチで正常に実行された後に生成されます。依存関係リストにアクセスするには

  1. 左サイドバーで、検索または移動先... を選択し、プロジェクトを見つけます。
  2. セキュリティ > 依存関係リストの順に選択します。 依存関係リスト(SBOM) ここから、依存関係に関する次の情報を表示できます。 |フィールド|説明| | ---------- | ---------- | |コンポーネント|依存関係の名前とバージョン。| |パッケージャー| 依存関係のインストールに使用されるパッケージャー。| |ロケーション| システムの依存関係の場合、スキャンされたイメージのリストが表示されます。アプリケーションの依存関係の場合、依存関係を宣言したプロジェクト内のパッケージャー固有のロックファイルへのリンクが表示されます。また、トップレベルの依存関係への依存関係パスも表示されます(該当の依存関係が存在する場合)。| |ライセンス| 依存関係のソフトウェアライセンスへのリンク依存関係で検出された脆弱性の数を示す警告バッジ。| |プロジェクト| 依存関係のあるプロジェクトへのリンク。同じ依存関係を持つプロジェクトが複数ある場合、プロジェクトの合計数が表示されます。依存関係のあるプロジェクトに移動するには、プロジェクトの番号を選択し、その名前を検索して選択します。プロジェクト検索機能は、グループ階層内に最大600件のプロジェクトがあるグループでのみサポートされています。|

ご意見をお寄せください

このブログ記事を楽しんでいただけましたか?ご質問やフィードバックがあればお知らせください。GitLabコミュニティフォーラムで新しいトピックを作成してあなたの声を届けましょう。

フィードバックを共有する

フォーチュン100企業の50%以上がGitLabを信頼

より優れたソフトウェアをより速く提供

インテリジェントなDevSecOpsプラットフォームで

チームの可能性を広げましょう。