古くなったMavenアーティファクトのセキュリティ

Question

Mavenでは、開発者は過去10年の古いアーティファクトに依存しています（例えば、commons-el：commons-el：1.0は2005年にリリース、jettyはjavax.servlet：5.1.11リリース2007年に）。 Javaエコシステムでは、古いバージョンの成果物に依存するのが一般的です。その理由は、その更新がAPIを静かに破棄するためです。

セキュリティ上の欠陥が検出された場合、古いアーティファクトにパッチが適用されていますか？誰がこれを世話しますか？

spark org.apache.sparkの最新リリースについて：spark-core_2.11：2.0.0、依存関係の3GiBをダウンロードした後、私は2005年よりもさらに古いものを見ることができます結果として生じるスパークが実行された場合、それらの古くなった依存関係は、潜在的なセキュリティ上の欠陥を露呈するでしょうか？

注：これは約security of javaではなく、security of mavenではありませんが、mavenによって配信されるアーティファクトです。

Answer 1

Mavenのセントラルレポジトリrequirements推移的な依存関係のセキュリティ問題については説明しません。

推移依存性を更新する責任は、依存関係の所有者に依存します。依存関係のオーナー/保守担当者は、依存関係（セキュリティ欠陥のあるもの）を更新する際にコードベースで発生した問題に対する修正を実装する必要があります。不安定な推移依存関係を有することができるアプリケーション内の依存関係のユーザーとして、あなたはいくつかのオプションがあり

：

• アップデート依存の最新バージョンに、依存関係の所有者は、既に修正を実施している可能性があります。
• 保護されていない過渡的な依存関係を除外します。意図しない影響がある可能性があるため、自己責任で使用してください。安全でない依存関係は、必要な依存関係によって実際には使用されない可能性があるため、これはしばしば機能します。
• 依存コードベースをフォークし、不確実な推移依存を更新し、問題を修正し、プル要求を送信します。 Javaアプリケーションに依存関係のセキュリティに関する詳細なレポートをしたい場合は

また、あなたは、NIST NVDデータベースに対して（推移を含む）プロジェクトの依存関係をチェックしOWASP Dependency Checkerを、チェックアウトすることができます。

Answer 2

特定のパッケージでセキュリティ上の欠陥が発見された場合、新しいパッチバージョンが作成者によって公開されることが期待されます。あなたのところでは、古い脆弱なバージョンはMaven Centralに残っていて、一見するとこれは非常に悪いことです。

これは、次の明白な質問につながる：なぜ誰かがこれらの脆弱なバージョンにパッチを適用しない

• ？
• 誰かがこれらの脆弱なバージョンを削除しないのはなぜですか？

のは、結果を見てみましょう....

誰かが私が使用しているライブラリのバージョンを変更している場合、私はコードが機能同じままであることをどのように確信していますか？このため、パッチは新しいバージョンとして扱われます。それは作者にとってははるかに少ない仕事です。

古い脆弱なバージョンにパッチが適用されていない場合は、削除する必要がありますか？ユーザーがライブラリの最新のパッチを適用したバージョンを使用したくない場合、コードを壊す恐れがあるため、誰かが依存していたライブラリのバージョンを削除した場合、確かに不幸になります。あなたがしていれば気を失っていて、気をつけなければ...。

結論としては、ユーザのことです。依存関係を管理し、さまざまな基礎となるAPIの変更に適応する必要があります。変更を無視すると、アップグレードするオプションなしに脆弱性にさらされるリスクがあります。ソフトウェア開発へようこそ：