後続のコミットで削除されたとしても、プッシュされたコミットに含まれていた認証情報はすでに漏洩しています。セキュリティ機能は変更内容や履歴から認証情報を検出し、それらを一切保持せず、ローテーションまたは無効化されたと誰かが確認するまで各認証情報を未解決の状態として扱います。
スキャン対象
- すべての変更内容：各pull requestの変更内容が含まれます。
Coroid Securityチェック時およびCoroid自身のエージェントによる変更内容がコミットされる前にスキャンされます。 - デフォルトブランチ：各プッシュ時および履歴全体に対して1回スキャンされます。履歴スキャンはリポジトリが接続された時または「漏洩したシークレット」機能が有効になった時に開始されます。
- プルリクエストブランチ：pull requestブランチにプッシュされた認証情報も検出対象となります。なぜならその認証情報はすでにリポジトリ内に存在するからです。
pull requestが設定されていないブランチはスキャンされません。
履歴スキャンでは到達可能なすべてのコミットを最新のものから読み取り、各ファイルのバージョンを1回だけ確認します。スキャンは複数のセグメントに分けて実行され、中断した箇所から再開されます。各リポジトリには読み取れる履歴の量（コミット数、バイト数、時間、ファイルサイズ）に制限があり、この制限を超えるリポジトリでは履歴の一部のみがスキャン対象となります。
検出されるもの
既知の形式のプロバイダー認証情報（AWSアクセスキー、GitHubおよびGitLabのトークン、OpenAIキーなど）、認可トークン、以下のような名前で割り当てられた認証情報passwordまたはapi_key、秘密鍵、URL内の認証情報、およびエントロピー値が高い長い文字列です。コード内で割り当てられた認証情報は、その値がリテラルである場合にのみマッチし、変数や関数呼び出しの場合はマッチしません。
Coroidは決してその値を保持しません
検出された値は検出器から直接Coroidの認証情報ブローカーに送られ、そこでキー付きのフィンガープリントが返され、値自体は破棄されます。フィンガープリントのみが保存されます。これは組織ごとにキーが設定されているため、他の組織と比較したりオフラインで推測したりすることはできません。
シークレットが表示されるべき場所（検出結果、チェック、レビューコメント、ログなど）では、Coroidはルール名、長さ、位置のみを表示します。例えば[redacted secret: named_credential, 40 characters]のようにです。値の一部も、先頭の文字でさえも表示されません。
Coroidは検出した認証情報を実際に使えるかどうかを確認する試みを決して行いません。
1つの認証情報、1つの検出結果
複数のコミットで確認された認証情報は、複数の発生箇所を持つ1つの検出結果となります。2つのリポジトリに存在する同じ認証情報は、リポジトリごとに1つの検出結果となります。1つを確認すると、セキュリティ機能は同じ認証情報を持つ他の検出結果も一緒に表示し、まとめて確認できるようにします。ただし自動で行うことはありません。
シークレットは確認作業によってのみ閉じられます
コードから認証情報を削除してもその発生箇所はなくなりますが、検出結果は未解決のままです。以前にリポジトリを閲覧した人がその認証情報を入手していた可能性があるからです。所有者または管理者が以下の内容を確認した場合にのみ閉じられます：
- ローテーション済みまたは無効化済み；
- 実施日;
- 任意の備考。
セキュリティ機能は確認者と日時を記録し、検出結果に表示します。「10月28日にローテーションされ、10月29日にAlexが確認しました」といった具合です。その後検出結果はローテーション確認済み。
漏洩したシークレットの修正方法
チェックリストタスクを作成するプロジェクト内に以下の手順を含むタスクが作成されます：
- プロバイダー側で認証情報をローテーションまたは無効化する。
- プロジェクトが認証情報を管理する場所に移動させる。
- コードから認証情報を削除する。
- セキュリティ機能でローテーションを確認する。
このタスクは繰り返し実行されたり、認証情報を試したりすることはありません。Gitの履歴を書き換えることもありません。履歴から認証情報を削除するかどうかはチームの判断であり、それによって漏洩した認証情報が安全になるわけではありません。
実際の認証情報か、問題なしか
シークレットの検出結果が表示された際、所有者および管理者は「これは実際の認証情報でしたか？」と答えます。これは実際の認証情報でしたか？
- 実際の認証情報確認されるまで検出結果を未解決のままにします。
- 問題なし検出結果を非表示にする偽陽性例外が記録されます。例えばテスト用データの場合などです。実際の認証情報その例外が再度解除されます。
これらの回答は検出器の調整にも役立ちます。
ブロック機能
「漏洩したシークレット」機能はデフォルトで監視モードで動作します。検出器の調整が完了し、強制適用が有効になって初めてブロックが行われます。詳細は保護と強制適用。
以前のシークレットスキャン機能を組織ポリシーで有効にしていた組織では、新しい検出器がキャリブレーションを完了するまで、該当する検出器バージョンによって引き続きブロックが発生します。この以前のスキャンでは検出結果は生成されないため、例外設定や証明書を使用してもブロック対象を隠すことはできません。
組織のデフォルト設定では、新規シークレットをブロックおよび最も大きな変更内容が「漏洩したシークレット」に分類されてスキャンされます。
通知
シークレットに関する検出結果からはまだ通知が送信されません。これらは「セキュリティ」→「検出結果」および「概要」に表示されます。
GitHub シークレットスキャン
リポジトリで GitHub 独自のシークレットスキャン機能が有効な場合、セキュリティ機能でそのアラートをインポートできます。GitHub のシークレットスキャンアラートは、GitHub 上で誰かが解決するまで開いたままとなるため、修正内容をマージしてもそこでは閉じられません。詳細はGitHub セキュリティアラート。