CVEが次々と報告され、エンジニアたちは予定外のメンテナンスに追われている
これは、単に消化して片付けることのできるバックログではありません。Evergreen を使えば、アプリケーション内のすべての依存関係が監視され、サポート終了時期（それが今日であれ、2年後であれ）が到来した際には、確実にカバーされます。
サポート終了となったパッケージのCVEは、すべてプロジェクトとなります
エンジニアは、脆弱性を評価し、アップストリームの修正内容を確認し、それが当初想定されていなかったバージョンにバックポートし、他の部分に不具合が生じていないことをテストした上で、それをリリースする必要があります。オープンソースがサポート終了（EOL）に達すると、メンテナーはセキュリティパッチの提供を停止するため、それに対する新たなCVEは、アップストリームのリリースではなく、あなたのチームの対応となるのです。
こうした作業はどれも計画されたものではありません。これらは、本来は別の業務に割り当てられていたリソースから捻出されたものであり、その別の業務については依然として成果を出す責任を負っています。そして、オープンソースの依存関係ツリーが拡大し、CVEの件数が増えるにつれて、作業の妨げとなる中断も増えていくのです。
上流のパッチの提供が停止すると、何が機能しなくなるのか
セキュリティ
CVEが公開されており、修正は未実施
コンプライアンス
それを示す証拠はない
ロードマップと予算
移行が挿入され、速度は予定外となった
.webp)
あなたのスタックには、サポート対象外のオープンソース依存関係がいくつありますか？
リポジトリ全体にわたる、直接的および推移的なすべてのライフサイクル終了時の依存関係に関するレポートを取得します。
問題点
よくある反応と、それらが持続可能ではない理由
その件を誰かに恒久的に担当させる
定期メンテナンス体制を導入すれば、業務の規模を縮小することなく、作業内容を予測可能にすることができます。これにより、一時的な中断を固定費に転換することになり、その四半期中は、ローテーション担当のエンジニアは何も開発を行わないことになります。
自動更新を活用しましょう
Dependabot と Renovate は、公開されている内容に基づいて解決を行います。サポート終了予定のブランチでは、その修正を含む公開されたブランチが上流に存在しないため、アラートが発火し、プルリクエストは送信されません。ツールは脆弱性の存在を確認しますが、これをクローズすることはできません。
AIを使って修正案を生成する
その普及は急速であり、ますます一般的になりつつある。ある独立した調査によると、AIが生成したコードのほぼ半数に新たな脆弱性が含まれており、レビューを経ないパッチについては、脆弱性を見逃したり本番環境に不具合を引き起こしたりした場合、誰がその責任を負うのかという疑問が残る。
解決策
Evergreenは、リメディエーションを業務の妨げから、ユーザーが管理できるキューへと変えます
リポジトリを一度だけ接続する
アプリケーションを構成する各リポジトリに、HeroDevs GitHub アプリをインストールしてください。
すべての依存関係には状態が割り当てられます
スキャンは自動的に実行されます。サポート期間中はすべての依存関係が監視され、サポート終了となりCVEが登録されると、修正処理のキューに入れられます。
リプレースメントはプルリクエストとして到着します
依存関係ごとに1件のプルリクエストを受け付け、深刻度順に並べ替え、1日あたりの上限を設けています。レビューとマージはご自身のスケジュールに合わせて行ってください。
なぜHeroDevsなのか？
1900万人以上
追跡対象のパッケージバージョン
1,000+
脆弱性の修正が完了しました
900+
HeroDevsがセキュリティ対策を実施している法人顧客
戦略的なロードマップを損なうことなくセキュリティ体制を維持しつつ、完全移行と比較して大幅なコスト削減を実現しました。
マルクス・ヴォルフ、建築家 @ Statista
マージできるプルリクエストと、管理できるキュー
.webp)
セキュリティおよびコンプライアンス担当者が尋ねる質問
もちろん、お探しの答えが見つからない場合は、お気軽にお問い合わせください。
ここに記載されていない内容がありますか？ 専門家に相談する。