新刊O’Reilly書籍：Guy Podjarny著『オープンソースライブラリのセキュリティ対策』

SnykとO’Reillyが提携し、新しい書籍『オープンソースライブラリのセキュリティ対策：オープンソースコードパッケージの脆弱性管理』をお届けします。本書では、SnykのCEO兼創業者であるGuy Podjarnyが、現在アプリケーションで使用しているオープンソースライブラリの脆弱性リスクに対処するためのさまざまなトピックを解説します。

脆弱性のある依存関係は、攻撃者に悪用される可能性が最も高いアプリケーションの構成要素です。本書では、アプリケーションを大規模に保護するための重要なベストプラクティスとツールを紹介します。

今すぐ無料の書籍をダウンロード！

Guyはまず、既知の脆弱性とは何か、CVEやNVDのデータベースなどでどのように公開されているかを説明し、それだけに頼るのでは不十分な理由を掘り下げます。また、責任ある開示とは何か、発見した脆弱性に対してどのような対応を取れるかも解説します。

第2章では、本書の核心に踏み込み、脆弱性がアプリケーション内で複数の経路を持つ仕組みを見ていきます。これは、依存関係ツリー内に脆弱なライブラリが複数回現れることで起こります。

パッケージAとBを使うアプリを考えてみましょう。Aも同じバージョンのBを使っている場合、依存関係ツリーは次のようになります。

ここで、B@1.0.0に既知のサービス拒否（DoS）脆弱性があるとします。アプリをテストしたとき、脆弱性はいくつ報告すべきでしょうか。一方では、既知の脆弱性はB@1.0.0のDoS脆弱性1つです。他方では、この脆弱性が2箇所に存在しています。1つと2つ、どちらを報告すべきでしょうか。

もう1つの重要なトピックは、テストを行うタイミングです。本書では、ソースコード段階とビルド済みアプリケーションの両方をテストするメリットを解説します。ただし、ソースコードのテストは近似的な評価であるのに対し、ビルド済みアプリケーションのテストはより正確です。最善策は両方を活用することです。

両方を組み合わせるには、_built_appsをテストしつつ、パッケージマニフェストファイルも探して論理的なツリーを構築し、見つかったライブラリをそのツリーに当てはめるツールを使います。これにより、ビルド済みアプリのテスト範囲を確保しながら、可能な限りソースコードに基づく深い理解も得られます。

あるいは、開発の異なる段階で2つのアプローチを使い分けることもできます。たとえば、GitHub/GitLab/BitBucketのワークフローではソースコードスキャンを行い、ビルドプロセスやデプロイのゲートとしてビルド済みアプリをテストできます。ほとんどの場合、2つのアプローチは同じ結果をもたらし、一貫して機能します。異なる結果になった場合でも、ビルド済みアプリのテストによって脆弱性のあるものをデプロイせずに済みます。

この章では、SCM、コマンドライン、コンテナレジストリ、ブラウザで既知の脆弱性を見つける方法を解説します。しかし、これは全体の半分にすぎません。より重要なのは、得られたデータにどう対処するかです。Guyは、直接依存と間接依存をアップグレードする方法に加え、アップグレードの方法がない場合のパッチ適用についても説明します。ただし、一部の言語では依存関係の競合が起きる可能性があります。

RubyやPythonなど多くの言語では依存関係をグローバルに管理する必要があり、RubyのbundlerやPythonのpipなどのクライアントが共存できるライブラリのバージョンの組み合わせを決定します。そのため、あるライブラリをアップグレードすると、別のライブラリとの競合が起こることがあります。開発者はこうした競合への対処に長けていますが、解決できないケースもあります。

本書ではアプリケーションの脆弱性だけでなく、コンテナイメージの脆弱性を修正する方法も取り上げます。Guyは、アプリケーションの脆弱性とは異なり、OSの脆弱性では単純にアップグレードできる修正版が提供されているとは限らないと説明します。そのため、適切なトリアージがより重要になります。

第4章では、変化の速い現代の開発環境で非常に重要なテーマを取り上げます。既存のパイプラインにセキュリティテストを組み込み、開発変更を本番環境に反映する際にテストできるようにする方法です。これはDevSecOpsパイプラインと呼ばれることがよくあります。

書籍全文をダウンロード！

迅速な修正に備える

このプロセスで重要なのは、コード変更や新たな脆弱性の公開によって脆弱性が見つかったとき、チームがどう対応するかです。新しいセキュリティ通知を受け取ったら、誰に連絡すべきでしょうか。セキュリティチームでしょうか。開発者でしょうか。経営陣でしょうか。問題の種類や深刻度に応じて、どれほど迅速に対応すべきでしょうか。新たな脆弱性が見つかった場合、ビルドを停止すべきでしょうか。依存関係チェーンの更新による影響を受ける可能性はあるでしょうか。オープンソースライブラリのセキュリティ対策を始めるための指針や実践的なアドバイスを得るには、今すぐ書籍をダウンロードしてください。