Pinterest のセキュリティツールでデベロッパーエクスペリエンスを向上

オープンソースライブラリを安全に利用することは、大規模な組織において継続的な優先事項となっています。大きな課題の一つは、開発者のワークフローにセキュリティツールを組み込むこと、そして開発者に負担をかけずに脆弱性修正の優先順位を決めるシステムを構築することです。しかし、成功するアプローチとはどのようなものでしょうか？

Snyk のフィールド CTO のサイモン・メイプル は、Pinterest の製品セキュリティエンジニアのカルペシュ・ダルワドカル氏 と共に、Pinterest で Snyk を活用してデベロッパーフレンドリーなセキュリティプラクティスを構築する方法について学びました。

3 大優先事項: 可視化、スキャン、およびトリアージ

Pinterest は、開発スタックに多数のオープンソースソフトウェアを使用しているため、オープンソースライブラリに脆弱性が含まれていれば、間違いなく経営陣のプロフィールに影響が及びかねません。カルペシュ氏が入社する前は、NPM 監査を使用してオープンソースライブラリにビューを構築するアドホックシステムを使っていました。それでも、カルペシュ氏が入社したとき、使用中のオープンソースライブラリをすべて可視化できる一元化システムを構築したいと考えました。カルペシュ氏が率いるチームは多数のソリューションを評価し、デベロッパーフレンドリーの機能と、Bazel (彼らが選定したビルドツール) などの言語固有のリポジトリをサポートしているという 2 つの主な理由から、Snyk を選びました。 カルペシュ氏は会話の最初にセキュリティに関する最優先事項を説明しました。

Pinterest がオープンソースのセキュリティについて重視しているのは、脆弱性のあるライブラリの可視化、修正点のスキャンを含むスタック全体で使えるツール、そして脆弱性のトリアージという主に 3 つの分野です。

カルペシュ氏は、ビルドには Jenkins を使用していると説明しました。Snyk CLI を使用してビルドシステムをスキャンし、結果を Snyk Web UI にアップロードします。最初の目標は、コードリポジトリのすべての依存関係を可視化し、脆弱性の修正の優先順位を設定することです。そこで、脆弱性を可視化できる Common Vulnerability Scoring System (CVSS) の導入が検討されました。攻撃された場合、Snyk からの情報をもとに、優先度の高い修正かどうかが判断されます。

パイプライン全体にセキュリティテストを追加する

次にサイモンは、開発パイプラインでのテストについて、開発者に Snyk の使い方を教える点でどのような課題があったか、質問しました。カルペシュ氏は、このステップを簡単に解決していました。開発者パイプラインに Snyk を導入した当初、Snyk コンソールを開発者に見せる代わりに、Jenkins のビルドのステップとしてスキャンを実行するようにしました。そして、「簡単に達成できる目標」、つまり簡単な修正に自分から取り組み始め、その成果を技術リーダーやプロジェクトオーナーに確認してもらいました。これにより、Snyk のツールで行う修正に興味を示す人が増えて、賛成の輪が広がりました。

効率的なトリアージ、修正の優先順位の設定、Log4Shell に関する議論

話し合いは脆弱性のトリアージに移りました。「開発者が注力する『脆弱性のトップ 5』について伝えられるよう、バックログからはどんなシグナルやレッドフラグを調べていますか」とサイモンが尋ねると、カルペシュ氏の解決策は、脆弱性の重大性について考慮することでした。つまり脆弱性に対して現在攻撃が仕掛けられているかどうか、そして脆弱性がインターネットに公開されているサービスに含まれているかを考慮することです。これらは修正の優先順位を設定するためのパラメーターになります。そして、開発者やサービスオーナーが脆弱性を修正するためのチケットが作成されます。チケットの追跡情報は、脆弱性の評価について、開発者が重要と考えている脆弱性と一致しているかどうかチームが把握するのに役立ちます。

開発者はそのチケットに割り当てられるからです。「依存関係に脆弱性のあるこの機能は現在使っていませんが」と言うかもしれません。その場合はその機能の優先順位を下げます。

Log4Shell の話になり、サイモンは Pinterest が大きなゼロデイ脆弱性にどのように対処しているかを尋ねました。カルペシュ氏は、Log4Shell が発表された翌朝、自分のチームがインシデントを宣言して影響を受けたサービスの件数を調査したことを思い出しました。JVM フラグ (またはワークアラウンド) が利用可能だったため、Java サービスに適用しましたが、すべてのサービスをデプロイするためにはサービスオーナーに依頼しなければならず、かなり時間がかかりました。すべてのサービスが JVM フラグを使用してデプロイされていることを確認したかったため、ワークアラウンドをデプロイするためにチームは週末までかかって作業しました。チームは 2 つの作業の流れを確立しました。1 つは Pinterest 全体のすべての Java サービスを検出する、もう 1 つは JVM フラグのワークアラウンドでは対応できないサービスを検出する、というものです。JVM フラグが十分でないサービスでは、アップデートが脅威を軽減する唯一の方法でした。 また、Log4Shell から得た重要な教訓として、本番環境で稼働しているものすべてを表示するダッシュボードを 1 つ用意すること、と付け加えています。

スキャンを自動化して開発を前に進める

サイモンは Pinterest での Snyk の活用方法の話に戻り、Snyk で Pinterest の開発者はセルフサービス型の手作業をどれだけ削減できたか、また開発者パイプラインをどれだけ可視化できたかについて質問しました。

Pinterest では、言語別のモノリポジトリが使用されています。Snyk にモノリポジトリを追加すると、そのリポジトリで作成されるすべての新しいプロジェクトが自動的に追加されます。そのため、リポジトリに新しいプロジェクトが作成されても、追加の作業は必要ありません。コードがリポジトリにマージされ、Snyk スキャンが行われると、その時点でどのような依存関係が発生したかがわかります。（開発者が自分のモノリポジトリにプロジェクトを作成するとき、スキャンは）開発者にとって透過的になります。Snyk が実行中であることを知る必要さえありません。

この設定により、開発者がプロジェクトを作成すると、そのプロジェクトが自動的にスキャンされ、Snyk UI にプッシュされるため、カルペシュ氏のチームはトップダウンですべてを確認できるようになりました。

サイモンは、開発者は通常、他のツールを使用するのではなく、現在のワークフローを変えたくないと思っていることを伝え、カルペシュ氏に「開発者がパイプラインに留まれるようにするため、どのようなことを行っていますか？」と尋ねました。

カルペシュ氏は、開発者は知る必要があることをすべて知っていながら、「チケットの作業」に留まることを望んでいることに同意しました。また、開発者向け教育リソースを含むSnyk のラーニングハブについても言及しています。カルペシュ氏は、このカリキュラムにアクセスすることで、開発者に Snyk Web コンソールをさらに公開したり、JIRA チケットに Snyk Learn の関連情報へのリンクを追加して、XSS や SQL インジェクションなどの脆弱性に関して多くのコンテキストを開発者に提供したりすることを検討していると言います。これは、開発者にセキュリティ知識を身につけることを促す有効な手段となります。

開発者の理想を実現する

Pinterest のカルペシュ氏とチームはデベロッパーフレンドリーなワークフローを大切にし、開発者の負担にならないようなトリアージを重視しています。Snyk を統合した当初は依存関係に多数の脆弱性が発見されたため、企業にとって優先度の高いものだけを明らかにすることが重要になったと述べています。Snyk でスキャンを自動化して結果を確認しつつ、開発者は自分の好きなツールで開発できるようになったため、Pinterest の開発はスムーズに進むようになりました。

開発者が知りたいのは、「何が問題なのか」、「どうすれば解決できるのか」、「どの問題を優先するのか」です。これらを開発者のチケットに表示できれば、問題解決への準備ができたことになります。