アプリケーション・ライフサイクルでの脅威
Tauri アプリケーションは、その「アプリケーション・ライフサイクル」（製品サイクル）の様々な段階で加えられた多くの要素から成り立っています。 この章では、ライフサイクル中の従来からある脅威と、それに対してどのように対処すべきかについて説明します。
以下のそれぞれの処理ステップが、下記の各セクションにて説明されています。
上流工程での脅威
Section titled “上流工程での脅威”Tauri は、あなたのプロジェクトと直接の依存関係※にあります。Tauri チームは Tauri のコミット、レビュー、プル・リクエスト、リリースに関して厳格な管理者としての統制を行なっています。 また、依存関係を最新の状態に保ち、更新またはフォーク・修正を行なうための措置を講じることにも最善を尽くしています。Tauri 以外のプロジェクトでは Tauri ほど適切に管理されず、監査が一度も行なわれていないかもしれません。
・依存関係 dependency： アプリケーションなどのビルド・実行を行なうために依存している（＝必要となる）外部のプログラムやライブラリ、モジュール等の情報。通常、パッケージ管理ソフトウェア等にて依存関係情報は登録・管理されています。
外部のライブラリ・プラグイン等を統合する際には、その健全性を考慮してください。さもないと、知らないうちに自分のアプリが「構造的負債（architectural debt）」を抱えてしまう可能性があります。
自分のアプリケーションを最新の状態に保つ
Section titled “自分のアプリケーションを最新の状態に保つ”アプリを「在野に」リリースする場合、Tauri が含まれたバンドルも出荷することになります。
そして Tauri に影響する脆弱性があれば、アプリケーションのセキュリティにも影響を及ぼし兼ねません。
そこで Tauri を最新バージョンに更新することで、重大な脆弱性にはパッチが当てられ、アプリケーションで悪用されることがなくなるのです。
また、コンパイラ（rustc）とトランスパイラ（nodejs）も最新の状態に保ってください。というのも、セキュリティ上の問題が解決されていることがよくあるからです。
これは開発システム全般にも言えることです。
依存関係の評価
Section titled “依存関係の評価”NPM（Node Package Manager）や Crates.io からは多くの便利なパッケージ群が提供されていますが、 信頼できるサードパーティのライブラリを選択するのはあなたの責任です。さもなければそのライブラリを Rust ですべて書き直してください。 既知の脆弱性の影響を受けていたり、メンテナンスされていない古いライブラリを使用すると、あなたの「アプリケーションのセキュリティ」と「心地よい一夜の眠り」が危険に曝されることになるかもしれません。
このプロセスを自動化するために npm audit や cargo audit などのツールを利用し、セキュリティ・コミュニティの重要な取り組みに頼りましょう。
cargo-vet や cargo crev のような Rust エコシステム※の最近の傾向は、サプライチェーン攻撃の可能性をさらに低減するのに役立つでしょう。
自分が誰の肩の上に立っているか、すなわち、どの先人の知識を利用させて貰っているのか、を知るには、cargo supply chain ツールを使用してください。
・エコシステム ecosystem： 元々は「生態 ecology」＋「系 system」の合成語ですが、ビジネス関連の用語としてはしばしば「ビジネス生態系」と訳されており、「経済 economy」＋「系 system」の合成語であるように思われます。Rust ecosystem とは「Rust を中心とする経済系」、すなわち、共通のプラットフォーム／基盤（Rust）を中心に様々な企業・組織が相互に緩やかに関連・影響・依存し合いながら共存共栄して事業活動を進めるビジネス圏のことです。「Rust 共栄圏」。
私たちが強く推奨している方法は、最善の策としては「コミット・ハッシュ値（hash revisions※」を使用して、次善の策としては「名前付きタグ（named tags）」を使用して、重要な外せない依存関係だけを Git から使用することです。 これは Rust だけでなく Node のエコシステムにも当てはまります。
・コミット・ハッシュ値 hash revisions / revision hashes： Gitなどのバージョン管理システムにおいて、各コミット（変更 revision の記録）を識別するために割り当てられる一意の英数字の文字列（ハッシュ値）。
開発時の脅威
Section titled “開発時の脅威”開発者であるあなたは、開発環境に気を配っていることと思います。 使用しているオペレーティング・システム、ビルド・ツールチェーン、および関連する依存関係が最新の状態に保たれ、適切に保護されているかを確認するのはユーザーであるあなたの責任です。
私たち全員が直面している真のリスクは、「サプライチェーン攻撃」と呼ばれるもので、それは通常、あなたのプロジェクトの直接的な依存関係に対する攻撃であると考えられます。 しかしながら、開発マシンを直接標的とする攻撃が巷では増加しており、この問題にも正面から向き合って備えておきましょう。
開発サーバー
Section titled “開発サーバー”Tauri アプリケーションのフロントエンドは、多くの Web フレームワークを使用して開発できます。 こうしたフレームワークはどれも、通常、それ自体の開発サーバーを同梱しており、フロントエンドのアセットはオープン・ポート経由でローカル・システムやネットワークに公開されています。 これにより、フロントエンドは WebView やブラウザ上で「ホットリロード」（アプリ実行中にコードの変更を即座に画面に反映する機能）や「デバッグ」ができるようになってしまっています。
実際、この接続は、大抵、デフォルトでは暗号化も認証もされていません。 このことは組み込みの Tauri 開発サーバーにも当て嵌まり、あなたのフロントエンドとアセットがローカル・ネットワークに公開され、無防備な状態になっているのです。さらに言えば、これにより攻撃者が、攻撃者と同じネットワーク内にある開発デバイスに対して、攻撃者自身のフロントエンド・コードをプッシュできるということです。 どのような機能・内容が無防備な状態にあるのかにもよりますが、これは、最悪の場合、デバイスのセキュリティ侵害につながる可能性があります。
したがって、あなたは開発デバイスを安全に公開可能な信頼できるネットワーク上でのみ開発を行なう必要があります。 それが不可能な場合は、あなたが使用している開発サーバーがあなたの開発デバイスとの接続に、「相互認証」と「暗号化」を使用していること（たとえば「mTLS※」など）を必ず確認してください。
・mTLS （mutual Transport Layer Security）： 相互TLS認証。クライアントとサーバーの間で相互認証を行うための業界標準プロトコル。クライアントとサーバーの両方が、信頼できる認証局（CA: Certificate Authority）によって発行された有効なデジタル証明書を保持していることを確認することで、相互に認証する仕組みです。《参考》
開発マシンの強化
Section titled “開発マシンの強化”各自の開発システムを強化する内容については、さまざまな要因や開発目的により、対応が必要となるそれぞれ固有の脅威モデルによって異なりますが、一般的なアドバイスとして、以下のようなことをお勧めします：
- コーディングなどの日常的なタスクに管理者アカウントを使用しない
- 開発マシン上で本番環境の秘密情報を使用しない
- 秘密情報をソースコードのバージョン管理で検証しない
- セキュリティ・ハードウェア・トークンなどを使用して、セキュリティ侵害のあるシステムの影響を軽減する
- 自分のシステムを最新の状態に保つ
- インストールするアプリケーションを最小限に抑える
より実用的な方法についての様々な情報は、『優れたセキュリティ強化コレクション／awesome security hardening collection 』（英語サイト）でご覧いただけます。
もちろん、自分の開発環境を仮想化して攻撃者を寄せ付けないようにすることもできますが、それだけでは、開発マシンだけを標的にした攻撃への対応のみで、あなたのプロジェクトそのものを標的とする攻撃には対処できません。
ソース管理認証と承認の確実な実施
Section titled “ソース管理認証と承認の確実な実施”大多数の開発者と共同作業をしているような場合、ソースコードの「バージョン管理ツール」と「サービス・プロバイダー」を利用することは、開発中の不可欠な手順です。
あなたのソースコードが権限のない者によって変更されないようにするためには、ソースコード・バージョン管理システムのアクセス制御を理解し、正しく設定しておくことが重要です。
また、悪意のあるコミットが、セキュリティ侵害を受けていない貢献者、あるいは悪意を持たない貢献者のせいにされないためにも、すべての（常連の）貢献者に対して、コミットへの署名を要求することを検討してください。
ビルド時の脅威
Section titled “ビルド時の脅威”現代のシステム開発では、バイナリ成果物を作成するために「CI/CD※」（継続的インテグレーション／継続的デリバリー）と呼ばれるアプリケーション開発自動化プロセスを使用しています。
・CI/CD （Continuous Integration/Continuous Delivery）： 「継続的インテグレーション／継続的デリバリー」。ソフトウェアの変更（コードの追加や修正）を共有リポジトリ内で、自動的にビルドやテストを実行して統合し《継続的インテグレーション》、テストを通過したコードをいつでも本番環境へリリースできる状態に保つ《継続的デリバリー》、自動ワークフローの開発手法および仕組み。CD は「継続的デプロイメント（自動展開）」と呼ばれる場合もあります。《参考》
こうした CI/CD を行なうリモートの（サードパーティ所有の）システムは完全に信頼できるものである必要があります。というのも、そのようなリモート・システムはソースコードやシークレット（機密情報）にアクセス可能であり、ビルドを変更できてしまいますが、そうして生成されたバイナリが、あなた自身のローカル・コードと同一であることをあなた自身が検証可能な形で証明できないからです。 このため、信頼のおけるプロバイダーを頼りにするか、自ら管理するハードウェア上に CI/CD システムをホストする必要があります。
Tauri では、さまざまなプラットフォームでアプリを構築するための「GitHub ワークフロー」を提供しています。 しかし、もし自分自身で CI/CD 環境を構築し、（GitHub Actions などの）サードパーティのツールに依存している場合には、あなたが明示的に適用バージョンを指定していないアクション（プラグインやツール）には十分な注意を払ってください（意図しないバージョンが用いられる危険性が有ります）。
あなたは、配布先のプラットフォームに合わせて、自分の作成したアプリのバイナリに署名する必要があります。 このやりかたは手順が複雑で、幾分コストがかかる可能性はありますが、エンド・ユーザーはあなたのアプリがあなた自身から発行されたものであるということの証を求めているのです。
もし「暗号に関する秘密情報※」が適切にハードウェア・トークンに保存されていれば、セキュリティ侵害されたビルド・システムでも関連する署名キーが漏洩することはありませんが、それでも「悪意のあるリリース版」が作られ、その署名に使用されることはありえます。
・暗号に関する秘密情報 （cryptographic secrets）： 「暗号秘密情報」「暗号化シークレット」「暗号シークレット」と訳される場合もあります。コード署名用の秘密鍵や自動アップデート検証用の非対称秘密鍵、ユーザーデータを保護するための暗号化マスターキーなどの厳重な管理が要求される秘密情報のことです。
再現可能なビルド
Section titled “再現可能なビルド”ビルド時の「バックドア・インジェクション」（バックドア型攻撃）に対抗するには、ビルドを再現可能にする必要があります。そうすることで、自分の PC でビルドしたときでも、別の独立したプロバイダーでビルドしたときでも、ビルド・アセットがまったく同じであることを検証できます。
第一の問題は、Rust が完全に信頼性のある再現可能なビルドをデフォルトで生成していないことです。理論上はこれをサポートしていますが、まだバグがあり、最近のリリースでも再現性問題が散発しています。
現在の状況は、Rust プロジェクトの 公開バグ・トラッカー《英語版》で追跡可能です。
次に遭遇する問題は、多くの一般的なフロントエンド・バンドラーが再現可能な出力を生成しないことで、そのため、バンドルされたアセット（最終的な Tauri アプリの形）でも再現可能なビルド状態が毀損されてしまう可能性があることです。
つまり、デフォルトでは「再現可能なビルドの実現性」を完全に信頼しきることはできず、心ならずも御自身のビルド・システムに全幅の信頼を置いていただくしかないのです。
配布時の脅威
Section titled “配布時の脅威”私たちは、アプリへの「ホット・アップデート」（再起動不要の更新）をできる限り簡単かつ安全に配信できるように最善を尽くしました。 ただし、マニフェスト・サーバー、ビルド・サーバー、あるいはバイナリ・ホスティング・サービス※の管理ができないと、すべてが台無しになります。
自分でシステムを構築する場合は、専門の「OPS アーキテクト※」に相談して適切に構築してください。
・ビルド・サーバー build server： ソースコードのコンパイルやテスト、実行ファイルへの結合といった一連の「ビルド作業」を自動処理で実行するための専用サーバー。
・バイナリ・ホスティング・サービス binary hosting service： コンパイル済みの完成品（バイナリ・ファイル）を安全かつ効率的に管理・保管・配信するための管理サーバー。
・マニフェスト・サーバー manifest server： アプリの起動・更新の際に必要なファイルの構成情報を格納したマニフェスト・ファイルを管理・配信するサーバー。
・OPS アーキテクト （OPS = operations）： システムの「運用・保守」のしやすさを設計する役割を担う部門・専門家。
もし、Tauri アプリの信頼できる配信サービスをお探しの場合、Tauri のパートナーである CrabNebula がクラウド・サービスを提供しています： https://crabnebula.dev/cloud
実行時の脅威
Section titled “実行時の脅威”私たちは WebView が安全ではないと考えています。つまり、信頼できないユーザーランド※のコンテンツを読み込むという状況に照らして、WebView からシステム API へのアクセスに関し、いくつかの保護対策を Tauri に実装しました。
・ユーザーランド （userland）： 「ユーザー空間」。Tauri のシステム構成は、ユーザー・インターフェース部である「フロントエンド／WebView」と、内部のデータ処理を行なう「バックエンド／Rust プログラム」の二つの領域からなっており、 「ユーザーランド」は、Tauri ではユーザーがアクセスする「フロントエンド／WebView」を指します。バックエンド部は堅牢な Rust 言語で記述されて安全性が担保されていますが、フロントエンド部はユーザーからの「外部」データに晒されるため、さまざまなセキュリティ対策が必要とされている訳です。
「コンテンツ・セキュリティ・ポリシー（CSP）」を使用することで、WebView が実行できる通信のタイプを制限します。 さらに、「セキュリティ・レベル」の設定により、信頼できないコンテンツやスクリプトが WebView 内の API にアクセスするのを防ぐことができます。
また、『セキュリティ 概要： 協調的な情報開示』の章に記載された「Tauri への情報提供」の仕組みと同様の、脆弱性を報告するための簡単で安全な方法を設定することもお勧めします。
【※ この日本語版は、「Sep 3, 2026 英語版」に基づいています】
© 2026 Tauri Contributors. CC-BY / MIT