GitLab public bungプログラムの公式ローンチから1年経った今、その成果と、GitLabとそのユーザのセキュリティ改善に与えた影響の評価をするべき時だ。
GitLabのバグ報奨金プログラムは、GitLabによれば、数百のバグレポートと50万ドルを越える報奨金という、すばらしい成果をあげることができた。
このプログラムは、当社のエンジニアにより高い場所への挑戦を続けさせることで、セキュリティチームを驚かせると同時に、GitLabをよりセキュアに保つ上で有用なものでした。
バグ報奨金プログラムを公開することによってGitLabは、レポートの選別や対応の方法からコミュニケーションや透明性の改善方法に至るまで、さまざまなことを学んだ。実際に同社では、自分たちはまだ学習途上であり、プログラムをより効果的にする方法の模索を続けている、と述べている。
InfoQでは、GitLabのシニアアプリケーションセキュリティエンジニアであるJames Ritchey氏から、GitLabのセキュリティ戦略、およびバグ報奨金プログラムが組織に貢献するものについて話を聞くことができた。
InfoQ: セキュリティに関して、GitLabは透明性と公開というポリシを以前から採用していますが、これがGitLabと投資家に対してどのような価値があるのか、詳しく説明して頂けますか？脆弱性の数や重要度を公開することで、GitLabのイメージにネガティブな影響を及ぼす心配はないのでしょうか？
Ritchey: GitLabは企業として、透明性を重要な価値観のひとつとしています。それが顧客からの信頼を得るための方法のひとつだからです。この考え方は、脆弱性プログラムに対しても適用されています。発見され、修正された脆弱性の詳細を公開することは、セキュアな製品を開発することの重要性を表すものとして、ユーザとの信頼性を構築し、維持する上で必要なものなのです。
セキュリティバグの処置を誤って、ユーザに直接影響を与えるようなことがあれば、信頼は失われます。脆弱性に関するすべての情報を30日後に公開することで、ユーザは自身の環境にアップグレードや回避手段を適用して、それらの脆弱性から保護する機会を得ることができます。セキュリティ上の問題を公開することは、GitLabをセキュアにするために我々が投資していることを広く示すものなのです。
InfoQ: この数年間、ソフトウェア業界のセキュリティに関する対処方法やシステムを脆弱性から保護する方法は着実に改善されています。例えばGitHubは、セキュリティアラートやコード分析を提供して、開発者の可能な限り早いリスク検出を支援しています。GitLabでは、開発者が自身のソフトウェアをセキュアなものにする方法を、どのように改善しようとしているのでしょう？
Ritcjey: 当社が開発者によるセキュアなコードの記述を可能にするということを重視しているのは、当社のSecureプロダクトチームに現れています。同チームは現在、開発者がコードをGitLabにプッシュすると、セキュリティ関連の情報を可能な限り早く提供できるようなツールを開発しています。提供する情報は、脆弱性のある依存関係への依存分析や、静的コード解析による一般的にセキュアでないコードパターンの検出、といったものです。
セキュリティチームは、この分野のツーリングにも貢献しています。当社のredチームは先頃、Token Hunterというツールをオープンソース公開しました。これは、開発者がGitLab以外の領域で、イシューやスニペットなどの重要なデータを見つけ出すことを支援するためのものです。
InfoQ: 先日のセキュリテイ企業Synkによるレポートでは、オープンソース開発者たちのセキュリティに関する当事者意識の欠如が、大きな要因のひとつとして指摘されていました。GitLabの開発者たちに対して、セキュアなソフトウェアを提供することの重要性を認識させる取り組みとして、どのようなことをしていますか？
Ritchey: GitLabでの開発者間のセキュリティ意識に関するコミュニケーションは、プロダクトの立ち上げ時から始まって、開発期間中ずっと続けられています。プロダクトに参加した開発者は、セキュアなコーディングに関するリソースの場所を教えられます。この中には、過去のセキュアコーディングに関するトレーニングのビデオや、一般的な脆弱性に対するガイドライン集などが含まれています。
さらにアプリケーションセキュリティチームも、別のイニシアティブを年間を通じて行っています。その一例が隔週で行われているオフィス訪問で、誰でも参加して、セキュリティ関連の問題を議論することができるのです。もうひとつ、これは初めての試みですが、当社が毎年行っているコミュニティイベントであるContributeで、今年は"Capture The Flag"というイベントを計画しています。皆で集まって顔合わせして、コミュニティを作り上げて、何らかの成果をあげたいと思っています。
InfiQ: 1年前に公開バグ報奨金プログラムをローンチして、150人以上のセキュリティ研究者が総額56万ドルを受け取りましたが、このプログラムがGitLabにとってどのような効果があったのか、そのプロセスを通じて何を学んだのか、簡単に説明して頂けますか？
Ritchey: 1年間を通じて、コミュニティからたくさんの反応を受け取りました。この間、私たちは多くのことを学びました。最も重要な教訓は、規模が必要だということです。特にコミュニケーションや行動において、規模は重要です。たくさんのレポートが寄せられる一方で、GitLab側の人数は限られています。規模を拡大しなければ、レポートの量に圧倒されてしまいます。これに対する私たちの回答は、可能な限り自動化する、というものでした。例えば、自動化されたbotを使用することで、最初の返答までの平均時間を、48時間以上から7時間未満まで削減することができました。
もうひとつの自動化は、私たちがすでにトリアージして追跡中のイシューに対するもので、その脆弱性がフィックスされる時期に関する最新情報の要求がたくさん来ます。そのために、自動化チームが新たなbotを立ち上げて、プロダクトチームがスケジュールしたイシューについては、予想される修正日をレポートにコメントするようにしました。
規模と同じように重要な教訓が、ハッカーの参画を促すことと、そのレベルを高く保つことです。HackerOneには選択可能なプログラムがたくさんありますから、私たちのプログラムを選んで固執しなければならない理由はありません。1,000以上のプログラムが選択肢としてある中で、レポータの注目を競っていることになります。そのために重要なのは、現在プログラムに参加しているレポータからのフィードバックに耳を傾けることです。
その中で多かったもののひとつは、報奨金の支払いまでの時間を短縮してほしい、というものでした。それまでの私たちは、イシューが解決した時点で報奨金を支払っていたので、イシューの重要度によっては1～4ヶ月程度かかっていたのですが、このフィードバックを受け入れて、2019年9月に、トリアージ時に事前に1,000ドルの報奨金を前払いできるように、報奨方法を変更しました。残りはレポートが解決された時と、あるいは90日が経過した時の、いずれか先の方に支払われます。
InfoQ: 報奨金プログラムの確立は、クラウドサービスのセキュリティを向上させる上で重要なアプローチですが、バグ報奨金プログラムの立ち上げと運用を成功させる上で、何かアドバイスはありますか？
Ritchey: 当面は、私たちやその他のプログラムに習うのがよい方法でしょう。
- 公開プログラムを立ち上げるのは、早いほどよい
- 自動化によるスケールアップを図る
- 多くのハッカーをプログラムに参加させる
- 特に高度で重要度の高い脆弱性については、競争力のある報奨をする
- 支払いを早くする
- スコープを大きくする
- セキュリティイシューに関しては、透明性を持つべきである。なぜか？
- サービスのセキュリティに対する熱意の現れであり、結果として顧客に信頼を与えるものだからだ。
- 正確には何が問題なのか
- 問題が報告されたのはいつか
- どの程度の期間で修復できたのか
- これらすべてを秘匿するならば、
- 説明責任がない
- サービスのセキュリティにどれほどコミットしているのか把握できない
GitLabはソースコード管理とWiki、イシュートラッキング、継続的インテグレーション/継続的開発などを統合した、開発とDevOpsのためのクラウドベースのプラットフォームである。