旧バージョンのAxiosは、必要な期間中、セキュリティが確保されています。
対応バージョン：0.24.x、0.27.x、0.33.x など
Axiosへの継続的なサポートにより、セキュリティチーム、エンジニア、経営陣は、EOL（製品サポート終了）に伴い失っていたもの――すなわち、自社のセキュリティ態勢、スケジュールを自ら管理し、ビジネスが注力すべき分野を決定する力――を取り戻すことができます。
多くの企業から信頼されています
セキュリティ、コンプライアンス、事業継続――これらを一体的に解決
サポート終了したAxiosのバージョンに対応した、当社の安全なドロップイン置換ソリューションを利用すれば、スキャナーがサポート終了したAxiosのバージョンにおけるCVEを検出することは、今後一切なくなります。
セキュリティ
AxiosのCVEが発見され、検証され、プロジェクトがもはやパッチを提供していないバージョンに対して修正が行われるたびに、このスタックに関するコアメンテナとしての専門知識を持つエンジニアによって、新しいリリースが提供されます。
SLAに基づくパッチの提供は、深刻度に応じて行われる
HeroDevsは、発見された脆弱性を公表する公認のCVE番号付与機関です。
コンプライアンス
インストールが完了すると、スキャナーはAxiosのCVEを検出対象から外すようになります。これは、当該ライブラリが積極的にパッチが適用され、商用サポートも提供されているためであり、これにより、未解決の監査指摘事項が解決済みとなります。
SOC 2、PCI DSS、HIPAA、FedRAMP、ISO 27001、NIS2 など
監査担当者向けのパッチ適用履歴の記録
事業継続
真のドロップイン：パッケージのインターフェースも、npmやCI/CDのワークフローもそのまま利用でき、アプリケーションコードの変更は不要です。Axiosをピン留めしていた親依存関係やランタイムについては、適切な順序で対応すれば問題ありません。
移行を適切に行うための数ヶ月あるいは数年の猶予期間
移行コストやセキュリティ侵害によるコストのほんの一部です。
リリースするすべてのパッチには、公開済みのCVEエントリがあります
現在、EOL（サポート終了）版のAxiosを使用している場合、アプリケーションは以下の脆弱性の影響を受ける可能性があります。NES for Axiosなら、これらの脆弱性を数分で修正できます。
11件のCVEが修正済み — 今後も増加中
レジストリの設定を1つ変更するだけ。コードの変更は不要。
package.json 内の Axios の依存関係を、以下の内容に置き換えてください。
以下の内容を含む .npmrc ファイルを作成してください
依存関係をインストールしてください
あらゆる規格、フレームワーク、規制に対して、説得力のある回答を用意しています。
レガシーソフトウェアや非公式のコミュニティによるサポートは、世界中の規制におけるパッチ管理への期待を損なう要因となっています。NESなら、ベンダーがサポートするメンテナンス済みのライブラリを提供し、確固たるSLAと、監査人や規制当局に提示できる文書化されたパッチ履歴を備えています。
PCIデータセキュリティ基準
要件 6.3.3 では、既知の脆弱性に対してパッチを適用することが求められており、重大な問題については 30 日間の SLA が定められています。パッチが適用されていない旧バージョンの Axios を使用している場合は、直ちに非準拠となります。NES はパッチ適用プロセスを復元します。
HIPAA
サポート対象外のコンポーネントがあると、ePHIを扱うシステムに対して適切な安全対策を講じることが困難になります。NESは、積極的なメンテナンスと、文書化されたリスク低減策を提供しています。
SOC 2
トラスト・サービス基準では、脆弱性の適時な是正とパッチ管理が求められています。セキュリティパッチが適用されていないレガシーコンポーネントは、認証不通過につながります。
FedRAMP
ベースラインはNIST SI-2に基づいており、定義された期間内に欠陥の修正およびセキュリティ更新プログラムの適用が求められます。政府のクラウド環境において、パッチが適用されていないレガシーソフトウェアは、コンプライアンス要件を満たしていません。
DORA
レガシーソフトウェアを、金融ICT資産の耐障害性における弱点と見なしています。NESは、重要システムに対して、文書化されたパッチ管理プログラムを運用しています。
NIS2指令
第21条では、パッチ適用、脆弱性、およびサプライチェーン管理について規定している。パッチが適用されていないレガシーソフトウェアは、リスクをもたらす場合、事実上、準拠していないものとみなされる。
GDPR
第32条では、「最先端の」技術的措置が求められています。サポート終了したレガシーソフトウェアを実行している場合、侵害が発生した後の正当性を主張するのは困難です。NESは、その依存関係を適切に管理しています。
NIST CSF 2.0
規制「PR.PS-02」では、組織に対し、リスクに基づいて脆弱性のあるソフトウェアを積極的に維持または削除することが求められています。NESを利用すれば、強制的なアップグレードや削除を行うことなく、コンプライアンスを確保できます。
サイバーレジリエンス法
サポート期間中は、製品およびそのコンポーネントの脆弱性を効果的に対処することが求められます。NESは、フロントエンドコンポーネントのサポートを確実に提供します。
ISO/IEC 27001:2022
脆弱性管理および構成管理の統制措置では、技術的な脆弱性を特定し、ソフトウェアをセキュリティ基準の範囲内に維持することが求められます。NESは、EOL（サポート終了）ソフトウェア向けのパッチ提供を通じて、統制態勢を回復させます。
CIS Controls AU
コントロール7（継続的な脆弱性管理）およびコントロール2（ソフトウェア資産の棚卸し）では、セキュリティ更新プログラムの提供が終了したソフトウェアを、本質的に脆弱であるとみなしています。NESは、ソフトウェアに常にパッチを適用し、監査可能な状態を維持します。
商業契約
多くの組織では、契約上、サポート対象外のソフトウェアを出荷することが禁じられています。NESは、各組織のポリシーで求められる、ベンダーによるサポートが保証されたソリューションを提供します。
当社はAxiosと提携しています
HeroDevsはAxiosのメンテナンス担当者と直接提携し、プロジェクトの持続的な運営と成長のための資金を提供しています。
私たちはオープンソースに貢献しています
オープンソースのメンテナーは極めて重要な役割を担っていますが、その対価として報酬を受け取ることはほとんどありません。
HeroDevsはこの現状を変えるため、2,000万ドルを投じ、エコシステムを支えるクリエイターやプロジェクトに対し、2,500ドルから25万ドルの助成金を提供します。
私たちは、メンテナンスされていないコードベースへのパッチ作成、誰も注目していなかった脆弱性の発見、そして急ごしらえの書き換えをせずに重要なシステムを安全に稼働させ続けてきました。この基金はそうした取り組みを基盤としており、メンテナーが自らの得意分野に専念し続けられるようにするためのものです。
よくある質問
お問い合わせ
オープンソース・ライブラリのネバーエンディング・サポートについてご質問ですか？私たちがお手伝いします！
HeroDevsのNES製品がお客様のシステムの安全性とコンプライアンスをどのように維持できるかをご覧ください。
当社のソリューションがお客様の組織にどのような価値をもたらすかをご覧ください。
お客様のニーズに合わせた詳細な価格情報を入手できます。
リソース
すべての記事を表示
