シークレット スキャンのスコープをカスタマイズする
時々、ドキュメントあるいはサンプルのアプリケーション用に疑似的シークレットを用意するために、リポジトリにシークレットをコミットする場合があります。このようなシナリオでは、素早くアラートを却下して、その理由をドキュメント化することができます。しかし、偽陽性のアラートが大規模に作成されることを回避するため、ディレクトリ全体を無視したいという場合もあり得ます。例としては、トリアージのために多数の偽アラートを引き起こすこともあるダミー キーのファイルを含み、複数のインテグレーションを使用している、巨大なアプリケーションが考えられます。
これを行うには、シンプルなカスタム YAML 構成ファイルをリポジトリに追加し、そこに数行を追加するだけです。途中で LinkedIn にいくつかのインサイトを紹介してもらいます。
このガイドの学習内容
シークレット スキャン構成ファイルの作成方法
シークレット スキャンからファイルやフォルダーを除外する方法
除外するものと除外しないもの決定するためのベスト プラクティス
1. シークレット スキャン構成ファイルを作成する。
シークレット スキャンを有効にしていない場合は有効にします。
Web Goat リポジトリの /.github/ ディレクトリで、[ファイルを追加]、[新しいファイルを作成] の順に選択します。
ファイル名を次のようにします: secret_scanning.yml.
2. 構成ファイルを編集する。
次のコードをファイルに貼り付けます。
paths-ignore:
- "docs/**"
これは、シークレット スキャンに docs ディレクトリ内の全てを無視するように指示します。このサンプル ファイルをテンプレートとして使用して、自分のリポジトリから除外したいファイルやフォルダーを追加できます。
LinkedIn の何千ものリポジトリでシークレット スキャンを使用していますが、組織レベルで例外は設定していません。その代わりに、開発者がリポジトリ レベルで独自の除外を処理できるようにしています。これにより、例えば、ユニット テスト フォルダーや、LinkedIn のシークレットを含まないサードパーティのパッケージで不要なアラートを回避でき、セキュリティの変更が実装されるのを待つ必要がありません。
ただし、当社では、セキュリティ チームとコミュニケーションを取って除外対象について話し合うよう開発者に推奨しています。
推奨されるベスト プラクティスは以下のとおりです。
- 除外するディレクトリの数は最小限にする。
- 除外を定義するときはできるだけ正確に行う。
- 特定のファイルやフォルダーを除外する理由を YAML ファイルのコメントで説明する。
- 除外対象となったファイルとフォルダー、除外の理由をセキュリティ チームに報告する。
- 定期的に YAML ファイルをレビューする。
3. フォルダーがシークレット スキャンから除外されていることを確認する。
docs ディレクトリからリポジトリの readme.md ファイルを開きます。
ファイルの任意の場所に、次の無効になっている Azure DevOps PAT を貼り付けます。
pfnm5xd56muu7srpsme5jxeiwo23vuyavuyo2msziwy34ca7oaha
プッシュ保護からの警告なしで変更をコミットできるはずです。
リポジトリの [セキュリティ] タブで、サイドバーから [シークレット スキャン] を選択します。
先ほど readme.md ファイルに導入したシークレットに対して新しいアラートは表示されません。
次の項目: 依存関係レビュー構成をカスタマイズする
ここまで、最も一般的な CodeQL とシークレット スキャンのカスタマイズについて説明しました。次のガイドでは、依存関係レビューの一般的な構成の微調整について説明します。