AIの攻撃は速いが新しくはない：SBOM棚卸し・ログ監視・イミュータブルバックアップを今週やる

9〜10月の情報漏えい、入口は昔からのもの

2026年9月から10月にかけて、国内で情報漏えいの公表が相次ぎました。「AIで攻撃が別物になった」という声もありますが、公表された入口を並べると次の5つに収まります。

• Webアプリ・CMSの既知の脆弱性
• 公開APIの悪用（スマホアプリを解析してキーやエンドポイントを特定）
• BIツール・社内ツールの脆弱性（Metabaseなど）
• VPN機器と保守アカウント
• 委託先・クラウド事業者

JPCERT/CCの10月8日の注意喚起にも「AI」という単語は出てきません。AIが変えたのは攻撃の量と速度で、手口ではない、というのが記事の結論です。

防御側がやることは3つ

1. 何を持っているかを知る：SBOMでライブラリーを棚卸しする
2. すぐ気づいて反応する：GuardDutyなどの検知を、AIで24時間トリアージする
3. 壊されても戻す：バックアップを管理者でも消せない形にする

SBOMを実際に回してみた結果

syftとgrypeをDockerで動かし、手元のリポジトリを棚卸ししました。

• 識別できた部品：409個（Go 355、Python 46、GitHub Actions 7 など）
• 古いgrype（v0.86.1）：26件。DBが2026年3月で止まっていた
• 最新grype（v0.120.1）：109件。同じSBOMで4倍

初心者がつまずきやすいのは、スキャナーが古いDBでもエラーを出さずに動くことです。結果と一緒に「照合したDBの日付」を記録しましょう。

さらに109件を「本番に出る場所か」で分けると、Critical 9件はすべてローカルのTerraformキャッシュ由来で、本番のLambdaにあったのは15件でした。件数ではなく場所とKEV（悪用が確認された脆弱性カタログ）で優先順位を決めます。

記事で扱っている実践

• KEVカタログとの突き合わせコマンド（jq）
• 毎日SBOMを照合し直すGitHub Actionsの構成例
• GuardDuty → EventBridge → Lambdaで、戻せる封じ込めだけを自動化し、LLMには要約だけをさせる構成
• AWS WAFのレート制限ルール
• AWS Backup Vault LockとS3 Object Lockの設定コマンド

※2026年10月時点の公開情報に基づきます。設定例はデプロイ検証をしていない構成例です。

詳しくはこちら：
https://shinichi.noguchi.jp.net/blog/2026-10-09-ai-attack-same-old-defense.html