サードパーティコード

自社開発ではなく外部から導入したソフトウェア構成要素で、ライブラリ・フレームワーク・SDKなどを総称する。

サードパーティコード

概要

サードパーティコード(Third-Party Code)は、開発組織が自ら作成せず、外部の供給者やオープンソースコミュニティから導入して使用するソフトウェア構成要素を総称する。ライブラリ、フレームワーク、SDK、プラグイン、APIクライアント、オープンソースパッケージなどがすべてこれに含まれる。現代のソフトウェア開発では、生産性と機能拡張のためにサードパーティコードへの依存は不可欠だが、同時にセキュリティ・ライセンス・保守の側面のリスクも併せて管理しなければならない。

主な内容

定義と範囲

サードパーティコードは大きく3つに分類される。第一に、オープンソース構成要素であり、npm、PyPI、Maven Centralのようなリポジトリで配布されるパッケージである。第二に、商用ソフトウェア開発キット(SDK)であり、クラウドサービスやハードウェアメーカーの公式ライブラリである。第三に、外部委託開発の成果物やベンダーが提供するモジュール形式のコードである。

使用する理由

開発速度の向上: 認証、暗号化、ネットワーキングなど反復的な機能を再実装しなくて済む。
検証済みの安定性: 広く使われているライブラリは、すでに多くのプロジェクトでテストされている。
コスト削減: 自社開発および保守の人員を節約できる。
標準準拠: 産業標準のプロトコルとフォーマットを容易にサポートできる。

主なリスク

セキュリティ脆弱性

サードパーティコードはサプライチェーン攻撃(Supply Chain Attack)の主要な経路である。2021年のLog4Shell事態は、広く使われていたロギングライブラリの脆弱性が世界中の数百万のサービスに影響を与えた代表的な事例である。パッケージ名を悪用したタイポスクワッティング、悪性コードの挿入、依存性混乱(Dependency Confusion)攻撃も頻繁である。

ライセンス問題

GPL、AGPLのようなコピーレフトライセンスが含まれると、自社ソースの公開義務が生じることがある。逆に、MIT、Apache 2.0は比較的自由である。ライセンス表示義務を怠ると、法的紛争に発展しかねない。

保守の不在

オープンソースプロジェクトが中断されたり、メンテナーが消えたりすると、セキュリティパッチを受けられなくなる。これはしばしば「ゾンビ依存性」問題と呼ばれる。

バージョン衝突

同一ライブラリの異なるバージョンを要求する依存関係が絡み合うと、「依存関係地獄(Dependency Hell)」が発生する。

管理方策

SBOM(Software Bill of Materials)の作成: 使用中のすべてのサードパーティ構成要素をリスト化する。
SCA(Software Composition Analysis)ツールの導入: Dependabot、Snyk、OWASP Dependency-Checkなどで脆弱性を自動スキャンする。
ライセンスポリシーの策定: 許可・禁止ライセンスのリストを明文化する。
定期的なアップデート: セキュリティパッチ適用の周期を定め、自動化する。
最小依存の原則: 本当に必要なパッケージだけを導入し、推移的依存関係の数を管理する。

サードパーティコード