Pinterestのセキュリティツールで開発者体験を向上

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

SnykのフィールドCTOであるSimon Mapleが、PinterestのプロダクトセキュリティエンジニアであるKalpesh Dharwadkarに、PinterestがSnykを使って開発者に使いやすいセキュリティプラクティスを構築する方法について話を聞きました。

3つの重要な優先事項：可視化、スキャン、トリアージ

Pinterestの開発スタックでは多くのオープンソースソフトウェアを利用しているため、脆弱なオープンソースライブラリは経営層の評価にも確実に影響します。Kalpeshが入社する前は、NPM auditを使ってオープンソースライブラリの状況を可視化する、場当たり的なシステムを利用していました。入社後、Kalpeshは、使用中のすべてのオープンソースライブラリを一元的に可視化する仕組みを整えたいと考えました。チームは多数のソリューションを評価し、開発者に使いやすい機能と、Bazel（同社が選択したビルドツール）など、言語固有のリポジトリへの対応を理由にSnykを選びました。会話の冒頭で、Kalpeshはセキュリティに関する主な優先事項を次のように説明しました。

Pinterestでオープンソースのセキュリティを確保するうえで、主に注力していることは3つあります。脆弱なライブラリを可視化すること、修正のためのスキャンに加えてスタック全体でツールを活用すること、そして脆弱性をトリアージすることです。

Kalpeshによると、ビルドにはJenkinsを使用しています。Snyk CLIでビルドシステムをスキャンし、その結果をSnykのWeb UIにアップロードします。まず、コードリポジトリ内のすべての依存関係を可視化し、脆弱性修正の優先順位を付けることを目指しました。そこで、脆弱性の可視化に役立つ共通脆弱性評価システム（CVSS）を調べました。脆弱性を悪用する手段が存在する場合は、Snykの情報を使って、優先度の高い修正かどうかを判断します。

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

続いてSimonは、開発パイプライン全体でのテストと、開発者にSnykの使い方を教える際に生じる課題について尋ねました。Kalpeshは、この段階をシンプルな方法で進めています。開発者のパイプラインにSnykを導入し始めた当初、Snykのコンソールを開発者に見せるのではなく、Jenkinsのビルド工程の一つとしてスキャンを実行しました。その後、「すぐに対応できる」簡単な修正の一部を自ら行い、テックリードやプロジェクトオーナーにレビューしてもらいました。これにより、Snykツールを使った修正に関心を持ってもらい、より広い賛同を得ることができました。

効率的なトリアージ、修正の優先順位付け、Log4Shellへの対応

話題は脆弱性のトリアージに移りました。Simonは、「開発者に『優先して確認すべき脆弱性の上位5件はこれです』と伝えるために、バックログでどのような兆候や危険信号を探しますか」と尋ねました。Kalpeshは、脆弱性の深刻度、実際に悪用されているかどうか、そしてインターネットに公開されているサービスに存在するかどうかを考慮します。これらの要素を使って修正の優先順位を決めます。次に、開発者またはサービスオーナーに脆弱性の修正を依頼するチケットを作成します。チケットに情報を記録することで、脆弱性に関するチームの評価が、開発者の重要度の認識と一致しているかを把握できます。

そのチケットは担当の開発者に割り当てられます。開発者から「この依存関係の脆弱な機能は使っていません」と返答があることもあります。その場合は、その機能の優先度を下げるようにしています。

話題がLog4Shellに移ると、Simonは大規模なゼロデイ脆弱性にPinterestがどう対処したかをKalpeshに尋ねました。Kalpeshは、Log4Shellの発表翌朝、影響を受けたサービスの数を調べるため、チームがインシデントを宣言したことを振り返ります。JVMフラグ（または回避策）が利用できたため、Javaサービスに適用しました。しかし、すべてのサービスをデプロイするには時間がかかるため、サービスオーナーに頼る必要がありました。すべてのサービスにJVMフラグが適用されたことを確認するため、回避策のデプロイ作業は週末まで続きました。チームは2つの作業系統を設けました。1つはPinterest全体のJavaサービスをすべて検出すること、もう1つはJVMフラグによる回避策でカバーできないサービスを検出することです。JVMフラグだけでは不十分なサービスでは、脅威を緩和するためにアップデートするしかありませんでした。Kalpeshはさらに、Log4Shellから得た重要な教訓として、本番環境で稼働しているすべてのものを表示する単一のダッシュボードを用意することを挙げました。

スキャンを自動化して開発を止めない

PinterestでのSnykの活用に話を戻し、Simonは、Snykによって開発者が自ら対応できるようになり、Pinterestの手作業がどれほど減ったか、また開発者のパイプラインをどれほど可視化できているかを尋ねました。

Pinterestでは、言語ごとのモノレポを使用しています。モノレポをSnykに追加すると、そのリポジトリに新しいプロジェクトが作成されるたびに自動で追加されます。そのため、リポジトリに新しいプロジェクトができても、追加の作業は必要ありません。コードがリポジトリにマージされてSnykのスキャンが実行されると、どの依存関係が導入されたかを把握できます。［開発者がモノレポ内にプロジェクトを作成したとき、スキャンは］開発者から見えない形で行われます。Snykが実行されていることを知る必要すらありません。

この設定により、開発者がプロジェクトを作成するたびに自動でスキャンされ、結果がSnykのUIに送信されます。Kalpeshのチームは全体を俯瞰して把握できます。

Simonは、開発者は一般に、ほかのツールに移るのではなく、自分のワークフロー内で作業を続けたいと考えていると話します。そしてKalpeshに、「開発者がパイプライン内で作業を続けられるよう、どのように設定していますか」と尋ねました。

Kalpeshも、開発者は必要な情報をすべて把握しながら「チケット内で作業を続ける」ことを好むと同意しました。開発者向けの学習リソースを提供するSnykのラーニングハブについても触れました。このカリキュラムを利用できることから、開発者にSnykのWebコンソールをもっと見てもらうことや、JIRAチケットにSnyk Learnの関連情報へのリンクを追加することを検討しているとKalpeshは述べています。こうすることで、XSSやSQLインジェクションなどの脆弱性に関する理解を深めてもらえます。開発者のセキュリティ知識の向上を促すうえで、有効な方法です。

開発者が望む場所で作業できるように

全体として、KalpeshとPinterestのチームは、開発者に負担をかけないようトリアージを重視した、開発者に使いやすいワークフローを大切にしています。Snykを初めて導入した際には、依存関係から多数の脆弱性が見つかったため、ビジネス上優先度の高いものだけを提示することが重要だったとKalpeshは指摘します。スキャンを自動化し、Snykで結果を確認しながら、開発者が使い慣れたツール内で作業できるようにすることで、Pinterestは開発を円滑に進めています。

開発者が知りたいのは、問題の内容、修正方法、そして優先度です。開発者のチケットにこれらを明記できれば、対応はスムーズに進みます。