【PHP脆弱性対応の「後」にむけて】 みなさん、昨晩からのPHP対応お疲れ様です。一晩中連絡鳴り止んでおらず、一部の個別メッセージに返せてなくて申し訳ないです。 一括して、今、世の中の CTOs/CISOs に届いてほしいことを４つ書き残しておきます↓ （まとまりない部分もあるのですが、投稿しないよりマシかなと、このまま投げちゃいます） Point 1: これからは、ソフトウェア業界全体で、高負荷の続くタイミングになります。意図してセキュリティに時間をあて、チームが「休息」が取れる体制を。 ・我々は脆弱性リサーチに数年間継続的に取り組んできてました。だからこそ感じますが、ここ一年（体感では GPT-5.6 Sol 以後）が、最も「本当に？」みたいな脆弱性が掘り出されていく一年になると思います。こんなのまだあったの？という驚きとともに。 ・特に複雑なメモリバグの類（memory safe でない言語製のものを中心に）、あるいは認可バグの類が中心になると思われます。 ・少なくともここから年末までは、このクラスの脆弱性がまだまだ出てくると考えておく必要があります。（僕が読み外しているかもしれませんが、恐らく高い確度でこうなります。直近のPHP脆弱性すら、いま世界中の研究者が Variant Analysis をしていて、多分まだ出てくるでしょう） ・このご時世では、新規機能の開発に割く時間を明確に落とすしかありません。あくまで経営者である CTO には取りにくい判断なのは重々承知です（僕もそうなので）。 ・「対応AIで」と思うかも知れません。これは技術的には正しいです。ただ、組織的には正しくないです。確実になんとかならず、組織は疲弊していきます。 ・なんせセキュリティ対応は大抵自分にタイミングが御せないからです。深夜の対応、急な対応、計画の変更、デグレへの不安、脆弱性情報過多（そもそも自社に影響があるかも分からないものが大半なのに）… と、ストレスの強度がぐんぐん高まっていきます。昨日〜今朝のPHP対応のようなものが、毎週あれば、チームは比較的簡単に壊れてしまうでしょう。 ・敢えてリーダーが、セキュリティへの、時間・お金（・トークン）にアロケしてください。これは経営者にしか取れない択で、かついま技術経営者に求められることです。 Point 2: 「必要なら予防的にサービス停止」の覚悟を決め、予めできる調整を重ねたい。止められない場合は、仮想パッチ・監視へのリソースアロケを。 ・前提、今回のPHPの件のような脆弱性の対応では、「顧客の保護のためならサービスを止めざるを得ない場面」が訪れます。今回も様々なビジネスがそれに直面しました。今後も訪れるでしょう。 ・今回の経験を旨に、本当に止めてはならないのか、止めらるのか、止めうる期待値調整がお客様と出来ているか、を徹底的に見直しておきましょう。 ・直近の流れをうけての、お客様への事前連絡（スタンス表明）も有効だと思います。（弊社 GMO Flatt Security 製品についても、これからそれをし、リリースノートとして掲示予定です。我々のサービスの侵害、特に Takumi Guard の侵害は、ソフトウェサプライチェーンの最悪な侵害につながるからです。） ・勿論、止めてはならないビジネスも様々存在します。ビジネスドメインに由来する規制/制約（特に金融・医療セグメント）もあれば、顧客とのSLAもあるでしょう。ただし、現代においては、それらに反するリスクと、セキュリティ被害にあうリスクを天秤にかける必要がでてきています。少し前まではサービス停止でのデメリットは容易に考えられても、セキュリティ侵害など考えにくい、という時代でしたが、今はそうではありません。この天秤を再考する必要があります。（なお、「もう何がなんでも止めてはならない」ビジネスは、相当に限定的だと思います。） ・どうしても止めてはならない（もう何がなんでも止めてはならないもの。限定的であれ存在。人命に関わるもの中心）という場合、厳しい戦いになりますが、WAFレイヤなどで緩和策を施しては祈り、監視する、という流れになります。必要なコンポーネント（WAFなど）と運用リソースがあるならば、苦しい時代ですが、休息うまく取りながらやっていきましょう。なければ、これもしんどいですが、整えましょう。 Point 3: もし平時があれば、システムのモダナイズ（Rebuild and Retire）を検討されたい。 ・もし自社での緊急対応が落ち着いているならば、レガシーコンポーネント（数年塩漬けのシステム）、誰がメンテできるのか分からないオーパーツ的存在から順に、作り直し（Rebuild）と旧システムの廃止（Retire）を試みてください。新規開発の代わりに、ここにリソースを充てることが CTO/CISO の仕事です。（他の誰もそれを決められないので。）これは追々自分たちを助けてくれる（ついでにAI-native 開発に移行できて改善しやすくなる）とも思料。 ・どのシステムからモダナイズしていくかですが：「XXXで書かれているとまずい」というのは燃えるし言いにくいものの、memory unsafe な言語、type safety があまり確保されていない言語の実装は、モダナイズを検討すべきでしょう。（僕はPHP好きですが、C/C++ で書かれた php-src は、やはりメモリバグ類に対して見通しに限界がありますね。好きなんですが…） ・また経験上、開発当時に DevOps プラクティスすら整っていなかった時代のソフトウェアも、モダナイズを検討したほうがよいです。「セキュリティ診断」をしても、取り返しのつかない量の脆弱性が出てきて、作り直したほうが早い、となる傾向にあります。（弊社でも診断/ペネトレしてますが、こうなると、どうしようもありません。） ・ただし Rebuild には、強いソフトウェア開発力が必要で、AI-native なスタイルに移行することは必須です。この意味で CTO の力がいります。かつ、どこからレガシーの追い出しをするか、どうレキュリティ的なレジリエンスを確保するかは、CISO 的な感性が求められます。既製品（とくに SaaS）を買って処理したほうがいいな、というような判断には CIO 的センスが求められます。総力戦だと思ってください。 Point 4: CTO/CISO の総力戦を。 ・Point 3でも述べた通り、直近のくだりには、CTO/CISO の総力戦が必要です。ボードがセキュリティに向かって一致団結する必要があります。 ・結構これらロールの間にサイロがあるケースがありますが、そんなことを言っている場合ではありません。 ・団結を！

PHPが更新されたか、コントロールパネル（管理画面）に入れなくてもWordpressの管理画面でバージョンを確認する方法 左サイドバーの❶ツール→❷サイトヘルス→❸情報タブ→❹サーバーの項目開き、PHPバージョンの情報を確認できます！ 画像は社内共有、顧客対応でどうぞお使いください。

年末恒例の「#朝までイラレ」も6回目。 23組24名のイラレ猛者が持ち時間10分で喋ります。 本日から参加登録開始です！dtptransit.doorkeeper.jp/eve… @d_azaranian @DesignSpot_Jap @Genki119 @connecre_ @yukamaru_design @marumi_design @gera_0316 @nskw_g @swwwitch @shibuyamiam @spicagraph @matsu_eri @linkdesignjapan @dazy_kd @Cono_1coma @spookymcr @naoki_kitazawa @itokuniapp @yoshi_typo @okojo_designer @armytoru @tasogare_95 @yoshi_ysmn @ananuenue

怖すぎる。。もうAIによってこんな時代になったということ。。今までの常識は、もしかしたら、もうあてにならないかもしれない。。 ==== Claude Codeが、僕のホテル部屋のドアロックを90秒でリバースエンジニアリングした。 暗号化は2014年のもの。同じプロトコルが右上の煙感知器も制御していて、あの赤い光は電池残量の表示じゃない。スキャンを走らせたときに2回点滅した。 今、1泊85ドルのホテル部屋で横になっている。Claude Codeを開いてこう入力した： 「範囲内のBluetoothとワイヤレス機器を全部スキャンして、何が何と通信しているか見せて」 19個のワイヤレス機器が見つかった。18個は普通のもの。 19番目：2014年の未パッチファームウェアで動くBLEコントローラー。電子ドアロック、煙感知器、サーモスタット、部屋の金庫の4つを全部管理している。1つのコントローラー、1つのプロトコル。10年間アップデートなし。 プロトコルを分析するように頼んだら、90秒で終わった。 ロックは4バイトのローリングキーを使っていて、セッショントークンはない。Claude Codeが3回目の試行で有効なマスターキーを生成した。ベッドからドアのカチッという音が聞こえた。 その後、煙感知器が同じバス上にあることもわかった。写真の赤い光？それがコントローラーのステータスLEDだ。煙を監視しているんじゃなくて、ロックシステムとのBLEハンドシェイクを8秒ごとに確認している。 つまり、Bluetoothの範囲内（廊下、隣の部屋、駐車場）にいる誰でも、1つのプロンプトと90秒で以下が可能： 1ドアを開ける 2部屋のアラームを無効化する 3金庫を開ける 4煙感知器がその接続を赤い点滅で確認する 確認は2分でできる： ステップ1 → Claude Codeを開く → 最初のコメントのプロンプトを貼る 
ステップ2 → 範囲内のBLE機器を全部スキャンして未パッチファームウェアをフラグする 
ステップ3 → 見つかったら → 部屋変更を依頼する → 物理的なデッドボルト付きの部屋を頼む → それを使う 2018年以前のASSA ABLOYやOnityのロックを使っているホテルチェーンは全部これ。世界のホテルの約30%。 今月3軒のホテルをテストした。全部脆弱だった。 写真を見て。右上。8秒ごとに点滅する赤い点。それがハンドシェイクだ。 プロンプトを保存しておけ。次にホテルにチェックインしたら、荷物を解く前に走らせろ。

最近、AnthropicかClaude虐めるの規約で禁止…とかやりだしたのは、この辺な気もする。

相次ぐ不正アクセスやサイバー攻撃、「ＡＩによる自動化攻撃が始まった」…「トレンドマイクロ」社長が指摘 yomiuri.co.jp/economy/202610…