ベッキー・ブラッケン
そして「Dark Reading Confidential」へようこそ。これはDark Reading編集部がお届けするポッドキャストで、サイバーの最前線から現実世界のストーリーを直接お伝えします。ホストのベッキー・ブラッケンです。本日は幸運にも同僚のロブ・ライトに参加してもらっています。ロブは、今日取り上げるテーマである「シークレット・クリープ」について、Dark Readingの主任記者として取材をリードしてきました。より具体的には、機密性の高い企業情報がソフトウェア開発プラットフォームに投入されているという話です。ロブ、これは妥当な見立てでしょうか？
ロブ・ライト
はい、妥当です。おそらくそれ以上に広範に広がっていると思いますが、出発点としては良いと思います。
ベッキー・ブラッケン
よし、いいですね。では、その話を聞きましょう。そして専門家の皆さんの話も聞きましょう。本日は、Watchtowerの主任セキュリティリサーチャーであるジェイク・ノット氏、Oasis Securityのリサーチエンジニアであるエレズ・シュワルツ氏、そしてGitGuardianのCMOであるキャロル・ウィンクイスト氏にご参加いただきます。サイバーセキュリティの専門家であるこの3名は、
シークレット・クリープが起きていること、それが現実であること、そしてそれを止めるためにできることがあることを突き止める画期的な取り組みをしてきました。そうですよね、ロブ？
ロブ・ライト
そうだといいんですが。本当にそうだといいですね。
ベッキー・ブラッケン
では、この問題をもう少し理解できるように助けてください。
ロブ・ライト
ええ。ここは専門家のキャロル、ジェイク、エレズに委ねたいところですが、状況としては、数年前から、パスワードやシークレットキー、認証情報、機微情報が、ソフトウェアリポジトリやソフトウェアサプライチェーン、CI/CDパイプラインなどに少しずつ入り込んでいく、という話を耳にしていました。ただ、問題への注目が高まり、研究も確実に増えているにもかかわらず、問題はむしろ悪い方向に進んでいるように見えます。シークレットが増え、問題が増え、拡散も広がっている。現状の説明として正確でしょうか？
どなたでも、最初に話したい方からどうぞ。
キャロル・ウィンクイスト
ええ、それを裏付ける数字があります。私たちは毎年「シークレット拡散の現状」レポートを出していますが、これは増え続けています。昨年は公共空間で2,300万件のシークレットを見つけました。これは前年よりも大幅に多いです。2025年の数字はまだ集計していませんが、皆が保護しようとしているとしても、さらに増えると予想しています。おっしゃる通り、シークレットはあらゆる場所に拡散します。残念ながらコードだけではなく、JIRAやSlackにも広がっており、こうしたツール経由の攻撃は私たちが思う以上に起きています。
ロブ・ライト
なるほど。ジェイク、あなたはどう見ていますか？
ジェイク・ノット
ええ、間違いなく同意します。今は多くの開発者や組織が、いわゆる悪名高いツール――Gitリポジトリ、Dockerコンテナ、Postmanワークスペースなど、オンラインで悪名が広まったもの――に潜むリスクを理解しています。そして、それらのリスクを軽減するためのツールや組織も数多くあります。拡散がどんどん大きくなっているだけでなく、もしかすると以前からずっとそうだったのかもしれません。私たちがより多くの場所を見るようになり、これまで誰も見てこなかったものを掘り起こしているだけです。そうすると、実際には「狙いどころが豊富な環境」だと分かります。探しに行けば、あまりにも多くのものが見つかる。私が掘り下げたツールのいくつかでは、主にオンラインのコードフォーマッタや、開発者が使うオンラインツールに焦点を当てましたが、そうしたものはこれまで同じような注目を受けてきませんでした。いわば無法地帯で、事前コミットフックや既存研究などの恩恵も十分ではありません。本当に、シークレットが至る所にある無法地帯のような状態です。
ロブ・ライト
ふむ。
キャロル・ウィンクイスト
ええ、モバイルの世界はさらにひどいです。おっしゃる通りです。
ロブ・ライト
では、この機会に言っておきますが、できるならポッドキャストは前向きなトーンで終えたいんです。だから、ネガティブで憂鬱な話は、最初に片付けてしまいましょう。そして最後には、可能なら明るい楽観にたどり着ければと思います。エレズ、あなたは何を見ていますか？
エレズ・シュワルツ
まあ、ジェイクやキャロルとほぼ同じです。たくさん見ます。APIキーのようなものも含め、さまざまなものを見ます。中には、従業員の一覧――従業員のメール、電話番号、住所、社員番号など、全部入りのリスト――が誤ってコミットされているケースも見ました。これは明らかに、本当に本当にまずいです。
そして、私の視点から、またAI関連の多くを見ていて思うのは、どこかの時点でAIの話は避けられませんが、CursorやWindsurfのようなものが自動でコミットしたり、そういう作業を大量に行ったりするようになると、コミットされるシークレットはさらに増えていく、ということです。
ロブ・ライト
ええ、信じてください、AIの話は大きく取り上げます。私の疑問は、どうしてここまで来てしまったのか、です。どうして、
多くの人が「こういうものを置いてはいけない」と分かっているように見えるのに――開発者なら、開発チームなら、コードやリポジトリ、パイプライン、Salesforceインスタンスなど、あらゆる場所でシークレットを露出させたくないはずなのに――結局それがそこに入り込んでしまう。なぜ起きていると思いますか？
キャロル・ウィンクイスト
最小抵抗の道だからだと思います。つまり、速く進めたい。AIの話が出ましたが、私たちも現場で議論していました。最終的にシークレットを増やすのはAIではなく、人です。速いから、何かをテストしたいから、「あとで置き換えよう」と考えるから。あるいはもっと悪いのは、置き換えたのにGitHubアカウントの履歴を忘れてしまうことです。彼らは、そういう点を見落とします。
訓練された開発者であっても、いくつかのことを見落とします。だから多くは人為的ミスです。そして、人が追加し、システム側もキーがどんどん増え、扱う数が多すぎて、Vaultに入れなければならない、いろいろ面倒な手順を踏まなければならない。だから急いでコードに入れてしまい、その後忘れる、あるいは部分的にしか修正しない。そういうことだと思います。
ロブ・ライト
ふむ。
ジェイク・ノット
ええ、間違いなく同意します。いくつかの要因があると思います。重要なのは摩擦です。社内で物事を進めるためのツールや権限がなく、何かを承認してもらうために膨大な手順を踏まなければならない。ツールをダウンロードするのにも、これをするのにも。そんなとき、Googleで探してツールを見つけて、さっとやってしまえばいい。多くの場合、単に利便性のためです。
ロブ・ライト
ジェイク、うなずいてますね。
ジェイク・ノット
多くの場合、悪意はなく、意図的でもありません。誰も朝起きて「オンラインツールにシークレットを漏らしてやろう」と思って一日を始めるわけではない。多くの場合、ただ仕事をしようとしていて、速く、うまくやろうとしていて、最小抵抗の道だからこうしたツールを選んでいるだけです。
そして、私が見てきたシークレット漏えいの組織を見ても明らかなように、最大級で重要な組織――政府、金融機関、巨大なセキュリティチームと高い成熟度を持つ組織――から、最小の個人開発者や中小企業まで、誰も免疫はありません。結局は「ちょっと便利だから」という瞬間が原因になり得ます。
キャロル・ウィンクイスト
それと「安全だという錯覚」もあると思います。公共空間では人はより慎重ですが、社内、つまりリポジトリやJIRA環境だと、「JIRAチケットにAPIキーを入れて何が問題なの？誰も私のJIRAチケットにアクセスできないでしょ」と考える。でも結局、アクセスされます。つまり「壁の内側にいる」「城の中にいる」「誰も見に来ない」という誤った安心感です。
ロブ・ライト
興味深いですね。エレズ、あなたの視点では、こうしたミスをする人たちは、もしかして単に知らないだけなんでしょうか。もちろん頭の中を覗くのは難しいですが、どこに情報を置いているのか、その影響を理解しておらず、リスクがこれほど高いとは分かっていない、ということはありますか？
エレズ・シュワルツ
確かにあると思います。特にJIRA、Slack、Teamsのような社内システムの話になると、人は「自分の要塞」だと思っている。まさにジェイクとキャロルが言った通りで、彼らは「もっと分かっているべき」なのかもしれません。もちろん分かっているべきですし、私たちも教え方を改善すべきですが、組織全体が社内ツールをそう捉えるのは、ある意味で起こりやすいです。
ただ、GitHubを見て、公開リポジトリに置いている人たちについては、ほとんどは悪意がないとしても、開発者として公共空間に置く以上、もっと分かっているべきだと思います。しかもそれが「公開」と分類されていて、プライベートリポジトリではないわけですから。そういう例もたくさん見ています。また、あるものが本当にシークレットかどうか分からない場合もあります。APIキーかもしれないし、テスト用トークンかもしれない。これは私たちが顧客向けに調査する際の課題でもあります。テストキーなのか、本番で、漏れると多くのものが壊れて適切に扱う必要があるものなのかを見極める必要がある。だから、そういう人たちや、私たちが見た一部のケースでは、個人アカウントを社内のクラウド環境に接続し、そこにリポジトリをつないでいた人がいました。その特定のケースでは保護されていて実際に侵入できるわけではありませんでしたが、見たときに「それは接続されるべきではない」と思いました。だから、そこにはガードレールが必要です。
キャロル・ウィンクイスト
でも、あなたが説明したことは、私たちが公開漏えいを分析するたびに見ている典型例です。問題はGitHubの仕組みそのものにあります。個人の開発者は、個人用のものも会社のものも、すべて1つのアカウントで扱いがちです。そうすると、会社のコードを自分のリポジトリにコピーしてしまい、時にはそれを公開にしてしまう、というミスがとても簡単に起きます。会社のコードにAPIキーが含まれたまま、ということもあります。これは毎日のように見つかります。つまり、個人プロジェクトと（個人ではない）ビジネスプロジェクトの両方を同じ場所で作業している、という性質そのものが原因だと思います。
ロブ・ライト
では、この拡散――露出したシークレットや機微情報の増加、そしてGitHubやCI/CDパイプラインだけでなくSalesforceやTeamsのチャットのような場所にまで広がること――は、単に一般的にシークレットが増えている、つまり人々が扱うデータが増えている、ということの結果なのでしょうか。ええ。
キャロル・ウィンクイスト
ええ。ええ。ええ。ええ。なぜなら、必要になるからです。マイクロサービスがまず爆発的に増え、今はエージェントです。彼らは複数のシークレットを同時に扱いますよね。だから、「シークレットレスでエージェントをやろう」と言うこともできたはずです。そういうことを助ける技術もあります。でも残念ながら、私たちは昔ながらのAPIを選びました。
その結果、今爆発的に広がっている技術と、私たちが使っているシステムそのものによって、シークレットの利用が増殖しているのを目にしています。だから、より洗練された、SPIFFEに着想を得たようなシークレットレス・アーキテクチャへ移行しない限り、止まらないと思います。ただ、そこに到達するにはまだ長い道のりがあります。
ロブ・ライト
つまり、シークレットが増えている、と。そしてAIのせいにできる部分も大きい。ジェイク、あなたはそれが問題の大きな部分だと思いますか？アプリやマイクロサービス、プラットフォームが増えたことで要求が増えている、という点は。
ジェイク・ノット
それは確かに一部だと思います。とても興味深い問題で、引っ張れる糸がたくさんあります。要因の一つは、私たちが「適当なツールに何かを入れると何かが返ってくる」ということに慣れてしまっている点だと思います。「これが日常だ。ツールAに入れると出力Bが返ってくる」。そして将来的には、その一部が追加の問題に寄与するようになると想像します。今分かっているデータソースだけでもそうです。
1年、2年、5年と経てば、データソースは増え続け、シークレットや認証情報、人々が使っているのに気づいていないものの「すごい宝の山」が見つかるだけでしょう。特に、話題のAIもそうですが、こうしたツールを使って、考えずに質問してしまう。そこに情報を入れてしまう。あるいは、また利便性の話に戻りますが、何かを素早くやる必要があるから、シークレットをマスクせず、認証情報を削除せずに、さっと貼り付けてしまう。「どこにも行かない」「他に出ない」と思って。でも後になって、どこかでオンラインに出たり、公開インデックスされたりする。ええ、これは増えていくと思います。
キャロル・ウィンクイスト
そしてロブ、人々が正しくやっていたとしても、たとえば環境変数に入れるなど正しい場所に置いていても、最近のShy Vouloudキャンペーンのようにハッキングされることがあります。実際に起きたのはそれです。ハッキングされた人たちは、シークレットを正しい場所に置いていました。それでも、攻撃者が侵入し、いわゆるシークレット・ファインダーがノートPC上で見つけられるものを片っ端から収穫したのです。
ロブ・ライト
なるほど。
キャロル・ウィンクイスト
だから、正しくやっていても完全には守られません。攻撃者は賢く、シークレットが組織に侵入する道だと知っていて、収穫しようとしています。あなたが言っていた通りです。私は2つあると思います。第一に、シークレットが増えている。はい。第二に、攻撃者が理解し、今ではツールも持っていて、収穫を大規模に行い、それを横展開や組織内に留まるために使い、攻撃をより強力にしている、ということです。
ロブ・ライト
ええ、これはメディアの人間としていつも抱く疑問です。シークレットの露出についての記事を読むたびに、セキュリティ研究者やサイバーセキュリティベンダーが、さまざまな組織で露出したシークレットの宝庫を見つけたという話――WatchtowerでもGitGuardianでも――を読むと、最初の疑問は「これらのシークレットのうち、どれだけが脅威アクターに入手され、悪用されたのか」です。どの程度の割合が、少なくとも不正なアクターに入手されたり、実際に使われたりしていると判断しますか？誰も悪用していないと考えるのは愚かに思えます。なぜなら、今や連中が探しているのは明らかだからです。
彼らはそれを仕事にして、シークレットを入手して使っています。とにかく、エレズ、あなたから始めましょう。脅威アクターによってシークレットが悪用されている可能性を、何らかの形で判断したり、見積もったり、推定したりする方法はありますか？
エレズ・シュワルツ
Oasisでは、私たちの顧客の一部で、既知の漏えい認証情報に対する試行を見たことがあります。試行があれば私たちも見えますし、顧客にアラートできます。ただ、割合を出すとなると分かりません。でも直感としては、「見えるし、起きている」です。インターネット上に公開されているものがあって、それを私たちが見ているなら、私だけが見ているはずがない。確実に、他の人が使っているのを見ますし、脅威アクターがいるのも確実です。
ロブ・ライト
ええ。
キャロル・ウィンクイスト
ええ、ロブ。シークレットの本質は「正当なアクセスポイント」だということです。だから調査の難しさは、悪意ある利用と正しい利用をどう区別するか、という点にもあります。方法はありますが、とても難しい。だから攻撃者はシークレットが大好きなんです。永続性を得られ、正当なアカウント、正当なアイデンティティ、正当なシークレットの背後に隠れられるからです。割合は分かりませんが、確実に使われています。私たちは毎月、Slackのシークレットや、あちこちのシークレット経由でハッキングされた顧客が出てきます。すべてが使われるわけではないにせよ、いくつかは使われる。そして企業が気にするには十分です。
ロブ・ライト
なるほど。ええ、ざっくりの目安を考えていたんです。コップ半分空か、半分満ちているか。できれば「半分満ちている」、つまり大半のシークレットは悪用されていない、と信じたいんですが、でも私は…
キャロル・ウィンクイスト
はい、大半は使われていないと思います。あなたの言う通り、大半は使われません。何らかの仕組みで保護されていれば、かなり速くローテーションできるので、機会の窓は非常に狭いです。でも問題は、1つで十分だということです。この世界の問題はそこです。
ロブ・ライト
ええ。ええ、分かります。ジェイク、あなたはどうですか？この点について、コップ半分空、半分満ちている、どちら寄りですか？
ジェイク・ノット
良い質問です。数カ月間シークレットと認証情報の海を泳いできた身としては、時々、前向きでいるのが難しいです。私も同意します。
多くの場合、残念ながら「侵害されたと仮定すべき」だと思います。そうでない証拠がなくてもです。入手され得る仕組みや方法があまりにも多いからです。現代の攻撃者が組織に侵入する現実は、アイデンティティベースの攻撃です。デフォルトや弱い管理者認証情報でそのままログインできるか？盗まれたトークン、認証情報、キー、シークレットを使ってログインし、ユーザーになりすまして通常の操作を行えるか？脆弱性を突いてノイズを出し、異常を作って捕まるよりも、です。
ロブ・ライト
なるほど。
ジェイク・ノット
攻撃者が関心を持っていることは分かっています。近年のデータでも裏付けられています。そして攻撃者が実際にやっていることも分かっています。こうしたオンラインのコードフォーマッタツールを掘り下げる中で、私は偽のカナリア認証情報をそこに公開してみました。私が最初に思いついたのか？という検証です。答えはもちろん違いました。そうしたツールに認証情報を公開してから48時間以内に、それが利用されるのを確認しました。特に興味深いのは、これは十分に活用されておらず、あまり知られていないプラットフォームだということです。少なくとも私がブログ記事で公開する前は、広く知られていませんでした。GitHubのような高リスクのプラットフォームと比べると、あちらは漏れればさらに速く悪用されます。
キャロル・ウィンクイスト
数分です。私たちもハニートークンで同じテストをしました。公開GitHubに置くと、数分以内に悪用されます。
ロブ・ライト
ええ、以前ハニートークンの話をしてくれましたよね…。ええ、数分。では、どうぞ。
キャロル・ウィンクイスト
ええ。ちなみに、ハニートークンは警告を受ける良い方法です。ジェイク、リポジトリやCI/CDのあちこちにハニートークンを仕込んでおけば、たとえばShia Lutの件でも、攻撃者が有効性をテストするのでアラートが発火し、警告を受けられたはずです。だから、解決策を探している企業にとっては、もちろん事前コミットフックなど私たちが話すものもありますが、ハニートークンも組織を守る非常に良い方法です。少なくとも侵害されたことを知り、アラートを受けたらすぐにローテーションできます。
ジェイク・ノット
ええ、今日の世界では、攻撃者が防御側と同じパイプラインを複製して漏えいを検知していない、なんて考えるのは甘いと思います。ほぼリアルタイムのイベントストリームを監視し、公開されたばかりのものを列挙し、できるだけ速く悪用する。私たちは時々、攻撃者にも同じプロセスを複製して追いつき、できるだけ速く動いているという点で、ある程度の評価を与える必要があります。そして現実として、
キャロル・ウィンクイスト
ええ。
ロブ・ライト
うんうん。
ジェイク・ノット
私たちの緩和策の多くは、結局のところ「既知のシークレット」を認識するところまでしかできません。私が見た中で最も興味深く機微なデータの一部は、既知の形式に一致せず、APIキーや既知プラットフォームの認証情報だとも分からず、追加の文脈、調査、理解が必要でした。そして突然、全体像が見えて「うわ、これは…これはすごい」となる。あるいは、PIIがツールに入れられていることの特定などもそうです。
ジェイク・ノット
シークレットではないこともありますが、同じくらい価値があります。
キャロル・ウィンクイスト
でもロブ、私たちが見つけるシークレットの大半は、私たちの用語で「汎用シークレット」と呼ぶものです。テキストや数字の文字列で、文脈化がとても難しい。でも一度アクセスできれば非常に強力になり得ます。残念ながら、公開GitHubで見つかるものの大半がこれです。そして多くの検知器は、これを検知するのが得意ではありませんよね。誤検知も多い。だから私たちは、この見つけにくく、評価や深刻度付けも難しいタイプのシークレットに特に力を入れてきました。
ロブ・ライト
ええ、ここで少し立ち止まりたいです。皆さんそれぞれ、この問題を深掘りして研究してきたと思います。そこで、もし可能なら、ある特定の案件や組織でシークレットを見つけて、どんな理由であれ警鐘を鳴らしたくなった例を1つ挙げてもらえますか。シークレットがどこに行き着いていたか、データ量がどれほどだったか、露出の仕方がどうだったか。とにかく、この問題がどれほど深刻かを痛感させた例、そして聴衆に「なぜこれが重要なのか」を示せるようなケーススタディです。エレズ、あなたからお願いします。
エレズ・シュワルツ
たぶん、従業員名の一覧が丸ごと入っていた件に戻ると思います。フルネーム、メールアドレス、全部です。私たちが調べ始めたときに見つけた最初期のものの一つだったので、どうしてもそれが印象に残っています。私にとっては、ソーシャルエンジニアリングの世界ともつながる話でした。厳密にはシークレットではないかもしれませんが、攻撃者がそのデータを持つことで大きな力を得られる。そして、簡単に元に戻せるものでもありません。全従業員の電話番号を全部変えるなんてできない。どう対処するか考えるのも本当に難しい。だから、私にとってはそれが一番大きかったです。
ロブ・ライト
興味本位ですが、連絡したときの反応はどうでしたか？
エレズ・シュワルツ
私は連絡していません。会社の別の人たちが対応しました。ただ、記憶ではショックでした。「まさか」という感じで。もちろん「ありがとう」と言われましたし。彼らがどんな対応を取ったかは覚えていませんが、当然、削除して、もうそこにないことを確認したはずです。
ロブ・ライト
なるほど。ええ、それは少なくとも良い出発点ですね。キャロル、あなたはどうですか？
エレズ・シュワルツ
ええ。
キャロル・ウィンクイスト
戦場の話は山ほどあります。いくつか思い浮かびます。最近のものではないですが、規模が大きいものもあります。たとえばLapsus$グループを覚えていますか。ある時点で彼らは侵入し、たしかUberだったと思いますが、あらゆるところに入り込みました。コードだけでなく、コードを公開までしました。Slackにも入り、コードが公開になった。MicrosoftやSamsungなど、当時いくつかの企業がありました。これらの企業は、ジェイクが言ったように非常に強力なセキュリティチームを持っています。それでも、たしか18歳の少年が、シークレットを使って侵入したんです。Tという、Vaultのようなものを見つけて、基本的に宝石箱――クラウンジュエル――を見つけ、そこからあらゆるところに入った。あれが最悪の話だと思います。
でも、私たちには日常的に企業から連絡があります。Slackの例を出しましたが、大手自動車メーカーがSlack経由でハッキングされました。攻撃者がSlackチャンネル内のシークレットを見つけ、そこから顧客データベースなどに入ったのです。あなたが言ったように、大量のデータです。
こうしたケースは常にあります。長期間生き続けるシークレットの例もあります。たとえばToyotaでは、サードパーティのコンサルタントが5年前の長期シークレットを公開してしまい、攻撃者が組織に侵入できたことがありました。あと、大きなカジノもありました。昨年だったか、シークレット経由でハッキングされ、生産（業務）が危険にさらされ、数日間停止せざるを得なかった。これは
大金の話です。一定日数、稼げなかったわけです。だから例は本当にたくさんあります。興味があれば、私たちのウェブサイトに一覧がありますが、残念ながら繰り返しで、影響はたいてい2つに集約されます。1つ目はデータです。エレズが言ったように、人々のデータ、顧客データ、医療データへのアクセス。2つ目は本番環境です。これは避けたい。会社に多大なコストがかかるからです。
ロブ・ライト
カジノを数日間オフラインにして稼げなくできるなら、相当ひどいことをやらかしてますよね。ジェイク、あなたはどうですか？
ジェイク・ノット
ええ、良い質問です。キャロルが言ったような、初期侵入やデータアクセスを可能にする高インパクトな例はたくさんあります。でも私にとって、人間的なレベルで最も影響が大きいのは、そのデータが、コントロールできないユーザーに影響するケースです。彼らはそれがそこに行き着いた理由ではない。ある例として印象に残っているのは、
ロブ・ライト
ええ、あなたのレポートには良い例がいくつかありましたね。
ジェイク・ノット
HRプラットフォームのエクスポートです。あなたが求人に応募したり、組織で働いていたりして、HR管理者があなたの機微情報をそのプラットフォームに公開してしまう。そして第三者経由で知ったり、自分の名前を検索したときに、生年月日、住所、機微情報、パスポート番号などがインターネット上に出ているのを見つけたりする。私にとっては、これが最も影響が大きい。あなたはそれをコントロールできないし、あなたのせいではない。そして、特に一部の番号は不変で、パスポート番号のように簡単にローテーションできないので、対処が本当に難しい。
ロブ・ライト
そうですね。自分のデータがどこにあるか分からず、露出していても気づきようがない、というのは特に怖い状況です。では、この急降下から機体を引き上げて、前向きな方向に進みましょう。皆さんは、何をすべきだと思いますか？何ができるでしょうか？
組織がシークレットの露出を防ぐために、最初にやるべきことは何でしょう？こうしたミスを防ぐために、まず導入すべきプロセスやポリシーはありますか？
キャロル・ウィンクイスト
ええ、間違いなくあります。私たちは「シークレット管理成熟度モデル」と呼んでいます。基本的に、組織の複雑さに応じて始めるべきです。まず最も重要なのは、これは人とツールのプロセスだということです。組み合わせです。人を訓練し、開発者――シニアもジュニアも全員――にまずリスクを教育する必要があります。
彼らは知っていますが、ジェイクが言っていたような摩擦を取り除き、シークレットへのアクセスをできるだけ簡単にして、「大変な頭痛の種」にならないようにする必要があります。次に、フックやIDE内の検知器などを用意します。コーディング中にシークレットをコミットしようとしたらベルが鳴って、「本当にこれをやりますか？」と促す。つまり、ミスをするときに逆方向の摩擦を加えるんです。そうすれば、正しくやることがより反射的になります。次に、組織にVaultや、シークレットを適切に保管する場所を用意します。単なる環境変数ではなく、です。
そして、複雑さに応じて上へ上へと進み、誰もがそこに行き、そこに入れなければならない、というVaultや保管場所を追加していきます。さらに第三の層として、銀行のようにVaultと警報システムがあるように、警報システムと監視システムが必要です。つまり、シークレットがどこにあるのか、それが何にアクセスできるのかを把握する。衛生状態は良いか、適切にローテーションされているか、何にアクセスできるのか。これをローテーションしたら本番が止まるのかどうか。こうしたことすべてです。これが、より成熟した状態だと言えます。
そして本当に最高を目指すなら、シークレットレスな組織です。先ほど言ったように、シークレットレスを導入し始めている企業もあります。長い旅で、とても…導入は複雑ですが、理想的には、システムが接続する瞬間のためだけに一時的にシークレットが生成され、その後自動でローテーションされる、という形です。これは出始めていますが、ええ、私にとってはそれが前進の道だと思います。ただ、組織を守る方法は他にもたくさんあります。
ジェイク・ノット
ええ、もちろんです。挙げられた点には強く同意します。私にとって大きいのは、認知、ユーザー教育、適切なプロセス、適切なポリシーを整え、摩擦をなくし、そもそも起きる可能性を下げることです。そして、適切な文化を持つこと。質問できる、立ち止まって「本当にこれが最善のやり方か？」と言えること。
議論すること、同僚とオープンに「もっと良くできないか？」と話し合うことは、協力して防ぐうえでとても良い方法だと思います。最後の点としては、起きてしまったときに対応するプロセスを用意することです。現実には避けられません。最大のシークレットから最小の小さな痕跡まで、機微情報を誤って漏らす方法は無限にあります。
もし起きてしまったら、対応して、できるだけ速く、影響を最小限にして復旧するプロセスが重要です。そしてまた文化の話に戻ります。「うっかりこれを漏らしてしまった」と言えること、そしてすぐに対処を始められることが、本当に重要です。
ロブ・ライト
エレズ？
エレズ・シュワルツ
完全に同意します。付け加えるなら、過去の攻撃から学ぶための会話をすること、そして実例を通じて教育し、現実世界の結果への理解を深めることが役立つと思います。他人の失敗から学ぶ、ということです。ここで議論された他の点すべてに加えて、ですが、私も完全に同意します。
ロブ・ライト
では、ここで締めに向けて、状況を直す・改善するという話の中で触れたいことがあります。シークレット拡散を減らし、露出するシークレットを減らし、拡散を減らす。ジェイク、あなたは文化の話をしましたね。良い対応、そして組織内で「自分がやらかしたかもしれない」と言える人がいて、それに対処できること。そこで思い出したのが、セキュリティ研究者からシークレット露出やデータ露出の連絡を受けた組織が、非常に攻撃的になったり、時には意地悪になったりする話を何度も聞いてきたことです。
そこで皆さんの視点を聞きたい。そういうことを見たことがありますか？今でも、企業がそれを軽く扱ったり、あなたに対して意地悪になったりすることはありますか？それとも、企業が自分たちの露出したデータやシークレットにどう対応するかという点で、より啓発された時代に移行しつつあるのでしょうか。良くなっていますか？
キャロル・ウィンクイスト
あります。すみません、あまり前向きな話ではないですが、あります。私たちの会社にはジェイクや、エレズのようなセキュリティ研究者がいて、ディオムやガエタもいます。彼らは多くの、いわゆる責任ある開示（responsible disclosure）を行っています。私たちのプロセスでは多くのものが見つかるからです。そして責任ある開示を行うのですが、よくあるのは「バグバウンティを通してくれ」と言われることです。
ところがバグバウンティ担当者がそれが何か分かっていない。そして私たちは、無視されるか、「大したことない」と言われるか、相手が何を言っているのか分かっていない、という板挟みになります。これが最悪です。一方で、本当に良い企業もあります。私たちをウォール・オブ・フェイムに載せてくれて、心から感謝してくれる。だから本当に両極端です。そしてShai-Huludの件では、初めて、25%の返信率がありました。これは通常の、同様の大量の責任ある開示と比べても非常に高いです。今回は400社に連絡しました。
これほどの反応があったのは初めてです。シークレットがCISOやセキュリティチームのアジェンダでより上位になってきているのだと強く感じます。Singularity、Ghost Action、Shai-Hulud 1、Shai-Hulud 2が数カ月のうちに繰り返されているのを見ているからです。8月に始まって、加速しています。だから、6カ月前よりも今のほうが問題を認識しているのかもしれません。分かりませんが、率直に言って、今回の反応率には驚きました。ただ、通常は、多くの組織で適切な担当者にたどり着くこと自体が戦いです。
ロブ・ライト
聞いてください、私はどこからでも楽観を拾いたいんです。だからその25%はありがたく受け取って走ります。とても嬉しいです。エレズ、あなたはどうですか？つまり、企業はより反応が良くなっていますか？より責任ある対応をしていますか？あなたがやっていることが、彼らのシークレットやデータ、ユーザーデータを盗もうとしているわけではないと理解していますか？そして、従業員データの例のように、適切に反応していますか？
エレズ・シュワルツ
会社によると思います。すべての会社を一括りにするのは難しいです。顧客なのか、見込み客なのか、あるいは調査中に見つけて「誰が適切な担当者か」を探しているだけの会社なのか。キャロルが言ったように、そうしたものを全部まとめてしまうと難しい。とはいえ、気にしている会社は多いと思います。コップ半分満ちている側としては、気にしていて、責任を持って正しいことをし、私たちと話し、関与して、何が起きているのか、どう直すのかを理解しようとしてくれる会社がある。でも一方で、「これは重要じゃない」「現実じゃない」「話しかけるな」といった反応をする会社もあります。それも起きます。
ロブ・ライト
うーん、あるいは「バグバウンティを通してくれ」ですね。そもそもバグじゃないし、脆弱性でもないのに。ジェイク、最後にあなたです。楽観と前向きの波に乗せて締めてください。
エレズ・シュワルツ
ええ。
ジェイク・ノット
はい。
できる限り頑張ります。言われたことには強く同意します。私の経験でも、コードフォーマッタの発見を開示する際の結果は大きくまちまちでした。責任ある形で対応してくれる組織もあります。ほぼ即座に返事が来て、すぐに対応し、徹底的に取り組む。これは本当に素晴らしいことで、真剣に受け止め、必要なことを行い、修正してくれるのを見るのはとても良いです。そして多くの場合、非常に感謝されます。それを見るのは本当に良いことです。
ロブ・ライト
うんうん。
ジェイク・ノット
一方で、バグバウンティに回され、提出してもスコープ外だったり、いろいろ複雑だったりする例もありました。まったく返事がない組織もありました。難しいですね。
報告を受け取る組織の立場に立ってみると、組織にはあらゆる経路で連絡が来ます。適切な連絡先ではないこともあるし、実在しない脆弱性や、単に小さなバウンティを得たいだけの人もいる。あるいは、あなたのWebサーバーのバージョンが古い、といった話で、実際には悪用可能な弱点ではないこともある。だから、責任ある開示の報告に対して「またそういうやつだろう」と身構えてしまう人がいるのも分かります。だから難しいこともあります。
ロブ・ライト
ふむ。
ジェイク・ノット
高インパクトなもの、責任ある開示で伝えるべき良い情報が、適切な人に届くようにすることが重要です。私たちは、研究結果を各国のCERTチームに開示し、彼らが関係組織に展開してくれる、という素晴らしい経験をしました。地元政府からメールが来れば、金銭的利益を得る動機もなく、別の意図もない。多くの場合、それが本当に有用で、できるだけ速く修正する助けになります。
ロブ・ライト
なるほど。
キャロル・ウィンクイスト
ええ、CERTは同じ経験です。別の脆弱性で大規模なキャンペーンをやったばかりですが、とても助けになりました。
ジェイク・ノット
ええ、同意します。
ロブ・ライト
つまり、迷ったらCERTへ、ということですね。今後の参考になります。では皆さん、本当にありがとうございました。キャロル、ジェイク、エレズ、お時間とご意見に感謝します。時に憂鬱でしたが、とても啓発的でもありました。皆さんが研究し、取り組み、そしてこの重要性を広めてくれていると知って、少し気持ちが楽になりました。本当にありがとうございます。
キャロル・ウィンクイスト
ありがとう、ロブ。
エレズ・シュワルツ
ありがとうございます。
ジェイク・ノット
ありがとうございます。
ベッキー・ブラッケン
取り組んでくださり、素晴らしいレポートを届けてくださってありがとうございます。感謝しています。
ジェイク・ノットさん、エラ・シュワルツさん、キャロル・ウィンクイストさん、改めてお時間とご協力を本当にありがとうございました。以上、「Dark Reading Confidential」でした。Dark Reading編集部がお届けするポッドキャストで、サイバーの最前線から現実世界のストーリーを直接お伝えします。ご参加ありがとうございました。また次回お会いしましょう。
翻訳元: https://www.darkreading.com/cybersecurity-operations/stop-secrets-creep-across-developer-platforms
