セクション開発ガイドライン
Sec セクションは GitLab アプリケーションのセキュリティ機能、DevSecOps の “Sec” の部分を担当します。Secセクションに特化した開発者向けガイドはここにリストアップされています。
私たちが共有している用語の概要については、用語集を参照してください。
アーキテクチャ
概要
セキュア機能をサポートするアーキテクチャは、主に2つの部分に分かれています：
- スキャン
- 処理、可視化、管理
スキャン
スキャンは与えられたリソースの脆弱性を見つけ、結果をエクスポートします。スキャンは、Analyzers サブグループにあるAnalyzers と呼ばれる小さなプロジェクトを通じて CI/CD ジョブで実行されます。Analyzersは、内部または外部で開発されたScannerと呼ばれるセキュリティツールをGitLabにインテグレーションするためのラッパーです。Analyzersは主にGoで書かれています。
サードパーティのインテグレーターの中には、同じアーキテクチャを利用したインテグレーション・ドキュメントに従うことで、追加のスキャナーを利用できるようにしているところもあります。
スキャンの結果はJSONレポートとしてエクスポートされ、セキュアレポートフォーマットに準拠する必要があります。
処理、可視化、管理
データがレポートアーティファクトとして利用可能になった後、GitLab Railsアプリケーションによって処理され、以下のようなセキュリティ機能が有効になります：
- セキュリティダッシュボード、マージリクエストウィジェット、パイプラインビューなどです。
- 脆弱性との相互作用。
- 承認規則。
コンテキストに応じて、セキュリティレポートはデータベースに保存されるか、オンデマンドアクセス用のレポートアーティファクトとして保存されます。
セキュリティレポート取り込みの概要
GitLabがスキャナーによって生成されたレポーターをどのように処理するかについての詳細は、セキュリティレポート取り込みの概要をご覧ください。
CI/CD テンプレート開発者
CI/CDテンプレートはVerifyセクションの責任ですが、多くはSecセクションの機能利用にとって重要です。CI/CDテンプレートを扱う場合は、GitLab CI/CDテンプレートの開発ガイドを読んでください。
プライマリ識別子のインポート
アナライザーのJSONレポート内では、identifiers フィールド 、脆弱性を記述できるタイプとカテゴリ（つまりCWEファミリー）のコレクションが含まれています。
identifiers コレクションの最初の項目はプライマリ識別子として知られており、脆弱性の記述と追跡の両方にとって重要な要素です。
その他のほとんどの場合、identifiers コレクションは順序付けされておらず、残りの二次識別子は脆弱性をグループ化するためのメタデータとして機能します（例外については、下記のAnalyzer 脆弱性翻訳を参照してください）。
プライマリ識別子が変更され、プロジェクトパイプラインが再実行されるたびに、新しいレポートの取り込みは以前のDBレコードを「孤児」にします。私たちの処理ロジックは、2つの異なる脆弱性の差分を生成することに依存しているため、かなり混乱してしまう可能性があります。例えば
マージされた後、以前の脆弱性は「修復済み」としてリストされ、導入された脆弱性は「検出済み」としてリストされます。
一次識別子の安定性を確保するための指針
- やむを得ない理由がない限り、一次識別子を変更すべきではありません。
- 脆弱性の変換をサポートするアナライザは、結果の「孤児化」を防ぐために、従来の一次識別子を二次的な位置に含める必要があります。
- 一次識別子を超えて、二次識別子の順序は重要ではありません。
- 識別子は、
TypeとValueフィールドの組み合わせに基づいて一意になります（識別子の指紋を参照）。 - プライマリ識別子を変更した場合、アナライザーを以前のバージョンにロールバックしても、孤立した結果は修正されません。以前データベースに取り込まれたデータは、データマイグレーションを自動化する方法がほとんどない以前のジョブのアーティファクトです。
アナライザーの脆弱性変換
SAST Semgrep解析器の場合、特に重要な二次識別子があります。それは、レポートの脆弱性をレガシー解析器（つまり、banditまたはESLint）にリンクする識別子です。
脆弱性の変換を可能にするために、Semgrep アナライザはレガシーアナライザの一次識別子と完全に一致する二次識別子に依存しています。
例えば、eslint が脆弱性レコードの生成に以前使用されていた場合、semgrep アナライザは元のESLint 一次識別子を含む識別子コレクションを生成しなければなりません。
元のeslint レポートが与えられた場合：
{
"version": "14.0.4",
"vulnerabilities": [
{
"identifiers": [
{
"type": "eslint_rule_id",
"name": "ESLint rule ID security/detect-eval-with-expression",
"value": "security/detect-eval-with-expression"
}
]
}
]
}
対応するSemgrepレポートにはeslint_rule_id ：
{
"version": "14.0.4",
"vulnerabilities": [
{
"identifiers": [
{
"type": "semgrep_id",
"name": "eslint.detect-eval-with-expression",
"value": "eslint.detect-eval-with-expression",
"url": "https://semgrep.dev/r/gitlab.eslint.detect-eval-with-expression"
},
{
"type": "eslint_rule_id",
"name": "ESLint rule ID security/detect-eval-with-expression",
"value": "security/detect-eval-with-expression"
}
]
}
]
}
脆弱性の追跡は、レガシーアナライザで生成されたDBレコードを新しいsemgrep 。