これからの取り組み

この章では、Tauri アプリをさらに安全なものにするために開始した案件や、今後取り組みたい内容について説明します。 このような活動に興味がある、あるいは何らかの知識をお持ちの場合は、新しく貢献者になっていただける方もあたらしいアドバイスをお持ちの方もいつでも歓迎致します。GitHub や Discord、あるいは他のコミュニティ・プラットフォームを通じてご連絡ください。

バイナリ解析

侵入テスト担当者^※や監査担当者の方々、自動セキュリティ・チェックにその役割を適切に遂行してもらうためには、コンパイルされたバイナリからでも知見を得ることは非常に価値があります。すべての企業がオープン・ソースであるわけでもなく、監査、レッド・チーム^※、その他のセキュリティ・テスト用にソース・コードを提供して貰えるわけでもないからです。

《訳注》

・侵入テスト担当者　（pentester）：　 ＝ penetration tester（字義的な訳としては「貫通試験者」）。「侵入テスト」は pentest と表記されています。
・レッド・チーム　（red team）：　セキュリティの脆弱性を検証する社内専任チーム。

また、しばしば見落とされがちなもう一つの点は、あなたのアプリケーションに内蔵されたメタデータを提供することで、ユーザー自身がそのアプリケーションを用いて構築した自分のシステムを、その生涯と労力を監査作業に注ぎ込むことなく、既知の脆弱性に対してより大きなものさしで監査できるようになることです。

もしあなたの「脅威モデル」が、「隠蔽によるセキュリティ^※」に頼っているものであるならば、以下に対策ツールや論点をいくつか提示しますので、これらがその脅威モデルを再考する機会になれば幸いです。

《訳注》

・隠蔽によるセキュリティ　（security by obscurity）：　設計や実装を非公開化（隠蔽）することによってセキュリティを確保する方法。この方法は非公開情報が漏洩した場合の防衛手段が存在しないため、非推奨です。Security Through Obscurity (STO) とも表記されます。

バックエンド側に用いられる Rust 言語には SBOM／ソフトウェア部品表 を作成し、再現可能なビルドを毀損することなく、バイナリの正確なクレート・バージョンと依存関係の情報を提供するするためのツール「cargo-auditable」があります。

ウェブ標準言語が用いられているフロントエンド・スタックでは、同様の解決手法を知りませんが、バイナリからフロントエンド・アセットを抽出するのは単純明快な手順のはずで、 後で npm audit などのセキュリティ監査ツールを使用して既知の脆弱性を把握できるに違いありません。 この抽出プロセスに関する ブログ投稿 はすでにありますが、手軽なツール自体はありません。

Tauri では、特定の機能を備えた Tauri アプリのコンパイル用に、そのようなツールの提供やアセットの抽出を容易にすることを計画しています。

Burpsuite、Zap あるいは Caido といった「侵入テスト pentesting」ツールを利用するには、WebView からトラフィックを捕捉し、「テスト用プロキシ^※」を通過させる必要があります。 現時点では、Tauri にはこれを実行するための組み込みメソッドを持っていませんが、このプロセスを容易に行なうための作業が進行中です。

《訳注》

・テスト用プロキシ　（testing proxy）：　プロキシは「代理／委任」の意味。アプリとサーバー間、あるいは、アプリのフロントエンドとバックエンド間の通信を捕捉して分析・テスト・脆弱性の検証を「代行」する役割のプロキシ型セキュリティ診断ツール。すなわち「侵入テスト・ツール」として名前の挙がっている「Burpsuite」や「Zap」「Caido」などを指します。

このようなツールはどれも、ソース・コードにアクセスすることなく Tauri アプリケーションを適切にテストおよび検査できるため、Tauri アプリケーションをビルドする際にに考慮すべきものです。

Tauri は、今後も関連機能の更なるサポートと実装を計画しています。

WebView の強化

Tauri の現在の「脅威モデル」や「統制領域^※」では、（外部技術に依存する）WebView 本体に更なるセキュリティ制約を追加することはできません。また、WebView は「メモリ安全ではないプログラミング言語^※」で記述されており、Tauri のプログラム構成（スタック）において最大の部分を占めているため、WebView プロセスをさらにサンドボックス化して隔離化する方法を調査・検討する予定です。

《訳注》

・統制領域　（boundaries「境界」）:　Tauri アプリケーションの脆弱性対策（統制）が及ぶ範囲の境界と解釈してあります。
・メモリ安全ではないプログラミング言語　（an memory unsafe language）：　メモリ・アクセス時のプログラミング・エラー防止機能や制約が欠如しているプログラミング言語。例えば C/C++。Tauri は C/C++ などのプログラム言語で記述された外部の WebView プログラムを借用しているため、「安全ではない」と言われています。「メモリ安全なプログラミング言語には、Rust/Go/Java/C#/Swift/Python/Ruby/Ada などがあります。《参考：Wikipedia》

セキュリティ攻撃の影響を軽減し、システム・アクセス^※に対して IPC ブリッジ（プロセス間通信）が強制適用されるようにするために、埋め込み型および外部のサンドボックス方式を評価する予定です。 Tauri プログラムの構成要素中では、この部分が脆弱箇所であると考えていますが、現行世代の WebView ではセキュリティ強化とエクスプロイト耐性^※（セキュリティー脆弱性攻撃への耐性）が向上しています。

《訳注》

・システム・アクセス　（system access）：　アプリケーションのコア部（すなわち Rust で書かれたバックエンド部）やその先のオペレーション・システム（OS）の機能に対するアクセス。このWebView の強化の項では、セキュリティに問題があるフロントエンド部（WebView）からのデータ受け渡しを、安全に送受信する仕組みである「プロセス間通信（IPC）を介して行ない、アプリケーション・コア部（バックエンド）やその先の OS との処理の安全性を確保するためのセキュリティ強化の取組について述べています。
・エクスプロイト耐性　（exploit resilience）：　exploit「偉業」＋ resilience「弾性／復元力」。ソフトウェアのセキュリティ脆弱箇所を悪用した攻撃に対する「耐性／回復力」（＝ソフトウェアの正常な機能を継続・維持する能力）。尚、exploit には動詞として「〜を利用する」「〜を不当に使う」「〜につけ込む」などの意味もあり、元々はハッカーのスラングとして「システムのすごい抜け穴（を見つけたという偉業）」に「つけ込む」というところから用いられるようになった模様。《参考：Wikipedia》

ファジング処理（Fuzzing）

《訳注》

・ファジング処理　ファズ・テスト。コンピュータプログラム検証プロセスのひとつ。無効な、予期しない、ランダムなデータ（fuzz と呼ばれます）を入力し、意図的に例外状態を発生させてシステムの検証を行なう方法。《参考：Wikipedia》

Tauri アプリケーションのファジング処理プロセスをより効率的かつ簡素化するために、「モック・ランタイム^※」やその他のツールをさらに実装して、個々の Tauri アプリケーションの設定やビルドを容易にすることを目指しています。

Tauri は多くのオペレーティング・システムと CPU アーキテクチャをサポートしています。通常では、アプリにメモリ安全性を持たないコードが含まれる可能性はほとんど、あるいはまったく、ありません。 こうした複数の OS と CPU に対応するアプリケーションでの、普通とは異なる「ファジングのユース・ケース^※」には、既存のファジング・ツールやライブラリで対応できないため、Tauri のファジング・フレームワークの構築には、独自のファジング機能を実装し、libAFL などの既存のライブラリを拡張する必要があります。

「ファジング」面での対応目標は、ファジング機能を Tauri アプリケーション開発者のために入手しやすく、効率的にすることです。

《訳注》

・モック・ランタイム　（mock runtime）：　実機や本番のシステムがない環境で、実際の動作確認が行なえるように、本番環境を模倣（モック）するダミーの実行環境のこと。
・ユース・ケース　（use case）：　具体的な使用事例。ユーザーがそのシステムを利用して達成できる具体的な目標や一連の操作を記述したもの、またはそのシステムに必要な機能要件を明確化したもの。

【※ この日本語版は、「Sep 9, 2026 英語版」に基づいています】