Upgrade to Pro — share decks privately, control downloads, hide ads and more …

260324「ちょっと脆弱性対応」が想像以上だった話

 260324「ちょっと脆弱性対応」が想像以上だった話

2026/03/24(火) ツナギメオフライン ベンキョウカイ #6 にて発表した登壇資料。
https://tsunagime-offline.connpass.com/event/385797/

Avatar for Takumi Abe

Takumi Abe

March 24, 2026
Tweet

More Decks by Takumi Abe

Other Decks in Technology

Transcript

  1. $ whoami あべたく @east_takumi { "普段": { "住み": "福岡県福岡市←→大分県国東市", "会社":

    "KDDIアジャイル開発センター株式会社(KAG)", "職種": "Webバックエンドエンジニア", "最近": "ジムおすすめ教えて欲しい" }, "コミュニティ活動": [ "JAWS-UG おおいた&福岡", "福岡クラウドUG", "AWS Community Builder(Serverless)" ] } 2
  2. 状況:誰も詳しくないリポジトリ ユーザー向け(Vue 3 )と CS 向け(Vue 2 )で別リポジトリ CS 向けはユーザー向けのクローンが起源、改修頻度が低い

    仕様書・試験書は 4 年以上前のまま 更新なし チーム内に詳しい人がいない → 当時の担当者にヒアリング アサインされたのは自分ともう一人、どちらも初見 →SDD を用いて対策(こちらはまたどこかで) 💡「脆弱性対応」だけのつもりで開けたら、想像以上の状態だった 3
  3. 判断① ライブラリより先に Node.js を直す 脆弱性対応しようとしたら… Node.js v16 → すでに EOL

    v16 のまま依存ライブラリを更新しても 保守性が下がる 脆弱性対応の効果も限定的 当初 PBI:ライブラリ脆弱性対応 ↓ スライス 追加 PBI:Node.js v16 → v24(先行) 💡 依頼作業の前提が壊れていたら、まずそっちを直す 4
  4. 判断② 動作担保できる状態を先に作る Node.js を上げて、 「動いている」と言えますか? 当時の状態: ✗ Unit Test なし

    ✗ リグレッションテスト → 手動・コード化なし ✗ 仕様書は古く、正確な情報が不明 → 判断:先に UT を作る(@vue/test-utils@1 を使用) 仕様把握の方法:古いドキュメントを逐次確認 + 当時の担当者にヒアリング + コード を読んで逆引き 💡 安全に変更できる状態を作ることは「コスト」?それとも「投資」? 5
  5. 結局こういう順番になった ① UT 作成(仕様把握 → テストコード化) ↓ ② Node.js v16

    → v24 ↓ ③ 依存ライブラリの v24 対応確認・代替ライブラリへの置き換え ↓ ④ 脆弱性対応(Dependabot アラート解消) ↓ ⑤ リグレッション試験 ↓ ⑥ Vue 3 移行 ↓ 完了! ……と思ったら 6
  6. リリース直前に、また脆弱性が出た(minimatch ) 対応完了・リリース直前に minimatch の脆弱性アラートが発生 eslint など主要ライブラリのコア部分で使われているライブラリが対象 影響範囲がかなり広く、単純なアップグレードでは解決しないケースも 対応方針 serverless

    3 →4 アップグレードで解決できる可能性が高い eslint 8 →10 アップグレードで解決できる可能性が高い htmlhint 撤去(gulpfile の build に含まれず現状不要) @vue/test-utils → js- beautify → editorconfig editorconfig が minimatch >=10.2.1 を要求す るリリースが確認できず、依存更新だけでは解決困難 7
  7. で、どうしたか アップグレードで解決できるものは対応できる eslint などはすでに Issue / PR が上がっており対応予定あり 問題は editorconfig

    経由のケース → 代替・構成変更が必要 無理やり直すと主要ライブラリとの互換性が壊れるリスクがある 今回はVue3 移行を優先して次回PBI に... また負債を積み上げた... (歴史は繰り返す) 8