SLA違反をなくす：パッチリリース前に脆弱性を修正する方法

【なぜ重要か】 Verizonの2026年版レポートによると、脆弱性の悪用は確認済み侵害の原因第1位となり、既知の悪用済み脆弱性（KEV）の完全修復率は2025年に26%まで低下（前年38%）、修復までの中央値は43日に拡大している。SOC 2やISO 27001の観点ではSLA超過自体が監査上の指摘事項となる一方、AIの進化により悪用リスクも高まっており、「製品開発を止めてパッチを当てる」か「SLAを破ってステークホルダーに説明する」かという二択を迫られるチームが増えている。

【ポイント】

• SLA未達の構造的原因：実質的にメンテナンスが放棄されたライブラリが本番システムの深部に組み込まれており、コンプライアンスポリシーはメンテナーの活動状況を考慮しないため、上流パッチを待つだけでSLAクロックが消費される。
• 現場チームが陥る5段階のループ：①上流パッチを待つ（否認）→②依存関係を丸ごと置き換える（怒り）→③例外申請で先送り（取引）→④自力でバックポート（抑うつ）という悪循環が生じており、いずれも根本解決にならない。
• Aikido Librariesの仕組み：パッケージ名と公開APIをそのままに、バージョンサフィックス（例：jsonwebtoken 8.5.1-aikido.5）を付与した修正済みライブラリを提供。パッチはメンテナー自身の修正をベースに対象バージョンへ適用し、自動テストと人によるレビューを経て、完全なdiffとともに提供されるため透明性が高い。
• 修復速度とカバレッジ：既知の悪用済み脆弱性は48時間以内、CriticalおよびHighのCVEは7日以内にパッチ済みライブラリを提供。JavaScript・Python・Java・.NET・PHP・Go・Rubyをカバーし、9,000以上のライブラリを収録、1日50〜100件のペースで追加中。
• 導入方法：リポジトリ単位またはコードベース全体に対してAikido UIから有効化でき、有効化後に開示されたCVEに対して毎日AutoFix PRを自動送信。パッチ適用と依存バージョンのアップグレードは独立した意思決定となり、新APIへの移行は任意のタイミングで実施可能。

【まとめ】 Aikido Librariesは、既存の依存バージョンを変えずにセキュリティパッチのみを適用することで、手動対応コストを増やさずにSLAを確実に守れる仕組みを提供する。まずAikidoのカタログで自プロジェクトの依存関係カバレッジを確認するか、対象リポジトリを登録して最初のマージ可能なPRを受け取ることから始めるとよい。