オープンソースの脆弱性にどう向き合っているか？5つのWebフレームワーク開発者21人の調査から見えた現実と課題
公開日
セキュリティ
ソフトウェア開発において、オープンソースソフトウェア（OSS）の外部ライブラリを組み込むことは開発の効率化に欠かせません。しかし、これらの依存関係に脆弱性が含まれていた場合、システム全体が攻撃のリスクにさらされることになります。開発チームがこれらのリスクをどのように認識し、管理しているのかを知ることは、セキュリティ対策を向上させる上で極めて重要です。
本記事では、Anna Makarudze氏が発表した研究資料「Vulnerabilities in Open-Source Dependencies: A Developer’s Perspective」に基づき、開発者が直面している依存関係管理の課題、意識、そして解決に向けた障壁について詳しく解説します。
ソフトウェアサプライチェーンと依存関係の基本構造
現代のソフトウェア開発では、一つのアプリケーションが多数の外部パッケージに依存しており、それらのパッケージ自身もさらに別のパッケージを呼び出すという複雑な連鎖が存在します。この構造を「ソフトウェアサプライチェーン」と呼びます。
外部パッケージを導入することは開発速度を高める一方で、開発者が直接管理していない部分から脆弱性が持ち込まれる要因になります。
図1 ソフトウェアサプライチェーンにおける依存関係チェーン
サプライチェーン攻撃の主な手法には、正規のパッケージに似た名前で悪意あるコードを登録する「タイポスクワッティング」や「コンボスクワッティング」、さらに元の開発者のアカウントを奪う「アカウント乗っ取り」などがあります。依存関係の深い階層にあるライブラリが攻撃を受けると、それを利用している全てのアプリケーションへ影響が及びます。
主要開発言語とWebフレームワークの特徴
本調査は、GitHubリポジトリの貢献度（コミット数など）に基づいて上位コントリビューターを抽出する意図的サンプリングを行い、3週間にわたり21名の実開発者を対象としたインタビュー形式で実施されました。調査対象となった開発者が主に扱う、5つの開発言語およびWebフレームワークにおけるパッケージ管理の特徴は以下の通りです。
| 概念 | Python | Java | JavaScript | Ruby | PHP |
|---|---|---|---|---|---|
| 依存関係の宣言ファイル | pyproject.toml requirements.txt setup.py | pom.xml build.gradle | package.json | Gemfile .gemspec | composer.json |
| ロックファイル | poetry.lock Pipfile.lock | gradle.lock | package-lock.json yarn.lock pnpm-lock.yaml | Gemfile.lock | composer.lock |
| 中央リポジトリ | PyPi | Maven Central | npm Registry | RubyGems.org | Packagist |
| 間接的な依存関係 | pip / Poetry / Pipenv によって解決 | Maven / Gradle で完全なグラフを解決 | npm / Yarn / pnpm がツリーを完全インストール | Bundler が完全なグラフを解決 | Composer が完全なグラフを解決 |
表1 選択された言語の比較
また、各プログラミング言語から選ばれた代表的なフルスタックフレームワークの特徴は次の表の通りです。
| Webフレームワーク | エコシステム | 設計スタイル |
|---|---|---|
| Django | Python | フルスタック、必要な機能があらかじめ網羅されている（Batteries-included） |
| Spring Boot | Java | フルスタック、企業システム向けの堅牢な設計 |
| Next.js | JavaScript / Node.js | フルスタック（Reactベース） |
| Ruby on Rails | Ruby | フルスタック、規約を重視した開発スタイル（Convention-driven） |
| Laravel | PHP | フルスタック、必要な機能があらかじめ網羅されている（Batteries-included） |
表2 選択されたWebフレームワークの比較
これらのフレームワーク構造の違いは、外部パッケージへの依存度に影響を与えます。例えば、Djangoのように標準機能が充実しているフレームワークは外部ライブラリへの依存度を低く保ちやすい一方、JavaScriptのエコシステムでは多数の小さなパッケージを組み合わせる傾向があります。
プロジェクトにおけるセキュリティ管理体制の実態
各開発チームがセキュリティ管理をどのように行っているかを調査したところ、組織的な体制には大きな偏りがあることがわかりました。
- 開発者個人がセキュリティ業務を兼任（11/21人）：専任のセキュリティ部隊がおらず、機能開発を行う開発者が要件定義からデプロイ、基本セキュリティ基準の担保までを一貫して担当しています。
- 専任のセキュリティチームが対応（6/21人）：一定規模以上の企業組織などでは、脆弱性のトリアージや対応方針を決定する専門チームが存在します。
- 個人のメンテナーや少人数グループが対応（4/21人）：小規模なOSSプロジェクトなどでは、セキュリティ窓口はあっても実務は実質的に1〜2人の主要メンテナーが担っています。
図2 プロジェクトのセキュリティガバナンス
特に、LaravelやRuby on Railsの利用プロジェクトでは多くの参加者が「専用のセキュリティチームを置いていない」と答えており、開発者が自力で脆弱性に対処せざるを得ない現状があります。また、全体の7割（15/21人）の組織では、セキュリティ事故が発生した際の正式な報告・開示プロセスが確立されていません。
開発者の脆弱性認識とリスクへの意識
開発者が依存関係に起因するセキュリティリスクをどれだけ認識しているかという点においては、多くの回答者がリスクそのものは理解していると答えました。
図3 依存関係およびリスクへの意識
調査結果からは以下の現状が浮き彫りになりました。
- 脆弱性の認識：全体の大部分（19/21人）が外部依存関係の脆弱性リスクを認識していました。ただし、開発作業中は機能の実装が最優先され、スプリントの最後などの特定のタイミングまで対策を先送りにするケースも見られました。
- サプライチェーン攻撃の認識：13/21人はサプライチェーン攻撃のリスクを把握していましたが、8/21人はリスク自体の認識が極めて乏しく、「インタビューの中で初めて攻撃手法について聞いた」と答える回答者もいました。
- 被害の経験：大半の開発者（19/21人）は実際にサプライチェーン攻撃を受けた経験がありませんでしたが、2名は攻撃への対応を迫られた経験を持っていました。
異なるエコシステム間における対応力の境界
開発プロジェクトが複数の言語エコシステムをまたいで構築されている場合（例：バックエンドがJavaで、フロントエンドがJavaScriptなど）、脆弱性対応の難易度は高まります。
図4 エコシステム境界と対応能力
調査では、13/21人の開発者が自分の主言語以外（特にフロントエンドのJavaScriptライブラリ）の外部パッケージをプロジェクトに組み込んでいると回答しました。しかし、それらのパッケージの保守が停止した場合、大半の開発者は「他言語のエコシステムのコードまで調査して修正するスキルはない」と回答しています。
この結果から、エコシステムをまたぐプロジェクトでは、脆弱性が発見されても自分たちで修正することが難しく、別のパッケージへ移行するか、脆弱性を内包したままコードの使用を続けざるを得ない技術的障壁が存在することが判明しました。
依存関係の更新頻度と管理のアプローチ
開発チームが依存関係をどのようにアップデートしているか、その対応速度やアプローチにはいくつかの傾向があります。
図5 依存関係管理の対応アプローチ
19/21名の開発者は、DependabotやRenovateといった自動検知ツールを導入し、パッケージの脆弱性を自動的に検出していました。しかし、検出後の更新頻度は開発チームごとに大きく分かれています。
- 能動的な更新（11/21人）：定期的なアップデート手順を定め、脆弱性の報告をトリガーとして迅速に新バージョンに更新します。
- 受動的・選択的な更新（8/21人）：システムが本番環境で問題なく動作している限り更新は行わず、脆弱性の危険度が非常に高いと判断された場合のみ対応します。
- ほぼ更新しない（2/21人）：動作しているシステムに影響を与えることを恐れ、脆弱性が存在していても更新を回避する姿勢をとっています。
対応にかかる時間についても、自動化されたプルリクエストを受け入れて数時間から数日以内に完了できるチームがある一方で、変更によるエラーやテストの手間から解決までに1ヶ月以上を要するチームもありました。
攻撃の防御に向けたプロセスと活用ツール
開発チームがソフトウェアサプライチェーン攻撃による被害を防ぐために導入しているツールや防御の仕組みは、その習熟度によって3つに分類されます。
図6 サプライチェーン対策の取り組みレベル
- 組織化されたセキュリティプロセス（11/21人）：静的コード解析ツール（SonarQubeなど）の導入、CI/CDパイプラインとの統合、脆弱性スキャナー（OWASP Dependency Checkなど）の活用、プルリクエスト時の厳格なコードレビューといった、複数の防御策を組み合わせた開発環境を構築しています。
- 限定的・暫定的な対策（5/21人）：場当たり的な脆弱性診断ツールを実行するものの、自動化された監視プロセスには組み込まれていません。
- 有効な対策を持たない（5/21人）：サプライチェーンリスクについての知識が乏しく、防御のためのツール導入やルール作りが全く行われていません。
開発を支援する自動ツールの導入は進んでいるものの、それを開発の統合プロセス（CI/CD）に落とし込んで機能させているか否かで、プロジェクトの防衛力に大きな差が生じています。
脆弱性の解決を妨げる要因
開発者がライブラリの脆弱性を速やかに解消したくても、それを阻害する複数の現実的な要因が存在します。
図7 脆弱性解決を阻む諸要因
開発者への聞き取りから、脆弱性対処の主な障壁として以下の点が挙げられました。
- 時間と人員の不足：新しい機能開発に追われ、脆弱性対処のための時間を確保することが難しい現状があります。
- 新バージョンでの機能破損（破壊的変更）：セキュリティ修正パッチを適用するためにパッケージをアップデートした際、既存のプログラムが正常に動作しなくなる懸念が強く、更新作業の大きな心理的障壁となっています。
- 不十分なセキュリティ記述（CVE情報が曖昧）：公開される脆弱性情報（CVEなど）の説明が抽象的であり、自分たちのシステムが実際に危険にさらされているかを開発者自身で正しく判別できないという問題が発生しています。
脆弱性対処における相互影響関係の全体像
ここまで解説した各要素（開発者の認識、組織の体制、対応するエコシステムの違い、開発ツール、妨げとなる要因）は、個別に機能しているのではなく、それぞれが密接に絡み合いながら最終的な脆弱性管理の成果に影響を与えています。
開発者の脆弱性に対する「認識」はすべての意思決定の起点となります。しかし、適切な「管理体制」や「開発ツール」が欠如していると、その認識を「更新作業」という実際の行動へと移すことができません。
さらに、使用しているプログラミング言語ごとの「エコシステムの境界」や、既存コードを破壊する「互換性の問題」といった「解決を妨げる障壁」が、対応の完了を阻み、解決スピードを低下させる結果につながっています。
まとめ
今回の調査結果は、オープンソースパッケージの脆弱性を修正し安全性を確保する取り組みは、単なる「ライブラリの更新コマンドを実行する」という単純な技術作業ではないことを示しています。
開発チーム全体のセキュリティ意識、組織内の役割分担、テストのしやすさ（自動化の導入度合い）、そして他言語エコシステムに対する知識やサポートなど、様々な要因が密接に関連しています。企業やコミュニティが今後サプライチェーン攻撃から身を守るためには、ツールを導入して脆弱性を検知するだけでなく、開発者が安心して迅速にアップデート作業を実施できる「開発プロセスと体制作り」に注力する必要があります。
Webサービスや社内のセキュリティにお困りですか？ 弊社のサービス は、開発チームが抱える課題を解決し、生産性と幸福度を向上させるためのさまざまなソリューションを提供しています。ぜひお気軽にご相談ください！
参考資料：