セキュリティ用語集

この用語集では、GitLabのセキュリティ機能に関連する用語の定義を提供します。一部の用語は他の場所で異なる意味を持つ場合がありますが、これらの定義はGitLabに固有のものです。

アナライザー

スキャン対象タイプのセキュリティ脆弱性を分析するソフトウェア。内部的には、必要な設定パラメータを収集し、ターゲットを標準化された形式に変換するために必要なデータ変換を実行して、スキャナーがスキャン操作を実行できるようにします。最後に、呼び出し元が必要とする形式でレポートを生成します。

CI/CDベースのGitLabアナライザーは、CI/CDジョブを使用してGitLabに統合されます。CI/CDベースのGitLabアナライザーによって生成されたレポートは、ジョブの完了後にアーティファクトとして公開されます。GitLabはこのレポートをインジェストし、ユーザーが検出された脆弱性を視覚化および管理できるようにします。生成されたレポートは、セキュアレポート形式に準拠しています。

多くのGitLabアナライザーは、Dockerを使用してラップされたスキャナーを実行する標準的なアプローチに従います。たとえば、イメージsemgrepは、スキャナーSemgrepをラップするアナライザーです。ただし、一部のアナライザーは、個別のコンテナではなく、GitLab Railsまたはその他のターゲット環境内で直接実行されます。

アタックサーフェス

攻撃に対して脆弱性があるアプリケーション内のさまざまな場所。セキュア製品は、スキャン中にアタックサーフェスを検出し、検索します。各製品は、アタックサーフェスを異なって定義します。たとえば、SASTはファイルと行番号を使用し、DASTはURLを使用します。

コンポーネント

ソフトウェアプロジェクトの一部を構成するソフトウェアコンポーネント。例としては、ライブラリ、ドライバー、データ、およびその他多数があります。

コーパス

ファズテストの実行中に生成される、意味のあるテストケースのセット。意味のある各テストケースは、テスト対象のプログラムで新しいカバレッジを生成します。コーパスを再利用し、後続の実行に渡す必要があります。

CNA

共通脆弱性識別子採番機関（CNA）は、それぞれのスコープ内で製品またはサービスの脆弱性に共通脆弱性識別子を割り当てる権限をMitre Corporationから与えられた世界中の組織です。GitLabはCNAです。

CVE

Common Vulnerabilities and Exposures（CVE®）は、公に知られているサイバーセキュリティ脆弱性の共通識別子のリストです。このリストは、Mitre Corporationによって管理されています。

CVSS

Common Vulnerability Scoring System（CVSS）は、コンピューターシステムのセキュリティ脆弱性の重大度を評価するための、無料のオープンな業界標準です。

CWE

Common Weakness Enumeration（CWE™）は、セキュリティ上の影響がある一般的なソフトウェアおよびハードウェアの弱点の種類について、コミュニティで開発されたリストです。弱点とは、ソフトウェアまたはハードウェアの実装、コード、設計、アーキテクチャにおける欠陥、障害、バグ、脆弱性、またはその他のエラーです。対処されない場合、弱点により、システム、ネットワーク、またはハードウェアが攻撃に対して脆弱になる可能性があります。CWEリストおよび関連する分類タクソノミーは、これらの弱点をCWEの観点から識別および記述するために使用できる言語として機能します。

重複排除

カテゴリーのプロセスで検出が同じであると見なされる場合、またはノイズリダクションが必要なほど類似している場合、1つの検出のみが保持され、その他は削除されます。重複排除プロセスの詳細をご覧ください。

依存関係グラフのエクスポート

依存関係グラフのエクスポートには、プロジェクトで使用される直接的および間接的な依存関係がリストされ、それらの間の関係が含まれます。これは、pipdeptree graph エクスポートの場合のように、インストール中にパッケージマネージャーで必要とされない場合があるため、ロックファイルとは区別されます。

重複する検出

複数回レポートされる正当な検出。これは、異なるスキャナーが同じ検出を検出した場合、または1回のスキャンで誤って同じ検出が複数回レポートされた場合に発生する可能性があります。

誤検出:

存在しないにもかかわらず、誤って存在するとレポートされる検出。

検出

アナライザーによってプロジェクトで識別された、脆弱性を持つ可能性のあるアセット。アセットには、ソースコード、バイナリパッケージ、コンテナ、依存関係、ネットワーク、アプリケーション、インフラストラクチャが含まれますが、これらに限定されません。

検出は、MR/フィーチャーブランチでスキャナーが識別する可能性のあるすべての脆弱性アイテムです。デフォルトにマージした後にのみ、検出が脆弱性になります。

脆弱性の検出を操作するには、次の2つの方法があります。

1. 脆弱性の検出について、イシューまたはマージリクエストを開くことができます。
2. 脆弱性の検出を無視できます。検出を無視すると、デフォルトのビューから非表示になります。

グループ化

重複排除の対象とならない複数の検出がある場合に、グループ内の脆弱性を視覚的に整理するための、柔軟で非破壊的な方法。たとえば、一緒に評価する必要がある検出、同じアクションで修正される検出、または同じソースからの検出を含めることができます。

重要でない検出

特定の顧客が気にしない正当な検出。

既知の影響を受けるコンポーネント

脆弱性が悪用されるための要件を満たすコンポーネント。たとえば、packageA@1.0.3は、名前、パッケージタイプ、およびFAKECVE-2023-0001の影響を受けるバージョンまたはバージョン範囲の1つと一致します。

場所のフィンガープリント

検出の場所のフィンガープリントは、アタックサーフェス上の各場所に対して一意のテキスト値です。各セキュリティ製品は、アタックサーフェスのタイプに応じてこれを定義します。たとえば、SASTはファイルパスと行番号を組み込みます。

ロックファイル

ロックファイルは、アプリケーションの直接的および間接的な依存関係の両方を網羅的にリストして、パッケージマネージャーによる再現可能なビルドを保証します。これは依存関係グラフのエクスポート（Gemfile.lockファイルのケースなど）である場合もありますが、依存関係のリストは要件ではなく、保証もされていません。

パッケージマネージャーとパッケージタイプ

パッケージマネージャー

パッケージマネージャーは、プロジェクトの依存関係を管理するシステムです。

パッケージマネージャーは、新しい依存関係（「パッケージ」とも呼ばれます）をインストールする方法を提供し、ファイルシステム上のパッケージの保存場所を管理し、独自のパッケージを公開する機能を提供します。

パッケージのタイプ

各パッケージマネージャー、プラットフォーム、タイプ、またはエコシステムには、ソフトウェアパッケージを識別、検索、およびプロビジョニングするための独自の規則とプロトコルがあります。

次の表は、GitLabドキュメントおよびソフトウェアツールで参照されているパッケージマネージャーとタイプの網羅的ではないリストです。

パイプラインセキュリティタブ

関連付けられたCIパイプラインで検出された検出を表示するページ。

影響を受ける可能性のあるコンポーネント

脆弱性によって影響を受ける可能性のあるソフトウェアコンポーネント。たとえば、既知の脆弱性についてプロジェクトをスキャンする場合、コンポーネントが最初に評価され、名前とパッケージタイプが一致するかどうかが確認されます。このステージでは、脆弱性によって影響を受ける可能性があり、影響を受けるバージョン範囲に該当することが確認された後にのみ、影響を受けることがわかります。

ポストフィルター

ポストフィルターは、スキャナーの結果のノイズを軽減し、手動タスクを自動化するのに役立ちます。スキャナーの結果に基づいて、脆弱性データを更新または変更する基準を指定できます。たとえば、検出に誤検出の可能性があるというフラグを設定し、検出されなくなった脆弱性を自動的に解決できます。これらは永続的なアクションではなく、変更できます。

検出の自動解決のサポートはエピック7478で追跡されており、安価なスキャンのサポートはエピック7886で提案されています。

プリフィルター

分析が行われる前に、ターゲットを除外するために行われる不可逆的なアクション。これは通常、ユーザーがスコープとノイズを減らし、分析を高速化できるようにするために提供されます。GitLabはスキップ/除外されたコードまたはアセットに関連するものを何も保存しないため、記録が必要な場合はこれを行うべきではありません。

例：DS_EXCLUDED_PATHSはExclude files and directories from the scan based on the paths provided.である必要があります

プライマリ識別子

検出のプライマリ識別子は、各検出に固有の値です。検出の最初の識別子の外部タイプと外部IDが組み合わさって値が作成されます。

プライマリ識別子の例はCVEであり、Trivyに使用されます。その識別子は安定している必要があります。場所がわずかに変更された場合でも、後続のスキャンは同じ検出に対して同じ値を返す必要があります。

プロセッサー

入力を受け入れ、指定された基準に従って変換するソフトウェア。入力データを変更するか、追加のメタデータを出力として添付します。プロセッサーは、スキャナーの操作をサポートするために存在し、スキャン前およびスキャン後のステージで一般的に使用されます。フィルターとは異なり、プロセッサーはビジネスロジックに基づいてワークフローの継続または終了を制御する意思決定機能を持っていません。代わりに、変換を実行し、結果を無条件に転送します。

プリプロセッサー

プリプロセッサーは通常、入力形式の正規化、追加のコンテキストによるスキャンターゲットの拡充、ターゲット固有の変換の適用、設定パラメータの拡張など、データ準備タスクを実行します。これにより、スキャナーが、スキャン操作に最適化された適切にフォーマットされ、強化された入力を受け取ることが保証されます。

ポストプロセッサー

ポストプロセッサーは、スキャナーが操作を完了した後、スキャン結果にインテリジェントな分析を適用します。ポストプロセッサーは、脆弱性の分類、誤検出のフィルタリング、重大度の調整、コンテキストの拡充などの操作を通じて、rawスキャナーの出力を強化します。スキャナーの結果は、処理された結果がアナライザーに返される前に、シーケンス内の複数のポストプロセッサーを通過できます。

到達可能性

到達可能性は、プロジェクトの依存関係としてリストされているコンポーネントが、コードベースで実際に使用されているかどうかを示します。

レポートの検出

アナライザーによって生成されたレポートにのみ存在する検出であり、データベースにまだ永続化されていません。そのレポートの検出は、データベースにインポートされると、脆弱性の検出になります。

スキャンタイプ（レポートタイプ）

スキャンのタイプについて説明します。これは、次のいずれかである必要があります:

• api_fuzzing
• container_scanning
• coverage_fuzzing
• dast
• dependency_scanning
• sast
• secret_detection

このリストは、スキャナーが追加されると変更される可能性があります。

スキャンターゲットタイプ

スキャンの実行範囲の境界として機能するコンテンツまたはアーティファクトの個別の単位。各スキャンターゲットタイプは、定義されたスキャン制約を持つ自己完結型のエンティティを表します。スキャンターゲットタイプの特定のインスタンス（特定のGitリポジトリやコンテナイメージなど）は、「スキャンターゲット」と呼ばれます。スキャンターゲットタイプの例としては、Gitリポジトリ、ファイルシステム、コンテナなどがあります。

スキャナー

スキャンターゲットタイプのインスタンスであるスキャンターゲットのセキュリティ脆弱性をスキャンするソフトウェア。これは一般に、アナライザーから必要なスキャンの設定パラメータとスキャンペイロードを受信するステートレスコンポーネントです。結果として得られるスキャンレポートは、必ずしもセキュアレポート形式であるとは限りません。スキャナーは、追加のプロセッサー（たとえば、シークレット検出スキャナー）を使用して1つ以上のスキャンエンジンをラップする高度なコンポーネントである場合もあれば、スタンドアロンのスキャンエンジン（たとえば、Trivy）と同じくらいシンプルな場合もあります。

セキュア製品

GitLabによる一流のサポートを備えた、特定のアプリケーションセキュリティの領域に関連する機能のグループ。

製品には、コンテナスキャン、依存関係スキャン、動的アプリケーションセキュリティテスト（DAST）、シークレット検出、静的アプリケーションセキュリティテスト（SAST）、およびファズテストが含まれます。

これらの各製品には通常、1つ以上のアナライザーが含まれています。

セキュアレポート形式

セキュア製品がJSONレポートを作成する際に準拠する標準レポート形式。形式は、JSONスキーマによって記述されます。

セキュリティダッシュボード

プロジェクト、グループ、またはGitLabインスタンスのすべての脆弱性の概要を提供します。脆弱性は、プロジェクトのデフォルトブランチで検出された検出からのみ作成されます。

シードコーパス

ファズテストターゲットへの最初の入力として与えられたテストケースのセット。これにより、ファズテストターゲットが大幅に高速化されます。これは、手動で作成されたテストケースであるか、以前の実行からファズテストターゲット自体で自動生成されたものである可能性があります。

ベンダー

アナライザーを維持する当事者。そのため、ベンダーはスキャナーをGitLabに統合し、進化に合わせて互換性を維持する責任があります。ベンダーは、オープンコアまたはOSSプロジェクトを製品のベースソリューションとして使用するケースのように、スキャナーの作成者またはメンテナーであるとは限りません。GitLabディストリビューションまたはGitLabサブスクリプションの一部として含まれるスキャナーの場合、ベンダーはGitLabとしてリストされます。

脆弱性

脆弱性は、その環境のセキュリティに悪影響を与える欠陥です。脆弱性はエラーまたは弱点を記述しますが、エラーの場所は記述しません（findingを参照）。

各脆弱性は、一意の検出結果にマップされます。

脆弱性はデフォルトブランチに存在します。検出結果（findingを参照）は、スキャナーがMR/フィーチャーブランチで識別する可能性のあるすべての脆弱性項目です。デフォルトにマージした後にのみ、検出結果が脆弱性になります。

脆弱性検出結果

report findingがデータベースに保存されると、脆弱性findingになります。

脆弱性トラッキング

これは、検出結果のライフサイクルを理解できるように、スキャン間で検出結果を追跡する責任を担います。エンジニアとセキュリティチームは、この情報を使用して、コード変更をマージするかどうかを決定したり、未解決の検出結果とそれらがいつ導入されたかを確認したりします。

脆弱性は、場所のフィンガープリント、プライマリ識別子、およびレポートタイプを比較することによって追跡されます。

脆弱性の発生

非推奨。findingを参照してください。