stonking（Ubuntu 26.10）の開発 / “Redhound”の導入とCIX P1への対応
UbuntuにおけるAI活用について、“ Redhound” と名付けられたCanonical社内で利用される監査エージェントの利用を開始していることが提示されています 。
LXDに関する3つの脆弱性の発見に成功したこのシステムは、静的解析によるコードベースの整理（Deterministic Recon） 、攻撃者が求めるであろう脅威ポイントの整理（Threat Modeling） 、攻撃仮説の反復ループ（Iterative Loop） 、攻撃可能点の検証（Debunking） 、信頼境界の影響評価（Impact Assessment）という5段階に分けられたプロセスでエージェントを動作させ、「 自動的なセキュリティアセスメント」を実現します。
具体的な利用サービスやモデルは明示されておらず、「 Built on frontier models」ということだけが示されています。全体的な評価が終わった後、検証ツールによる検証を通過した発見のみが、人間のレビュー担当者の手に渡った後、ゴーサインが出た場合はさらにドラフトレポートとPoCコードの生成までが実施できることが示されており（この時点で利用できる「最先端モデル」がだいぶ限定されるのですがそれはともかく） 、「 これまではきわめて高いスキルを持つ人間にしかできなかった」プロセスをAIベースで実施できることが示されています。
全体的には「既存のセキュリティプロセスにAIベースのツールを組み込んだ」「 新しい定期的な業務プロセスにした」というトーンで説明されており、革命的な変化というよりは「既存の検証を高頻度で実施できるようになった」という性質のAI導入となっています。Stonkingを含む今後のUbuntuのリリースにおいて、そして特にCanonical製のツール類のセキュリティ的な品質の向上に繋がることになるでしょう。
Stonkingの開発に直結はしないものの、26.04 LTSベースの実験として、「CIX P1 concept」 「開発者向けの概念実証のためのプレビュー」として位置づけられるもので、ベータテスト的な形で提供される（そして、正式なリリースになるかどうかは未確定）ものです。
これはCIX Technology 製のARM SoCベースのハードウェア向けのUbuntuです。デスクトップを含めて基本的な機能が動作します。「 新しいプラットフォームであるがゆえのトレードオフを受け入れる覚悟が必要です」という注意書きもあり、全機能が動作する期待で利用するべきではありません（バグを見つけたら積極的にバグ報告を行う必要がある、という意味です） 。
CIX P1はRadxa Orion O6 、Minisforum MS-R1 やOrange Pi 6 Plus のような、デスクトップ的な用途に向けたARM SoCで、45TOPSのNPUを搭載し、これまでのQualcomm Snapdragon系列と同じように「ARM版Windowsが動く」リッチなモデルです。8コアのA720（うち4コアは高クロックで動作）と追加4コアのA520のbig.LITTLE構成でGPUとしてはG720 MC10を採用しており、「 いまどき」のデスクトップ環境が動作します。
テスト済み環境として、以下の環境が提示されています。おおむね「今通常の方法で手に入るCIX P1搭載ハードウェア」すべてで動作する形です（CIX P1はACPIベースで動作するため、正しくデバイスが設計されていればこれら以外の環境でも動作することが期待されます） 。
MetaComputing AI PC Framework Laptop
Minisform MS-R1
Orange Pi 6 Plus
Radxa Orion O6
Radxa Orion O6N
該当するハードウェアを持っている、あるいはx64ベースの環境に飽きている（そしてRISC-Vではパワーが足りない）方は手を出してみてはいかがでしょうか。好評であれば今後、Stonking版もリリースされるかもしれません。
Ubuntu Core 26のリリース
26.04 LTSをベースにしたUbuntu Core、Ubuntu Core 26がリリース されています。
アピールポイントとしてあげられているのはsnap-delta、差分ベースでのSnapパッケージの更新と、Chiselによる「不要なファイルを含まない」最小構成が実現できること、そしてEU Cyber Resilience Act（CRA法）への準拠です。
組み込みやIoT文脈での選択肢として覚えておくと良さそうです。
その他のニュース
注目すべきセキュリティー的な視点： 基本の見直し国家サイバー統括室 が提供する「AI性能の高度化を踏まえたサイバーセキュリティ対策の強化について」において、日本国内の基本的な認識・考え方として、次のことが示されています。
発見された脆弱性のパッチ適用やリスク緩和措置を速やかに実施（リスクベース）
基本的な対策、多層防御の実施、インシデント発生時の備え 等
これとあわせて、次のような構造が示されています。今回は「基本的な対策」のうち、見逃されがち、あるいは意識的に運用しないと抜けがちな項目について考えてみましょう。
まず、もっとも重要な、しかし忘れられがちなこととして、「 拾い食い」をしない、ということがあります。ここでの「拾い食い」というのは、
適当に検索して、あるいはAIエージェントが提示してきた設定をそのまま採用する
なんらかの設定スクリプト（コピー＆ペーストで動作する）を、そのまま実行する
出自不明なパッケージを導入する
といったものが含まれます。いずれも「どのように動作するのか不明である」「 発行元が不明である」「 今後継続的に更新されるかが不明である」という欠陥をシステムに呼び込むことになりますし、「 拾った」ものに悪意がある可能性すらあります。
この意味では、「 設定の意味を理解する」ということも重要です。意味を理解していない状態で行われた設定は、それ以降の保守において大きなコスト増大を招くことになります。少なくとも「よくわからない」という情報は残しておくべきでしょう。
セキュリティに直結する他の観点としては、immutableな形でログを取ることも挙げられます。特定のホストが乗っ取られることを前提にした場合、そのホストにしかログがない、という状態では問題を検出することすらできない可能性があります。なんらかの異なるホストにログを転送する設定は必須です。
また、ブルートフォース対策として、認証系のレートリミットを持つ・弱い暗号系を使わない、といったことも必要になります。あらゆる認証系、そして通信系については一定のレートリミットや帯域上限を設定できるようにしましょう。
攻撃界面を減らすこともまた、典型的なものの重要なアプローチです。不要なポートへの接続性は絶つ、そもそも接続元を管理する、不要な機能は実装しない、といった方策が必要です。また、使用する端末を安全に保つためのエンドポイントセキュリティの導入も検討したほうがよいでしょう。
これに加えて、緩和策を利用できるように準備することも必要です。現在のLinuxではeBPFを用いてかなり柔軟な設定変更（＝緩和策の適用）が可能です。システムに適切な変更を加えられる余地を持つことで、「 何か見つかったとき」の時間稼ぎが可能になります。「 緩和策を利用できる」ためには、「 緩和策についての適切な情報収集ができている」ということも同時に必要です。
「適切なセキュリティの確保」「 基本」として整理されるものにも、それなりに落とし穴がありそうです。
