1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

アプリケーションのセキュリティを始める

Last updated at Posted at 2025-11-23

アプリケーションのセキュリティを始める

(トップページはこちら)

GitLabのアプリケーションセキュリティ機能を使えば、セキュリティテストをソフトウェア開発ライフサイクルに統合し、潜在的なセキュリティ問題を自動的にスキャンできます。本記事では、セキュリティスキャン機能を段階的に導入し、開発プロセス全体でセキュリティを優先事項として扱うための実践的な手順を解説します。

image.png

概要

GitLabは様々なプログラミング言語とフレームワークをスキャンし、以下のような脆弱性を検出できます。

  • SQLインジェクション - データベースへの不正なクエリ実行
  • クロスサイトスクリプティング(XSS) - 悪意のあるスクリプトの注入
  • 安全でない依存関係 - 既知の脆弱性を含むライブラリやパッケージ
  • シークレット情報の漏洩 - APIキーやパスワードなどの機密情報

スキャン結果はGitLabのUIに表示され、マージリクエストやパイプラインと統合することで、開発プロセス全体を通じてセキュリティを確保できます。

ステップ1: スキャンについて学ぶ

まず、2つの基本的なスキャン機能を理解しましょう。

1.1. シークレット検出(Secret Detection)

リポジトリをスキャンして、シークレット情報の漏洩を防ぎます。すべてのプログラミング言語で動作します。APIキー、パスワード、トークンなどの機密情報が誤ってコミットされていないかをチェックします。

1.2. 依存関係スキャン(Dependency Scanning)

アプリケーションの依存関係を分析し、既知の脆弱性を検出します。特定の言語とパッケージマネージャーに対応しています。使用しているライブラリやフレームワークに脆弱性がないかを確認できます。

詳細はこちら

ステップ2: テスト対象のプロジェクトを選択する

初めてGitLabのセキュリティスキャンを設定する場合は、単一のプロジェクトから始めることをお勧めします。

2.1. 適切なプロジェクトの条件

組織で一般的に使用されている技術を使用している

スキャン機能は言語によって動作が異なるため、実際の開発環境を反映したプロジェクトを選びましょう。

新しい設定を試せる環境である

承認必須などの設定を、チームの日常業務を中断せずに試せるプロジェクトが理想的です。トラフィックの多いプロジェクトのコピーを作成するか、あまり活発でないプロジェクトを選択しましょう。

ステップ3: スキャンを有効化する

プロジェクト内の漏洩したシークレットと脆弱なパッケージを特定するため、シークレット検出と依存関係スキャンを有効化するマージリクエストを作成します。

3.1. 設定の流れ

  1. .gitlab-ci.ymlファイルを更新するマージリクエストを作成
  2. スキャンがプロジェクトのCI/CDパイプラインの一部として実行されるように設定
  3. プロジェクトのレイアウトや構成に合わせて設定を調整(例: サードパーティコードのディレクトリを除外)

3.2. ベースラインスキャンの重要性

マージリクエストをデフォルトブランチにマージすると、システムがベースラインスキャンを作成します。このスキャンは、デフォルトブランチに既に存在する脆弱性を特定します。

その後、マージリクエストでは新たに導入された問題のみがハイライトされます。ベースラインスキャンがない場合、マージリクエストはブランチ内のすべての脆弱性を表示してしまい、既にデフォルトブランチに存在する脆弱性も含まれてしまいます。

3.3. 基本的な設定例

# シークレット検出の有効化
include:
  - template: Jobs/Secret-Detection.gitlab-ci.yml

# 依存関係スキャンの有効化
include:
  - template: Jobs/Dependency-Scanning.gitlab-ci.yml

# 除外設定の例
variables:
  DS_EXCLUDED_PATHS: "vendor/,third_party/"
  SECRET_DETECTION_EXCLUDED_PATHS: "tests/fixtures/"

ステップ4: スキャン結果を確認する

チームがマージリクエストと脆弱性レポートでセキュリティ検出結果を確認することに慣れるようにしましょう。

4.1. 脆弱性トリアージワークフローの確立

ラベルとイシューボードの作成

脆弱性から作成されたイシューを管理するためのラベルを作成します。イシューボードを使用することで、すべてのステークホルダーが共通のビューを持ち、修正の進捗を追跡できます。

セキュリティダッシュボードのトレンド監視

既存の脆弱性の修正状況を測定し、新しい脆弱性の導入を防げているかを確認します。

4.2. 確認できる場所

  • 脆弱性レポート - プロジェクト全体の脆弱性を一覧表示
  • マージリクエスト - 新規に導入される脆弱性をレビュー時に確認
  • セキュリティダッシュボード - 組織全体のセキュリティ状況を可視化

詳細はこちら

ステップ5: 定期的なスキャンジョブをスケジュールする

スキャン実行ポリシーを使用して、定期的なセキュリティスキャンジョブを強制します。

5.1. 定期スキャンの特徴

定期スキャンは、コンプライアンスフレームワークパイプラインやプロジェクトの.gitlab-ci.ymlで定義された他のセキュリティスキャンとは独立して実行されます。開発活動が少なく、パイプラインスキャンが頻繁でないプロジェクトや重要なブランチに最も有用です。

5.2. スキャン実行ポリシーの例

# 週次でのスキャン実行
type: scan_execution_policy
name: "週次セキュリティスキャン"
description: "毎週月曜日にセキュリティスキャンを実行"
enabled: true
rules:
  - type: schedule
    branches:
      - main
    cadence: "0 0 * * 1"  # 毎週月曜日
actions:
  - scan: secret_detection
  - scan: dependency_scanning
  - scan: container_scanning

5.3. 追加のスキャンタイプ

  • コンテナスキャン - コンテナイメージの脆弱性を検出
  • 運用コンテナスキャン - 本番クラスタで実行中のコンテナイメージをスキャン

詳細はこちら

ステップ6: 新しい脆弱性を制限する

スキャンの動作に慣れたら、より広範囲にセキュリティを強化しましょう。

6.1. スキャン実行ポリシーの活用

必須のスキャンタイプを強制し、セキュリティチームとエンジニアリングチームの職務分離を確保します。

6.2. マージリクエスト承認ポリシーの作成

デフォルトブランチに新しい脆弱性がマージされることを制限します。

# マージリクエスト承認ポリシーの例
type: scan_result_policy
name: "重大な脆弱性のブロック"
description: "重大度が高い脆弱性が検出された場合、セキュリティチームの承認を必須とする"
enabled: true
rules:
  - type: scan_finding
    branches:
      - main
    scanners:
      - dependency_scanning
      - secret_detection
    severity_levels:
      - critical
      - high
    vulnerabilities_allowed: 0
actions:
  - type: require_approval
    approvals_required: 1
    user_approvers:
      - security-team

6.3. 段階的な展開

  1. 同じ手順で他のプロジェクトでもスキャンを有効化
  2. 複数のプロジェクトに対して一度にスキャンを強制

詳細はこちら

ステップ7: 新しい脆弱性のスキャンを継続する

時間の経過とともに、新しい脆弱性が導入されないようにすることが重要です。

7.1. 定期的なスキャンの実施

リポジトリに既に存在する新たに発見された脆弱性を表面化させるため、定期的な依存関係スキャンとコンテナスキャンを実行します。本番クラスタのコンテナイメージのセキュリティ脆弱性をスキャンするため、運用コンテナスキャンを有効化します。

7.2. 追加のスキャンタイプの有効化

SAST(Static Application Security Testing)

静的アプリケーションセキュリティテストです。ソースコードを分析して脆弱性を検出します。

DAST(Dynamic Application Security Testing)

動的アプリケーションセキュリティテストです。実行中のアプリケーションをテストします。

ファズテスト(Fuzz Testing)

ランダムなデータを入力して予期しない動作を検出します。

Web APIファジング

APIエンドポイントのセキュリティテストを実施します。

7.3. レビューアプリの活用

一時的なテスト環境でDASTやWeb APIファジングを実行するため、レビューアプリの有効化を検討しましょう。

# SASTの有効化例
include:
  - template: Jobs/SAST.gitlab-ci.yml

# DASTの有効化例
include:
  - template: Jobs/DAST.gitlab-ci.yml

variables:
  DAST_WEBSITE: "https://example.com"

詳細はこちら

まとめ

GitLabのアプリケーションセキュリティ機能を活用することで、開発プロセスの早い段階で脆弱性を検出し、修正できます。この7ステップのアプローチに従うことで、以下を実現できます。

  1. 段階的な導入 - 単一のプロジェクトから始めて、徐々に拡大
  2. 自動化されたスキャン - CI/CDパイプラインに統合し、継続的にセキュリティをチェック
  3. 可視化と追跡 - 脆弱性レポートとダッシュボードで状況を把握
  4. ポリシーによる強制 - 承認ポリシーで新しい脆弱性の導入を防止
  5. 包括的なカバレッジ - 複数のスキャンタイプで多角的にセキュリティを確保

セキュリティは一度設定して終わりではなく、継続的なプロセスです。GitLabの機能を活用して、開発速度を落とすことなく、安全なアプリケーションを構築していきましょう。

1
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?