Skip to main content

SurveyMonkey、急成長中の企業におけるデベロッパーセキュリティについて Snyk と語る

著者:
feature-customer-survey-monkey

2022年5月5日

0 分で読めます

多くの企業では、ソフトウェア開発全体のセキュリティ管理を、CISO やコンプライアンスチームに任せています。ただし、この方法だと、通常はセキュリティを開発者から切り離して考えることになってしまいます。CISO はセキュリティタスクを開発者に割り当てることができるとはいえ、開発者がセキュリティについて常に考えていない場合は、こうしたタスクを見過ごしてしまうかもしれません。このギャップを埋める 1 つの方法は、セキュリティエンジニアリングのリーダーを指名することです (この概念はセキュリティチャンピオンと似ています)。つまり、この人物がエンジニアリングプロセスのセキュリティ部分の責任者となります。

最近の円卓会議で Snyk のフィールド CTO のサイモン・メープル (Simon Maple) が、SurveyMonkey (現在は Momentive グループ) のセキュリティ、クラウド、およびデータストアエンジニアリングのシニアディレクターのクレイク・パイク氏 (Craik Pyke) と対話しています。その中で、急成長中の企業で情報を可視化するツールを使用することや開発者がセキュリティに集中できるようにする道路のようなインフラを作るアプローチについて話し合いがなされました。SurveyMonkey では、Snyk Open SourceSnyk ContainerSnyk Code を活用し、開発プロセス全体でセキュリティを統合しています。ここでは、話し合いの概要をご紹介します。

一貫性を高めて可視化する

クレイク氏が SurveyMonkey に入社した当時、同社はマイクロサービスアーキテクチャで運営されていました。つまり、各チームが設計から開発、導入、サポートまで、独自のサービスを担当していました。チームの自由度は高く、誰もが独自のパイプラインにプラグインを追加し、好みのツールを使用していました。この方式の問題はトレーサビリティです。つまり、開発者がコンテナをどこで入手したか、または依存関係の数を明確に追跡することができないのです。この環境で、クレイク氏はオープンソースの管理を一番心配していました。そこで同氏はライセンス利用状況を追跡したり、信頼できる帰属表示を作成したりする方法があるかどうかを尋ねました。すべて手動で管理されていたため、答えはいつも「ノー」でした。

開発者は自分が手がけているプロジェクトには依存関係が 80,000 件も含まれているが、何が何を参照しているのかさっぱりわからない、そのすべてのライセンスを調べる方法もわからないという状況でした。 そこが私たちの出発点となりました。私たちは、開発者が質問に答えられるように支援する必要がありました。セキュリティだからといって強制することはしたくありません。

クレイク氏はこれまでの経験から、最初に取り組むべきは情報の可視化とガバナンスの確立だということを理解していました。以前に同氏が勤務していた会社では製品の回転が目まぐるしく、パッケージのバージョンや関連するオープンソースのリスクを把握するという考え方には、顧客に求められるまで対応していませんでした。それで SurveyMonkey では、情報を可視化する前に、一貫性の点から取り組みを始めました。まず、DevOps のカルチャーを根付かせる必要がありました。つまり、開発者が 1 つのパイプラインを構築するという作業を特定のグループに任せて管理してもらうという習慣です。多くの人がその習慣を身につけると、1 本のパイプライン構築がスムーズにいくようになりました。最初のステップは開発アーティファクトを構築することでした。次に、開発者がパイプラインの外部で各自のマシンで行っていることを可視化するためのツールを探しました。

優れたツールとデータを提供する

開発者は、問題があれば解決したいと考えます。問題解決に必要なものがあれば何でも、自分のマシンや IDE に取り込んでしまいます。クレイク氏は、開発者が試作の段階で何を取り込んでいるかを明確にし、定義したいと考え、さらに、開発パイプラインや IDE またはコマンドラインの作業を反映するツールを提供したいと思いたちました。

開発パイプラインと同じマシン上で (開発者に) 優れたツールを提供するにはどうすればいいでしょうか。そのツールを特定してパイプラインに導入できれば、パイプライン上での作業が楽になります。一貫性が鍵です。

さらに、開発者に有用なデータを提供する、ということもあります。たとえば、特定のパッケージがプロジェクトに適しているかどうか、それとも別のパッケージを探すべきなのか、開発者が簡単に判断できるようにするということです。そのための最良の方法は、データを活用することです。開発者は、Snyk Advisor のようなツールを活用して指標 (パッケージの人気度や最新の問題点など) を表示できれば、問題の複雑性をすばやく把握できます。クレイク氏は、彼の現在の役割での決定的な要素は、信頼できるデータを開発者に渡すことであり、その後は開発者が正しい選択をしてくれると信頼することだと言います。

道を踏み固める

次に、クレイク氏は共通インフラの構築に着手しました。彼は汎用のアーティファクトリポジトリである Artifactory を使用しましたが、他にも活用できるものはたくさんあります。主な目標は、開発者が常にレジストリからアーティファクトを取得できるようにすることでした。急成長中の企業にとってこのステップは非常に重要です。開発者チームの拡大によって、インフラが無秩序に拡大することになりかねないからです。ただし、クレイク氏は、セキュリティチームが事業を妨げることを望んでいませんでした。開発者にはこう言っています。「アーティファクトシステムで好きな設定ファイルを指定した場合、必要なファイルがなければ、システムが自動的に取得してくれます。きっと役立つはずです」。 最初は開発者に対して、この変更について言い広めなければなりませんでしたが、開発者たちが単一のアーティファクトクラスターからアーティファクトを取得するようになると、いつどこで何が行われているか、そしてどのバージョンが使用されているかを可視化できるようになりました。

クレイク氏のチームは、開発者にパイプライン外での作業も許可しましたが、PR の送信をしようとするとそれを阻止するようにしました。GitHub でテストを行う開発パイプラインでは、インターネットからの直接取得を禁止し、アーティファクトリポジトリからの取得に限って許可しました。開発者がこの仕組みを理解してアーティファクトストアを使用していれば、何も問題は起こりません。

開発者が、セキュリティを邪魔だと思わないようにするために、私たちはフレンドリーなアプローチを取りました。つまり、目の前にニンジンをぶら下げる方式です。私たちは、単一のアーティファクトリポジトリを提供することで、入ってくるものすべてをスキャンできるので、悪意のあるパッケージや不正なライセンスについて心配する必要がなくなり、間違えるおそれもなくなると考えました。 開発者たちが感じていたセキュリティへの反感は一掃され、単に質問して答える人たちと見るようになりました。私たちは開発者たちの力になりたいのであって、邪魔をしたいわけではありません。

セキュリティチャンピオン: 草の根的なアプローチ

クレイク氏のチームが道を踏み固めている間、SurveyMonkey の開発者数人がセキュリティチャンピオンとして行動するようになりました。経験豊富な開発者が、アーティファクトリポジトリや PR シグナルの検出の方法、誰に質問したら良いかなどを新しいチームメンバーに教え始めたのです。クレイク氏はこれを「第一段階のサポートを開発者チームに任せる緩やかな概念」と呼んでいます。 セキュリティチャンピオンについては、形式的な制度にはしませんでした。チームに加わる人がセキュリティ重視の行動を自然に身につけるようになっていったからです。

コードのセキュリティ監査を開発者が自ら行う際に支援を必要とした場合は、セキュリティチームがイネーブラーになれます。クレイク氏は、踏み固めた道と、脆弱性の検出や修正が簡単にできる Snyk ツールのようなツールセットがあれば、開発者の手を煩わさず、必要に応じてセキュリティチームがアーティファクトの再構築をトリガーできると指摘しています。

ツールとパイプラインから取得したデータにより、開発者は実際に賢明な選択を行えるようになっています。

責任と目標を共有する

シフトレフト文化が浸透した環境では、開発者は前もってセキュリティ要件に対応しておきたいと考えます。検証を行うことで、収益につながる作業をすばやく完了できます。つまり、セキュリティチームが開発者に対して「セキュリティを保護するために、これら手順に従え」と指示するのではなく、 むしろ開発者の側からセキュリティチームに対して、「このパッケージに問題があるようだが、開発を続けてもいいか」と尋ねるようになったのです。 また、チームは説明責任の共有にも努めています。つまり、起こってしまった脆弱性を非難するのではなく、問題をできるだけ早く解決し、そこから何を学んだかを話し合う姿勢です。

開発者の支援とは、開発者同士が支援し合うことでもあります。クレイク氏のチームが Snyk を導入して脆弱性をチェックした際も、GitHub の妨げにはなりませんでした。その代わりに、経験豊富な開発者がコードレビューや PR レビューについて、経験の浅い開発者を指導できるようにしました。経験豊富な開発者は、「この赤い X 印は問題があることを示しており、技術的にコードのマージはできるが、現状は見ての通りだ」などと指導します。 つまり、新米の開発者に厳しく当たるのではなく、共に歩む文化を作り上げたのです。SurveyMonkey のチームにとっては、適切なレベルで Snyk ツールを強化することが最善のアプローチとなりました。

優れたデベロッパーセキュリティのインサイトについて詳しくは、全文をご覧ください

カテゴリー: