LLフレームワークの不都合な事実

Chuma Takahiro — Sun, 08 Nov 2026 05:58:06 +0000

現在進行形で世界的なセキュリティ脅威が拡大している。

いま起きていることは、ここ1年ほどで急拡大したAIのパワーを活用して新たなゼロデイ脆弱性が発見され、セキュリティパッチを上回る速度で攻撃が進行する事態と言える。

実際に運営を手がけているメディアDecider, directly.サイトを観測している限りでも、存在しないアドレスに対して世界各地からのアクセスが増えている。
リクエストの内容から、既知の脆弱性を持つプロダクトが提供するエンドポイントの存在をスキャンする挙動であることが分かる。

全体を俯瞰すると、運営サービスの安全性はつねに予断を許さない状況にある。ネットワークライブラリやカーネルが本来提供する役割のセキュリティ隔離を無効化する方法が続々と発見されているからだ。影響を受けていないにしても、それはひと通り確認できたうえで分かることで、防衛は消耗戦になる。

これは、航空自衛隊が近年、スクランブル哨戒を迫られる構図とよく似ている。深層で働いている力には同質性がある。

脆弱性は、直感的には悪用や攻撃として捉えられるが、実装形態としてはサービス機能の1つでしかない。
セキュリティ対策は、適切な挙動に修正することも含めて、サービス機能の削減のバリエーションと言える。

直近、社会で起きているインシデントをリアルタイムで確認している限り、廃止できるものを積極的に廃止していく方向が防衛に効果的と言える。

Web2.0が注目されていた頃のLL言語（PHP, Python, Ruby, Javascript）ベースのWebアプリケーションフレームワークから時間をかけて脱却してきたことが、かなり防衛に効いていることを実感している。

脱スクリプト

LL言語は、コードを書いたらすぐにその通りに動く性質が評価されて広まっている。
その機能はそのまま攻撃に利用できる能力になっていて、該当言語のスクリプトを置かれたらかなり自由に攻撃される、という関係にある。

Deciderのアプリケーションは、当初はRuby on Railsでスタートしたが、かなり早期にRustに移行した。
当時は、今のような体系的なサイバー・ウォーフェアを想定していたわけではなかった。しかし、スクリプト注入できるランタイムがないことの効果は絶大だ。

脱ORマッパー

2026年のサイバー攻撃の新たな特徴は、データベースを丸ごと外から取り出されるという被害形式が多発した点にもある。
これは、インジェクションで自由に実行される前項のバリエーションと、権限奪取によってフルデータアクセスを得るケースに大きく分かれている。

フルデータアクセスについては、アプリケーションがフルデータアクセスできているから外から取得できる、という関係にある。
これはあまり自明ではないが、防衛策は個々のSQLクエリが最小限のデータアクセスになっていることを保証する、というアプローチが必要になる。

そのためには、セキュアコーディングの慣行が必要となり、個別のパラメタライズドSQLのレビューを完備することが有効と言える。
これは、ORマッパーを利用すると簡潔に書ける、というWeb2.0時代のキャッチコピーとはかなり違う事態だ。

また、今年じっさいに報告されたインシデントでは、サービス本体ではなく外付けで導入した分析アプリケーションが流出経路になった例がある。
これも、レビューを経ていないSQLが存在している、という生態のバリエーションだろう。

コンテナ化

kubernetesによるコンテナ化については、さまざまな効果がある。
セキュリティ面では、万一侵入されたとして、悪用できる追加の脆弱性ランタイムにアクセスできない、という点が効果的と言える。

もちろん、初動の侵入を許したくはないのだが、ネットワークソフトウェアの実際の脆弱性を見る限り、運営者が最善の努力をしたとしてもノーガードになる瞬間は、残念ながら十分存在しうると見ている。
2026年10月のPHP2Shellは、世界中で緊急パッチ適用やサービス停止が相次いだ。これは、PHPのスクリプティングホストの側面というより、利用しやすいゼロデイ侵入経路の側面が強い。

このときCVE-2026-99999も同時進行しており、PHPホストがなくても強力な潜在脅威があった。しかし、脆弱なPHPホストがフロントにあった場合、直通でネットワークセキュリティを全面無効化できる側面があった。

このシナリオを評価していて、たとえ隔離の強度が下がる瞬間があったとしても、コンテナ化は防壁として有効と再認識した。

なおこれも自明ではないが、LLアプリケーションはRAM使用量が乱高下するので、OOMしやすくコンテナ化に向いていない性質がある。
サポートのためにrails consoleを起動したら、productionサービスがOOM killedで全部落ちたことがあり、これはLL言語全廃を決めた主要な理由だった。

セキュアコーディングには捨てる意思がかなり必要

LL WAF->Rustコンテナへの移行の主要な側面を整理した。

けっきょくのところ、防衛について注意すべき観点はセキュアコーディングの原則から来ている。
そうなると、無数のミクロな判断の積み上げが必要となり、モノリシックなシステムほど一足飛びに移行することが考えられなくなる。

また、移行過程で正常系の処理範囲を狭めるところに防衛力の源泉があるため、コードの機械的な置換では十分なガードが得られない可能性がある。
どちらかというと、段階的に廃止していくというより、限定された再実装コードに切り替えていかなければ最終的な保証を確認しづらい性質がある。

DEV Community: StarLeague Ltd.

LLフレームワークの不都合な事実

脱スクリプト

脱ORマッパー

コンテナ化

セキュアコーディングには捨てる意思がかなり必要