シークレット管理は、仕組みや外のサービスに入るための鍵（シークレット）を、プログラムや共有の資料に書かず、決めた保管場所で管理することです。鍵には、API キー、パスワード、アクセス用のトークンなどがあります。鍵を知っている人は、鍵の持ち主として仕組みに入れます。漏れたときの被害が大きいので、置き場所、見られる人、取り替える手順を決めておきます。社員が覚えて使うパスワードは、パスワードの管理のアプリに置きます。シークレット管理が主に扱うのは、仕組みどうしが使う鍵です。
業務の仕組みでは、鍵をプログラムの本文に書かず、環境変数や .env と呼ばれる設定のファイルに分けて置くのが一般的です。Laravel の説明書は、.env のファイルを記録の置き場所（リポジトリ）に入れないよう書いています。置き場所に入り込まれたとき、鍵がそのまま見えるからです。GitHub の自動の処理（GitHub Actions）では、鍵を Secrets という保管場所に登録し、処理の中では名前で呼び出します。
よくある間違いは、共有のリポジトリに鍵を書いてしまうことです。あとから消しても、Git の記録には前の版が残ります。GitHub Docs は、鍵が入ってしまったら、まずその鍵を無効にするか取り替えるよう書いています。無効にすれば、漏れた鍵はもう使えません。鍵を発行したサービスの画面で無効にし、作り直した鍵を決めた場所に置き直します。鍵をチャットやメールで送ったり、AI への指示文に貼ったりするのも、同じ漏れ方です。
当社も、サーバーや外のサービスに入るための鍵は、資料やチャットに書きません。社内の資料に残すのは、どの鍵をどこに置いたかの名前だけです（パスワードの決まりの記事）。当社の WordPress の被害復旧でも、入口をふさいだあとに、データベースのパスワードとログインの状態を保つための鍵を変えます。