翻訳者 |静岩

校正者 | Chonglou

最近の調査によると、アプリケーションの90%以上にオープンソースコンポーネントが含まれていることが分かりました。これには十分な理由があります。オープンソースコードは無料でダウンロードできるため、開発者の効率が向上するだけでなく、イノベーションも加速します。

しかし、オープンソースを利用することの欠点は、依存するパッケージのセキュリティ確保に伴う隠れたコストが発生することが多いことです。Log4jとXZ Utilsを標的とした最近の悪意のある攻撃により、オープンソースソフトウェアのセキュリティへの注目が再び高まり、多くの組織にとって実装レベルの優先事項となっています。こうした背景から、多くのアプリケーション開発チームは、悪意のあるオープンソースパッケージがアプリケーションに侵入するのを防ぐための新たな方法を模索し始めています。

オープンソースパッケージが「悪質」になる理由

企業での利用に悪影響を与えるオープンソースパッケージを指すのに、私は「不良パッケージ」という表現をよく使います。パッケージが「不良」とみなされるのは、放棄された、非推奨となった、あるいは廃止されたと宣言された場合です。また、セキュリティポリシーが公開されていなかったり、セキュリティ問題への対処が不十分だったりする場合もあります。これは多くの場合、メンテナーが1人しかいないことが原因です。組織は、アプリケーション内のパッケージがマルウェアであることを発見し、パッケージマネージャーから削除しても、実際には「社内」でクリーンアップしないことがよくあります。

不良パッケージは、組織の収益、データ、顧客に影響を与えるセキュリティ リスクをもたらすだけでなく、パッケージの置き換え、回避、または脆弱性の修正の無限ループへの対処が必要になるときに貴重な開発時間を消費します。

これまで多くの組織は、自社のアプリケーションで使用されるオープンソースコードパッケージの脆弱性を特定し、修正するために、ソフトウェアコンポジション分析（SCA）ツールを活用してきました。これは、既存の脆弱性を確実に軽減するための効果的な方法です。しかし同時に、優先順位付けが難しい膨大なセキュリティ脆弱性のリストを分類し、誤検知と真のセキュリティリスクを区別するという、終わりのないモグラ叩きのような作業でもあります。SCAのみを使用すると、早期警告の兆候を見逃すだけでなく、パッケージの有効期限（つまり、無効と宣言されるタイミング）を見逃してしまう可能性があります。その結果、実際にはより大きな脆弱性が危険にさらされているにもかかわらず、誤った安心感を抱いたり、さらには攻撃を受けるリスクが生じたりする可能性があります。

そのため、多くの組織は脆弱性パッチ適用だけに頼るのではなく、使用しているオープンソースコードパッケージのセキュリティ対策をより深く理解することに積極的に投資しています。これにより、問題が発生する前に、悪意のあるパッケージへの依存をより体系的に減らすことができます。ここでは、組織が悪意のあるオープンソースソフトウェアパッケージによるリスクを特定し、軽減するために活用できる4つの主要な方法をご紹介します。

1. アプリケーション開発に組み込む前にパッケージを評価します。

質の悪いソフトウェアパッケージがもたらすリスクを回避する最善の方法は、まずそれらのパッケージがアプリケーションに使用されないようにすることです。オープンソースパッケージを調査・評価する際には、明確な審査プロセスを確立してください。パッケージは、この審査に合格した場合にのみ、使用を検討します。

検査でカバーされる一般的な問題は次のとおりです。

• 組織のライセンス ポリシーに準拠していますか?
• 積極的に保守されていますか、それとも放棄されていますか?
• メンテナンススタッフはセキュリティ問題に積極的に対応していますか？コミュニティは新しいバージョンの開発にどの程度積極的ですか？
• パッケージの依存関係とサブ依存関係は正常ですか?
• あなたやあなたのチームはコミュニティにどのように貢献できますか?

2. 現在使用されているオープンソース パッケージを積極的に監視します。

オープンソースパッケージは常に進化しているため、特定のパッケージまたはバージョンの使用を決定した後は、アップデートの監視と確認が不可欠です。パッケージまたはバージョンに問題がある可能性を示唆する早期の警告サインを探してください。具体的には、組織は以下のような兆候に注意する必要があります。

• 新しいバージョンがリリースされた後、現在使用している古いバージョンのサポートが終了する場合があります。
• 新しいバージョンは、異なるライセンス タイプを使用してリリースされる可能性があります。
• このソフトウェア パッケージは非推奨または廃止としてマークされています。
• このソフトウェア パッケージは、脆弱性の影響を頻繁に受けているようです。
• このパッケージの依存関係によりリスクが生じています。

3. すでに使用している問題のあるソフトウェア パッケージを特定して削除します。

最初から悪いソフトウェア パッケージを避けるのが理想的な選択肢ですが、ほとんどの組織では、セキュリティを確保するために適切に検査されていないパッケージがアプリケーション内にすでに多数存在しています。

したがって、すでに使用しているソフトウェア パッケージを振り返って、次の質問に答えることが重要になることがよくあります。

• このソフトウェア パッケージは、エンタープライズ グレードのセキュリティ ソフトウェア開発手法を使用していますか?
• 廃止または非推奨としてマークされていますか、それともライフサイクルの終わりが近づいていますか?

4. 本質的にリスクのあるソフトウェア パッケージを追加して、破損を防ぎます。

リスクの高いパッケージを特定することは、脆弱性が表面化する前に問題に対処するために不可欠です。しかし、重要なパッケージの安全を確保するもう一つの方法は、パッケージを適切にメンテナンスし、健全な状態に保つことです。

まず、使用しているパッケージのメンテナーが、安全な開発プラクティスの実践と、それらのプラクティスおよびコード自体の維持に対して、確実に報酬を得ているかどうかを調べましょう。組織にパッケージを導入する前に、パッケージの現状と長期的な見通しを積極的に把握しましょう。依存関係グラフに投資し、コードを提供することで、パッケージの長期的な健全性とセキュリティ維持に貢献できます。

結論

問題のあるオープンソースパッケージをアプリケーションから削除すると、攻撃の潜在的な侵入口がなくなり、セキュリティリスクを軽減できます。安全でないパッケージやメンテナンスが不十分なパッケージに起因するセキュリティ上の脆弱性を軽減することで、チームの生産性を向上させることができます。健全で回復力のあるオープンソースコードパッケージを使用してビルドすることで、アプリケーションの品質を向上させることができます。

原題: 4 Ways to Reduce Reliance to Bad Open Source Packages 、著者: Lauren Hanford