アプリの脆弱性対策は「ライブラリの把握と更新」から：Dependabotだけでは見逃す実例と、発注者が発注先に確認したいこと

納品したアプリが使っている部品には、すでに脆弱性が公表されているものが含まれていることがあります。

警察庁によると、令和8年上半期（1〜6月）のランサムウェア被害の報告は 123 件で、統計を取り始めてから半期として最多でした。被害を受けた企業の約 6 割が中小企業です。

攻撃の入り口になりうるのは、新しく書いたコードの穴だけではありません。更新されないまま残った古い部品も、その一つです。

アプリの脆弱性対策で、発注者が最低限確認したいことは 2 つあります。

• 把握: ライブラリの脆弱性を、ツールで継続的に見ているか
• 更新: 見つかったものを、決めた期限で直しているか

納品後に古くなるのは「部品」

アプリの多くの機能（ログイン、決済、画像処理、通信など）は、第三者が公開しているライブラリ（部品）に頼っています。その部品がさらに別の部品に頼っていることも珍しくありません。

納品した日は問題がなくても、その後に部品の脆弱性が見つかることがあります。コードを一行も変えていないのに、昨日まで安全だったアプリが、今日は「既知の脆弱性を含むアプリ」になります。

ソフトウェアのセキュリティ向上に取り組む非営利団体 OWASP は、部品の脆弱性や古さを放置するリスクを、2013 年版から Top 10 に挙げ続けています。2025 年版では「ソフトウェアサプライチェーンの不備」（3 位）に範囲が広がりました。

納品後の脆弱性対策は、部品の公表情報を見張って更新する仕事です。

把握する：ツールで継続的に見る

Dependabot が教えてくれること

数十、数百ある部品の脆弱性情報を、人が毎日調べるのは現実的ではありません。そこで使うのが、ツールによる自動の見張りです。

代表的なのが、GitHub（ソースコードの置き場所）に付いている Dependabot です。アプリのソースコードが使っている部品を調べ、脆弱性が公表されると「このバージョンに問題があります。修正版はこれです」と知らせてくれます。GitHub の機能の一つで、GitHub の設定で有効にします。まず入れておく価値があります。

それでも見逃すことがある

ただし、Dependabot を入れていれば安心とは言えません。

当社が保守しているあるアプリで、深刻度「高」の脆弱性が公表されている部品が 10 件ありました。ところが、Dependabot のアラートは出ていませんでした。GitHub 自身の脆弱性データベースと、部品の一覧には、その 10 件は載っていたにもかかわらずです。

GitHub の公式ドキュメントの説明から読み取ると、アラートが出ない、または出にくくなる条件は次のとおりです。

当社の事例で、どの条件に当たったのかは特定できていません。上の条件で起こりうること、実際に 10 件が見逃されたことまでは分かっています。

別のツールで、定期的に照合する

そこで当社は、見張りを二重にしました。GitHub が持っている「部品の一覧」（SBOM と呼ばれる部品表）を取り出し、別のツール（Trivy）で定期的に照合します。深刻度が「高」以上のものを、Dependabot のアラートと同じ画面に並べて表示します。Dependabot が同じ脆弱性をすでに追っているものは重複させません。

タップで拡大

見張りを二重にしたのは、一つのツールが見落とす前提で、別の経路を持っておくためです。

更新する：決めた順番で、定期的に

見つけても直さなければ、アラートが積み上がっていくだけです。当社が保守の計画を立てるために確認したあるアプリでは、未解決のアラートが 73 件ありました（緊急 3 件、高 36 件、中 26 件、低 8 件）。見つかっているのに、直されないまま残っていました。

深刻度で期限を決める

すべてを同じ優先度で直すと、重要なものが埋もれます。当社のある案件では、深刻度ごとに次の期限を決めて運用しています。

これは当社の運用例で、業界の標準ではありません。数字より、期限が決まっているかどうかが大事です。決まっていなければ「あとで」が続きます。

更新は壊れることがある

部品を新しくすると、アプリが動かなくなることがあります。そのため、当社では更新を次の順で進めています。

1. 部品を一度に全部上げず、少しずつ分けて更新する
2. 更新するたびにテストを通し、動作を確かめる
3. 問題がなければ反映する

当社のある案件では、更新の提案を自動で作るツール（Renovate など）を使っていますが、自動で反映はしません。必ず人が内容を見てから取り込みます。新しく公開された版に悪意あるコードが紛れ込んだ事例（2021 年の JavaScript の部品 ua-parser-js など）が実際にあるためです。

記録して、報告する

何が検知され、いつ誰が対応し、どれが残っているか。この対応状況を記録し、定期的に発注者へ報告します。ここまでやって、はじめて「把握して更新している」と言えます。

発注者が発注先に聞ける、「回っているか」を見分ける5つの質問

発注先、または現在の保守会社に、次の 5 つを聞いてみてください。

当社の見方では、「担当者が気づいたら対応します」という答えなら、回っていない可能性が高いです。

保守契約がないと、対応する人が決まらない

ここまでの作業には、継続的な工数がかかります。保守契約がなければ、納品した日の状態が、そのまま古くなっていくことになります。契約があっても、範囲に「把握」と「更新」が入っていなければ、先ほどの 73 件のように、見つかったものが残り続けることがあります。

「今は何も起きていないから」という理由で見送ると、更新がたまっていきます。たまるほど一度に直すのが難しくなり、毎月少しずつ直すより、費用もかかりやすくなります。

契約を結ぶ、または見直すときは、「把握」と「更新」が契約の範囲に入っているかを確認してください。

把握と更新のどちらが欠けても、古い部品は残り続けます。

出典

• 警察庁「令和8年上半期におけるサイバー空間をめぐる脅威の情勢等について」
• OWASP Top 10:2025「A03 ソフトウェアサプライチェーンの不備」
• GitHub Docs「Dependabot アラート」
• GitHub Docs「脆弱な依存関係の検出」
• GitHub Advisory Database「Embedded malware in ua-parser-js」（CVE-2021-4229）