Apache CXFがEOL(サポート終了)になっても、CVEの報告は止まりません。
対応バージョン:3.4、3.5
現在サポート終了となっているApache CXF 3.4または3.5上でアプリケーションを実行している場合、Never-Ending Support (NES) を利用すれば、アップストリームでのパッチ提供が終了した後も、アプリケーションを稼働させ続け、セキュリティを確保し、コンプライアンスを満たし、監査対応可能な状態を維持できます。移行も、コードの変更も、新しいバージョンの導入も必要ありません。
多くの企業から信頼されています

セキュリティ、コンプライアンス、事業継続
これらを一気通貫で解決
サポート終了したApache CXFのバージョンに代わる、当社の安全なドロップイン置換ソリューションを利用すれば、スキャナーがサポート終了したApache CXFのバージョンにおけるCVEを検出することは、今後一切なくなります。
セキュリティ
Apache CXF 3.4.x および 3.5.x には、アップストリームからのセキュリティ修正が提供されなくなりました。NES はメンテナンスされたビルドを公開しており、フレームワークに新たに発見された CVE に対してパッチが適用されるため、問題が蓄積されることはありません。
SLAに基づくパッチの提供は、深刻度に応じて行われる
HeroDevsは、発見された脆弱性を公開する公認のCVE番号付与機関です。
コンプライアンス
Apache CXF向けのNESの各リリースには、HeroDevsのVEXステートメントが同梱されており、CVEごとに1つずつ、修正が含まれる正確なアーティファクトとバージョンが明記されています。
SOC 2、PCI DSS、HIPAA、FedRAMP、ISO 27001、NIS2 など
監査担当者向けのパッチ適用履歴の記録
事業継続
Apache CXFのすべてのメンテナンス対象バージョンでは、少なくともJava 11が必要であり、4.xではjakarta.* ネームスペースへの移行も必要となります。アプリケーションがJava 8で動作している場合、移行先となるアップストリームバージョンは存在しません。NESでは、移行期間中も引き続きサポートを提供します。
移行を適切に行うための数ヶ月あるいは数年の猶予期間
移行コストやセキュリティ侵害によるコストのほんの一部です。
Apache CXF 3.4 および 3.5 については、アップストリームからのリリースは行われなくなりました。 3.5 の最後のパッチは 2025 年 3 月の 3.5.11、3.4 の最後のパッチは 2022 年 12 月の 3.4.10 であり、それ以降に公開されたすべての CXF セキュリティアドバイザリには、3.6 および 4.x 向けの修正のみが含まれています。現在、両方のバージョンラインにおいて、最終的なアップストリームリリースには未修正の CVE が存在しています。
リリースするすべてのパッチには、公開済みのCVEエントリがあります
HeroDevsは、CVEプログラムから権限を付与された公認のCVE番号付与機関(CNA)であり、HeroDevsが発見したセキュリティ脆弱性を特定し、CVE IDを割り当てる権限を有しています。
Apache CXF向けのNESの各リリースには、HeroDevsのVEXステートメントが同梱されており、CVEごとに1つずつ、修正が含まれる正確なアーティファクトとバージョンが明記されています。
現在、レガシー版のApache CXFを実行している場合、アプリケーションは以下の脆弱性の影響を受ける可能性があります。NES for Apache CXFは、これらの脆弱性を数分で修正します。
Apache CXF用のNESが公開する内容
アップストリームが 3.4.10 および 3.5.11 向けに公開したすべての org.apache.cxf ランタイム、トランスポート、セキュリティ、ツール、および統合アーティファクトは、NES 座標の下で公開されています。テストハーネス、アーキタイプ、および OSGi 統合テストは、顧客向けではないため、表示されていません。
コアとトランスポート
cxf-core
cxf-rt-transports-http
cxf-rt-transports-jms
cxf-rt-transports-http-netty-client
cxf-rt-transports-http-jetty
cxf-rt-transports-http-undertow
SOAP および WS-*
cxf-rt-frontend-jaxws
cxf-rt-bindings-soap
cxf-rt-databinding-jaxb
cxf-rt-wsdl
cxf-rt-ws-security
cxf-rt-ws-rm
cxf-rt-ws-transfer
cxf-services-sts-core
RESTとJAX-RSのセキュリティ
cxf-rt-frontend-jaxrs
cxf-rt-rs-client
cxf-rt-rs-security-oauth2
cxf-rt-rs-security-sso-oidc
cxf-rt-rs-security-jose-jaxrs
cxf-rt-rs-security-xml
cxf-rt-rs-extension-search
統合
cxf-spring-boot-starter-jaxws
cxf-spring-boot-starter-jaxrs
cxf-spring-boot-autoconfigure
cxf-integration-cdi
cxf-integration-jca
工具の製作
cxf-codegen-plugin
cxf-java2ws-plugin
cxf-wadl2java-plugin
cxf-wsdl-validator-plugin
あらゆる規格、フレームワーク、規制に対して、説得力のある回答を用意しています。
EOL(サポート終了)ソフトウェアは、世界中の規制におけるパッチ管理への期待を損なうものです。NESなら、ベンダーによるサポートが継続されるビルドを提供し、確約されたSLAと文書化されたパッチ履歴により、監査人や規制当局に対してコンプライアンスを証明することができます。
PCIデータセキュリティ基準
要件 6.3.3 では、既知の「重大」および「高」深刻度の脆弱性については、30 日以内にパッチを適用することが求められています。アップストリームからのパッチが提供されていない EOL 版の Apache CXF を使用している場合、コンプライアンス違反となります。NES により、パッチ適用経路が復元されます。
HIPAA
サポート対象外のフレームワークでは、ePHIを扱うシステムに対して適切な安全対策を講じることが困難になります。NESは、積極的なメンテナンスとリスク低減を提供します。
SOC 2
トラスト・サービス基準では、脆弱性の適時な是正とパッチ管理が求められています。EOL(サポート終了)となった依存関係については、代償となるサポート手段が存在しない限り、監査の際に重大な指摘事項となります。NESこそが、その代償となるサポート手段です。
NIS2
第21条では、パッチ適用、脆弱性、およびサプライチェーン管理について規定している。サポート体制が整っていないEOLソフトウェアを稼働させるとリスクが生じるが、NIS2では、事業者がこのリスクを積極的に軽減することが求められている。
DORA
DORAは、EOL(サポート終了)ソフトウェアを、金融ICT資産におけるレジリエンスのギャップと見なしています。NESでは、メンテナンスが継続されているビルドと、文書化されたパッチ管理プログラムを提供します。
サイバーレジリエンス法
デジタル要素を含む製品のソフトウェアライフサイクルにおけるセキュリティを管理します。NESでは、保証期間中、サポート終了(EOL)となったApache CXF製品ラインに対して、メンテナンスおよびパッチ適用済みのビルドを提供します。
NIST CSF 2.0
規制PR.PS-02では、組織に対し、リスクに基づいて脆弱性のあるソフトウェアを積極的に維持または削除することが求められています。NESを利用すれば、強制的なアップグレードを行うことなく、この規制への準拠が可能になります。
FedRAMP
継続的な監視では、定義された周期での脆弱性の修正が求められます。パッチが適用され、ベンダーのサポートが保証されたビルドがあれば、ISSOは、EOL(サポート終了)となったApache CXFを認証境界内に維持し続けることを正当化するための、文書化された修正手順を得ることができます。
商業契約
脆弱性および構成管理の対策には、技術的な脆弱性を特定し、ソフトウェアをセキュリティ基準の範囲内に維持することが求められます。NESは、EOL(サポート終了)ソフトウェアについても、そのセキュリティ態勢を回復させます。
当社は、オープンソースエンジニアやエコシステムへの貢献者たちと協力し、当社の「Never-Ending Support」製品が、オリジナル製品と同等の品質を保てるよう努めています。
プロジェクトに精通したエンジニアを参画させることで、オープンソースソフトウェアのメンテナンスにおける新たな基準を打ち立て、Apache CXF向けのNESが、その基盤となっているアップストリーム技術と同様に信頼性の高いものとなるよう保証しています。


私たちはオープンソースに貢献しています
オープンソースのメンテナーは極めて重要な役割を担っていますが、その対価として報酬を受け取ることはほとんどありません。
HeroDevsはこの現状を変えるため、2,000万ドルを投じ、エコシステムを支えるクリエイターやプロジェクトに対し、2,500ドルから25万ドルの助成金を提供します。
私たちは、メンテナンスされていないコードベースへのパッチ作成、誰も注目していなかった脆弱性の発見、そして急ごしらえの書き換えをせずに重要なシステムを安全に稼働させ続けてきました。この基金はそうした取り組みを基盤としており、メンテナーが自らの得意分野に専念し続けられるようにするためのものです。
よくある質問
HeroDevs による Apache CXF 3.4.x および 3.5.x のメンテナンス版です。セキュリティ修正は、アップストリームの最新リリースである 3.4.10 および 3.5.11 のフォークに反映され、NES バージョン文字列を含む同じ org.apache.cxf 座標で公開されるため、BOM のバージョンを 1 つ変更するだけで、それ以外の変更は一切必要ありません。
2つのブランチ:3.4.x(3.4.10からフォークされたもの)と3.5.x(3.5.11からフォークされたもの)。いずれもJava 8を必要とし、javax.* 名前空間を維持しています。CXF 3.6、4.0、4.1、および4.2はNESブランチではありません。
グループIDとアーティファクトIDは変更されません。NESバージョンのorg.apache.cxf:cxf-bomをインポートし、HeroDevsレジストリを追加して、再ビルドを行います。アプリケーションコード、設定、およびWSDL契約には変更を加えません。
CXFの独自コードにおけるCVEは、OAuth2およびOIDCフィルター、JMSトランスポート、WS-SecurityおよびSTS、XMLおよびWSDLの解析、添付ファイルの処理、Netty HTTPクライアントなどにわたって確認されています。修正ごとのVEXステートメントを含む最新のリストは、脆弱性ディレクトリおよびdocs.herodevs.comのリリースノートに掲載されています。
CXF 4.0 は jakarta.* ネームスペースに移行し、4.1 ではベースラインが Java 17 に引き上げられたため、すべての javax インポートと Java ランタイムが同時に変更されます。CXF 3.6 は javax を維持していますが、Java 11 が必要です。アプリケーションが Java 8 に固定されている場合、移行を行わなければ適合するアップストリーム版は存在しません。
各修正プログラムには、HeroDevsのVEXステートメントと、スキャナーが認識できるNESバージョン文字列が付属しています。これらは、PCI DSS、SOC 2、HIPAA、NIS2、DORA、およびEU CRAにおいて、監査人が求める証拠となります。HeroDevsはCVE番号付与機関です。
NESは、3.4および3.5の各シリーズが生産されている限り、それらのパッチ提供を継続します。CXF 4.xへの移行が行われる際には、インシデントが発生してからではなく、セキュリティが確保されたベースラインから開始されます。
リソース
すべての記事を表示
お問い合わせ
オープンソース・ライブラリのネバーエンディング・サポートについてご質問ですか?私たちがお手伝いします!
HeroDevsのNES製品がお客様のシステムの安全性とコンプライアンスをどのように維持できるかをご覧ください。
当社のソリューションがお客様の組織にどのような価値をもたらすかをご覧ください。
お客様のニーズに合わせた詳細な価格情報を入手できます。


