責任ある開示：CodeCovのCEOとCTOが情報漏えいから得た教訓を語る

2021年1月、CodeCovはサプライチェーン攻撃を受け、顧客の環境変数が流出しました。その後数か月にわたり、何が問題だったのか、今後同様の攻撃にどう対処すべきかを明らかにするため、情報漏えいの詳細と技術的な仕組みがアプリケーションセキュリティコミュニティによって詳しく検証されました。しかし、この事件から得られたもう一つの興味深い知見は、やや華やかさに欠けるテーマ、つまり責任ある開示についてのものでした。

2021年10月、CodeCovのCEOであるJerrod EngelbergとCTOのEli HootenがThe Secure Developerポッドキャストに出演し、事件の内情を語りました。Guyとの対談では、インシデントの渦中にいるとはどういうことかが明らかになり、同様のインシデントにどう対応するのが最善かについて、興味深い問いが投げかけられました。

今すぐエピソードの全編を聴く

CodeCovのセキュリティインシデント

このエピソードの影響を掘り下げる前に、まず概要を振り返りましょう。CodeCovは、開発者がテストを実行する際に機械可読形式のレポートを生成する、コードカバレッジツールです。これらのレポートはCodeCovのアップローダーで処理され、該当するカバレッジデータが送信されます。レポートはGithub、Gitlab、BitbucketなどのCIプロバイダーを経由してアップローダーに届くため、CodeCovはソフトウェアサプライチェーンの中心に位置していました。

インシデント当時、CodeCovはレポートをサーバーにアップロードするためにcurl|bash（「curl pipe bash」「curl bash piping」などとも呼ばれる）スクリプトを使用していました。サーバーは`private write, public read`のCDNバケット上でホストされていました。攻撃者はCodeCovのエンタープライズ向けDockerイメージの圧縮レイヤーから認証情報を抜き取り、CDNバケットにアクセスしてbashスクリプトを悪意ある内容に改ざんしました。認証情報が無効化されるまでの間にプルリクエストまたはマージリクエストを作成したすべての顧客のCIパイプラインに、改ざんされたスクリプトが取り込まれました。これにより攻撃者はCIが実行されている顧客環境に侵入し、環境変数を出力させて、後で利用するために第三者のサーバーへ転送できるようになりました。

この攻撃の影響は顧客によって異なりました。CIをパブリックリポジトリで管理していた顧客は、環境変数に重要な情報を保存していなかった可能性が高いでしょう。一方、非公開リポジトリを使用し、CIが技術スタックと密接に連携して機密情報を保持していた顧客にとって、この情報漏えいは深刻な懸念事項でした。

他のサプライチェーン攻撃と同様、確かなことは情報が漏えいしたということだけでした。攻撃者が盗んだ環境変数を何に使うつもりなのかは分からず、チームは迅速かつ断固として行動する必要がありました。

CodeCovの対応

Engelbergは、開示に関するCodeCovの基本方針を次のように要約しました。「たった1社でも、私たちから連絡を受け取れず、適切な対応を取れない顧客がいるとしたら、それは多すぎます」。しかし、実際にはこの理念の実践が課題となりました。顧客がCodeCovにサインインする際、メールアドレスか、連絡先情報を非公開にできるソーシャル認証（OAuth、Github、Bitbucketなど）を選べます。便利な選択肢でしたが、後に開示プロセスの重要な要因となりました。

CodeCovで直接アカウントを作成した顧客や、連絡先情報を開示していた顧客への対応は簡単でした。利用可能なすべてのメールアドレスに、情報漏えいを知らせ、対応を促す通知を送りました。しかし残念ながら、CodeCovユーザーの大半はこのグループに該当しませんでした。そこでCodeCovチームは、残るすべての顧客に連絡するため、あらゆる手段を講じました。

連邦当局への報告後に情報を公開し、情報漏えいの詳細を伝える発表をテクノロジーメディアに取り上げてもらい、さらにCodeCovのアプリ上で大量の通知を送りました。ユーザー全員への通知を確実にするため、妥当と考えられるあらゆる手段を講じましたが、こうした大規模な対応に至った事情について考える価値があります。

CodeCovが全ユーザーにメールアドレスなどの個人情報の開示を求めていたなら、情報漏えい後に全員へ連絡するのは簡単だったでしょう。ソーシャル認証を選べるようにすることで、顧客は個人データをよりプライベートに保てましたが、緊急の連絡が必要になった際には大きな障壁にもなりました。ユーザーへの通知が一斉メールを送るだけで済むとしたら、CodeCovの開示プロセスは違っていたでしょうか。おそらく違わなかったでしょう。Hootenはこう語っています。「正しい対応ができていると分かるのは、たとえ先へ進む道が苦痛で困難でも、答えが明白なときだと思います」。CodeCovの根幹にある価値観が、いずれにしてもチームを透明性のある対応へと導いたはずです。

透明性によって事業への影響を最小限に抑える

セキュリティインシデントでまったく無傷でいられる企業はありませんが、CodeCovは継続的で透明性の高いコミュニケーションによって、悪影響を最小限に抑えられました。迅速に対応したものの、顧客離れは一部で発生しました。Engelbergによると、「『今は御社のサービスを使えません』と言う顧客もいました。また、製品を愛用していた推進者からも、『御社の製品は気に入っていますが、利用停止の指示が出たので、もう使えません』と言われました」。しかし、チームが透明性をもって開示していなければ、顧客の離反は大幅に増えていたでしょう。脆弱性を修正することは、損なわれた信頼を取り戻すことよりもはるかに容易です。

Snykと同様、CodeCovも開発者を中心に据えたアプリケーションです。そして開発者に必要なのは、取り繕った説明ではなくデータです。事実に基づいて対応し、幅広いセキュリティコミュニティに助けを求めたことで、CodeCovは危機の渦中にあっても、開発者からの信頼と開発者へのコミットメントを保ちました。

情報漏えいのその先へ

CodeCovのセキュリティ侵害から明らかになったことは、一つのインシデントにとどまりません。この攻撃の性質は、業界全体に影響する潜在的な落とし穴を浮き彫りにしました。最大の課題は、ベースラインの分配に関する問題です。オープンソースソフトウェアが開発サイクルに欠かせないものとなるにつれ、その依存関係も一緒に持ち込まれます。オープンソースの利点は明らかです。重要なのは、安全に活用する方法を見極めることです。

情報漏えい後にセキュリティを強化するため、CodeCovはSHAチェックサムや署名検証などの対策を追加しました。ユーザーには、取得するスクリプトがCodeCovから直接提供されたものだと確認できるよう、こうした検証の活用を促しました。しかし、検証の使用を義務付ける方法はありません。Engelbergはこう説明しています。「これがゼロトラストになるまでは……常にこのハンドシェイクが必要ですよね。ハンドシェイクをどんどん高度化することはできますが、今後どう進み、何ができるかについて、私がよく考えているテーマの一つです」。

潜在的なリスクについてユーザーを教育し、コードを監査するツールを提供することはできますが、追加の手順を踏むよう強制することはできません。企業と顧客の間の合意は、開発文化に深く根付いています。リスクを軽減する最善の計画を見極めることが、業界全体の課題です。

CodeCovの情報漏えいと、そこから業界について明らかになったことをさらに知りたいですか？The Secure Developerでポッドキャストの全編をお聴きください。EngelbergとHootenはCodeCovの内情を語り、社内のセキュリティ準備、CEOやCTOへのアドバイス、危機への対応を変えた共感の力などについて、当事者ならではの見解を共有しています。