ハードコードされたシークレットとは? 決して commit してはいけない認証情報

ハードコードされたシークレットとは、ソースコードや config に直接書かれたパスワード、キー、トークンであり、リポジトリ(あるいは git 履歴)にアクセスできる者なら誰でも読めてしまいます。

シークレットのハードコードは便利に感じます。キーを貼り付け、コードを出荷し、次に進む。問題は、ソースコードが広がることです。クローンされ、fork され、バックアップされ、履歴に永遠に残ります。一度 commit されると、シークレットはリポジトリに到達できるすべての人にとって実質的に公開状態になり、履歴からの削除は困難です。

どのようなものか

ハードコードされたシークレットとは、JavaScript ファイル内の API キー、YAML config 内のデータベースパスワード、あるいはリポジトリに commit された shell script 内のトークンです。実行時に注入される代わりにバージョン管理内に存在する、あらゆる認証情報です。

なぜ危険か

• リポジトリに読み取りアクセスできる者なら誰でも使える。
• 行を削除した後も git 履歴に残り続ける。
• fork、クローン、バックアップがそれをあらゆる場所にコピーする。
• 公開リポジトリは数分以内に自動スキャナーにそれを露出させる。

git 履歴の罠

新しいコミットでハードコードされたシークレットを削除しても、それは取り除かれません。古い値は依然として履歴に残り、簡単に復元できます。唯一の本当の修正は、シークレットをローテーションする(焼き切れたものと見なす)ことと、必要なら履歴を書き換えることですが、後者は破壊的です。

回避する方法

シークレットは、commit されたファイルからではなく、環境変数やシークレットマネージャーから実行時に注入します。キーファイルのパターンを .gitignore に追加し、secret scanning を使ってミスが merge される前に捕捉します。

自動的に捕捉する

シークレットスキャナーは CI 上および push ごとに実行され、認証情報らしきものを検出します。pre-commit フックと組み合わせることで、ほとんどのハードコードされたシークレットが共有ブランチに到達する前に止められます。

重要なポイント

• ハードコードされたシークレットは、ソースコードや config に commit された認証情報である。
• git 履歴に永遠に残り、クローンや fork を通じて広がる。
• シークレットは実行時に注入し、scanning を使って merge 前にブロックする。

関連ガイド