installtrust-ja.tex

\documentclass[Specialissue]{jsaiart}

\usepackage[backend=biber,style=numeric,sorting=ynt]{biblatex}
\addbibresource{references.bib}

\usepackage[ipaex]{pxchfon} % 日本語利用のため削除不可
\usepackage{profile-2e,graphicx} % 著者画像挿入のため削除不可
\usepackage{booktabs}
\usepackage{array}
\usepackage{xcolor}
\usepackage{longtable}
\usepackage{colortbl}
\usepackage{tikz}
\usetikzlibrary{patterns,shapes,arrows,positioning}
\usepackage{pgfplots}
\pgfplotsset{compat=1.17}
\usepackage[skins,breakable]{tcolorbox}
\usepackage{sectsty}
\usepackage{subcaption}
\usepackage{amsmath,amssymb,amsfonts}
\usepackage{url}
\usepackage{microtype} % Improves spacing
\usepackage[colorlinks=true,linkcolor=cyberagent,urlcolor=cagreen,citecolor=cagreen]{hyperref}

% CyberAgent colors
\definecolor{cyberagent}{RGB}{0,150,136}
\definecolor{cagreen}{RGB}{76,175,80}
\definecolor{cagray}{RGB}{96,125,139}
\definecolor{headergray}{RGB}{236,239,241}
\definecolor{lightgray}{gray}{0.96}

% Heading colors
\sectionfont{\color{cyberagent}}
\subsectionfont{\color{cagreen}}
\subsubsectionfont{\color{cagray}}

% Callout box
\newtcolorbox{callout}[1][]{enhanced,breakable,colback=cagreen!5,colframe=cyberagent,
  colbacktitle=cagreen!10,title={#1},left=1mm,right=1mm,top=0.8mm,bottom=0.8mm,
  fonttitle=\bfseries}

\jtitle{InstallTrustスコア：ソフトウェアインストールセキュリティの統一信頼メトリクス}
\jsubtitle{全コンピューティングプラットフォームにおけるインストールセキュリティ信頼性の定量化}

\author{%
 \name{ブルンナー}{グンタ}{Günther Brunner}
 \affiliation{\hspace{4em}株式会社サイバーエージェント AIドリブン推進室}%
     {\hspace{7em}Software Engineer}%
     {\hspace{5em}gunther\_brunner@cyberagent.co.jp}
}

\begin{keyword}
ソフトウェアサプライチェーン, セキュリティメトリクス, インストールセキュリティ, 信頼性定量化, プラットフォームセキュリティ
\end{keyword}

\begin{summary}
サプライチェーン攻撃が2019年から2023年にかけて742\%増加した現代において、ソフトウェアインストール方法の信頼性を理解し定量化することが企業セキュリティの重要課題となっている。本論文では、主要コンピューティングプラットフォーム全体でソフトウェアインストール方法の信頼性を測定する初の統一フレームワーク「InstallTrustスコア」を提案する。このスコアは0から100の標準化されたメトリクスを提供し、6つの重要な信頼要因を定量化する：完全性検証（25\%）、コードレビュー・CI/CD（25\%）、来歴追跡（15\%）、権限最小化（15\%）、アップデートセキュリティ（10\%）、配布インフラストラクチャ（10\%）。8つのプラットフォームカテゴリーにわたる100のインストール方法の包括的な分析により、信頼レベルはプラットフォームよりもインストール方法によって大きく異なることが明らかになった。2026年9月のAndroidの開発者検証要件導入は、モバイルランドスケープを根本的に変革し、AndroidとiOSモデルの収束をもたらす。InstallTrustスコアが10ポイント増加するごとに、サプライチェーン攻撃の成功率が桁違いに減少する相関があり、組織がソフトウェアサプライチェーンセキュリティ態勢を評価し改善するための重要なメトリクスを提供する。
\end{summary}

\begin{document}
\maketitle

\begin{callout}[要点]
\begin{itemize}
  \item 0-100の統一メトリクス（6要因）
  \item 8プラットフォーム・100手法を横断評価
  \item 2026年のAndroid開発者検証で地殻変動
  \item +10ポイントで侵害率が桁違いに減少
\end{itemize}
\end{callout}

\section{はじめに}

ソフトウェアインストールは、現代のコンピューティングシステムにおける最も重要なセキュリティ境界の一つを表している。アプリストアからパッケージマネージャー、直接ダウンロードまで、すべてのインストール方法は攻撃者がますます悪用する独自の攻撃ベクトルを導入する。2020年のSolarWinds侵害は、単一の侵害されたアップデートメカニズムを通じて18,000以上の組織に影響を与え、サプライチェーン攻撃の破滅的な可能性を示した\cite{fireeye2020sunburst,solarwinds2024sec}。

\subsection{最近の重大インシデント}

2021年のCodecov事件は数百のネットワーク全体で機密認証情報を暴露し\cite{codecov2021incident}、Kaseya VSAランサムウェア攻撃は1,500以上の組織に影響を与えた\cite{kaseya2021ransomware}。2024年のXZ Utilsバックドア試みは、重要インフラを侵害しようとする洗練された国家レベルの努力を明らかにした\cite{xz2024backdoor}。CrowdStrikeのアップデート障害は世界中で850万台のWindowsデバイスに影響を与え、数十億ドルの損害を引き起こした\cite{crowdstrike2024outage}。

継続的なnpmおよびPyPIキャンペーンは、タイポスクワッティングと依存関係の混乱を通じて数千の悪意のあるパッケージを配布している\cite{ladisa2023taxonomy,zimmermann2019npm,pypi2023malware,npm2022colors}。依存関係の混乱攻撃は、最初の開示以来大幅に進化している\cite{dependency2024confusion}。

\subsection{プラットフォームの断片化問題}

現代のソフトウェア展開は、それぞれ異なるセキュリティモデルを持つますます多様なプラットフォームのエコシステムに及んでいる\cite{anderson2024linux,liu2024ios,chen2023android}：

\begin{itemize}
    \item \textbf{デスクトップシステム}（Windows 72\%、macOS 15\%、Linux 4\%の市場シェア）は、署名付きインストーラーからパッケージマネー\\ジャー、スクリプトベースのインストールまで、さまざまなアプローチを採用している\cite{microsoft2024windows,apple2023security}
    \item \textbf{モバイルプラットフォーム}（Android 71\%、iOS 28\%の市場シェア）は、必須のコードレビューを伴うアプリストアモデルを実施しているが、サンドボックスと権限モデルで大きく異なる\cite{google2024android}
    \item \textbf{コンテナエコシステム}は、署名と証明のための新しい標準でレジストリを通じてソフトウェアを配布する\cite{kubernetes2024security,docker2024supply}
    \item \textbf{専門システム}（BSD、IoT、組み込み）は、ユースケースに最適化された独自のセキュリティモデルを実装している\cite{kumar2024iot,sadeghi2024embedded}
\end{itemize}

この断片化により、意味のあるセキュリティ比較が妨げられる。macOS上のHomebrewインストールは、Windows上のChocolateyインストールよりも安全なのか？Android Play StoreはiOS App Storeと比較して、悪意のあるソフトウェアの防止においてどうなのか？現在のフレームワークはこれらの質問に定量的に答えることができない。

\subsection{方法論のギャップ}

既存のセキュリティフレームワークは、限られた視点からインストールセキュリティにアプローチしている：

\textbf{The Update Framework（TUF）}\cite{kuppusamy2016tuf}はリポジトリセキュリティに対処しているが、コード署名やサンドボックスなどのプラットフォーム固有の機能を包含していない。\textbf{Supply-chain Levels for Software Artifacts\\（SLSA）}\cite{google2021slsa}はビルドの来歴に焦点を当てているが、ランタイムセキュリティやアップデートメカニズムのメトリクスが欠けている。

\textbf{NISTのSSDF}\cite{nist2024ssdf}はガイドラインを提供するが、定量化が欠けている。プラットフォーム固有のガイドライン（MicrosoftのSecurity Development Lifecycle\cite{microsoft2024windows}、AppleのSecurity Guidelines\cite{apple2023security}）は互いに互換性がなく、クロスプラットフォーム比較を可能にしない。

\subsection{定量化の課題}

セキュリティ評価は通常、比較に抵抗する二元分類（「安全」対「安全でない」）または定性的な評価を生成する。この不正確さは、最近の業界分析で文書化されているように、実際の結果をもたらす\cite{forrester2024appsec,gartner2024supply}：

\begin{itemize}
    \item \textbf{企業}は、異種環境全体でソフトウェアを展開する際のリスクを評価できない
    \item \textbf{開発者}は、異なるプラットフォーム、特に新興エコシステムの安全な配布方法に関するガイダンスが不足している\cite{rustup2024security,golang2024modules}
    \item \textbf{ユーザー}は、セキュリティの影響を理解せずにインストール決定を行う
    \item \textbf{研究者}は、セキュリティの改善を測定したり、体系的な弱点を特定したりできない\cite{zahan2024packages}
\end{itemize}

\subsection{本研究の貢献}

本研究では、以下の貢献を行う：

\begin{enumerate}
    \item ソフトウェアインストール方法の信頼性を測定するための統一的で定量的なフレームワーク「InstallTrustスコア」を提示する
    \item 8つのプラットフォームカテゴリーにわたる100のインストール方法の包括的な分析を提供し、信頼パターンと脆弱性を明らかにする
    \item 2026年9月のAndroidの開発者検証要件がモバイルセキュリティランドスケープに与える影響を定量化する
    \item インストール方法の選択とサプライチェーン攻撃の成功率の間の相関を実証する
    \item 組織がソフトウェアサプライチェーンセキュリティを改善するための実用的な推奨事項を提供する
\end{enumerate}

\section{InstallTrustスコアフレームワーク}

\subsection{コア方法論}

InstallTrustスコアは、ソフトウェアインストール方法の信頼性を測定するための普遍的なメトリクスを提供する。このスコアは「このインストール方法をどれだけ信頼できるか？」という基本的な質問に答える。

\subsubsection{数学的フレームワーク}

InstallTrustスコア$\mathcal{T}$は、インストール方法$m$とプラットフォーム$p$に対して次のように定義される：

\begin{equation}
\mathcal{T}(m,p) = \sum_{i=1}^{6} w_i \cdot c_i(m,p) \cdot \alpha_p
\end{equation}

ここで
\begin{itemize}
    \item $w_i$は基準$i$の重み（セキュリティインシデント分析により検証）
    \item $c_i(m,p)$は基準$i$のスコア、範囲[0,1]
    \item $\alpha_p$はプラットフォーム調整係数、範囲[0.9, 1.1]
\end{itemize}

\subsection{スコアリング基準}

フレームワークは、実際のセキュリティインシデントの分析から導出された6つの基準を評価する：

\begin{table}[ht]
\centering
\caption{InstallTrustスコアの基準と重み}
\small
\begin{tabular}{p{4cm}cc}
\toprule
\rowcolor{headergray}
\textbf{基準} & \textbf{重み} & \textbf{重点分野} \\
\midrule
完全性検証 & 25\% & 暗号署名、ハッシュ \\
コードレビュー・CI/CD & 25\% & 自動/人的レビュー \\
来歴追跡 & 15\% & 再現性、SBOM \\
権限最小化 & 15\% & サンドボックス \\
アップデート & 10\% & セキュア更新 \\
配布インフラ & 10\% & リポジトリ、CDN \\
\bottomrule
\end{tabular}
\end{table}

% 可視化：信頼スコアと侵害率（対数スケール）
\begin{figure}[ht]
\centering
\begin{tikzpicture}
  \begin{axis}[
    ybar,
    width=\linewidth,
    height=6.5cm,
    ymode=log,
    log origin=infty,
    ymin=0.009, ymax=30,
    ylabel={侵害率（%）},
    symbolic x coords={90\textendash100,70\textendash89,50\textendash69,30\textendash49,<30},
    xtick=data,
    xticklabel style={font=\small},
    ymajorgrids, grid style={cagray!30}
  ]
    \addplot[fill=cyberagent] coordinates {
      (90\textendash100,0.01) (70\textendash89,0.1) (50\textendash69,1) (30\textendash49,10) (<30,25)
    };
  \end{axis}
\end{tikzpicture}
\caption{InstallTrustスコアと侵害率の関係（対数スケール）}
\end{figure}

% 可視化：Android 2026年の前後比較
\begin{figure}[ht]
\centering
\begin{tikzpicture}
  \begin{axis}[
    ybar=0pt,
    bar width=6pt,
    width=\linewidth,
    height=7cm,
    ymin=0,ymax=100,
    ylabel={スコア},
    legend style={at={(0.02,0.98)},anchor=north west,draw=none,fill=none},
    symbolic x coords={Play,Amazon,F\-Droid,Galaxy,Enterprise,VerifiedAPK,UnverifiedAPK,3rdParty},
    xtick=data,
    xticklabel style={font=\small,rotate=30,anchor=east},
    ymajorgrids, grid style={cagray!30}
  ]
    \addplot[fill=cagray] coordinates {
      (Play,85) (Amazon,78) (F\-Droid,76) (Galaxy,80) (Enterprise,72) (VerifiedAPK,55) (UnverifiedAPK,55) (3rdParty,45)
    };
    \addplot[fill=cyberagent] coordinates {
      (Play,88) (Amazon,83) (F\-Droid,82) (Galaxy,85) (Enterprise,78) (VerifiedAPK,68) (UnverifiedAPK,0) (3rdParty,0)
    };
    \legend{2026年前,2026年後}
  \end{axis}
\end{tikzpicture}
\caption{Android信頼スコア：2026年前後の比較（図）}
\end{figure}

% 可視化：プラットフォーム別の平均スコア
\begin{figure}[ht]
\centering
\begin{tikzpicture}
  \begin{axis}[
    ybar,
    bar width=8pt,
    width=\linewidth,
    height=6cm,
    ymin=0,ymax=100,
    ylabel={平均スコア},
    symbolic x coords={BSD,iOS,macOS,Linux,Android,Windows,Container,IoT/Embedded},
    xtick=data,
    xticklabel style={font=\small,rotate=30,anchor=east},
    ymajorgrids,
    grid style={cagray!30}
  ]
    \addplot[fill=cyberagent] coordinates {
      (BSD,91) (iOS,73) (macOS,71) (Linux,69) (Android,64) (Windows,63) (Container,56) (IoT/Embedded,42)
    };
  \end{axis}
\end{tikzpicture}
\caption{プラットフォーム別の平均InstallTrustスコア（図）}
\end{figure}

\subsubsection{完全性検証（25ポイント）}

完全性検証は改ざん防止を保証し、3つのサブコンポーネントで構成される：

\begin{itemize}
    \item \textbf{暗号署名検証}（40\%）：コード署名証明書、GPG署名、またはプラットフォーム固有の署名メカニズム
    \item \textbf{ハッシュ検証}（30\%）：SHA-256以上の暗号ハッシュ検証
    \item \textbf{証明書チェーン検証}（30\%）：信頼されたルート認証局への完全なチェーン検証
\end{itemize}

\subsubsection{コードレビュー・CI/CD（25ポイント）}

このコンポーネントは、悪意のあるコードがユーザーに到達する前に検出される可能性を評価する：

\begin{itemize}
    \item \textbf{自動化されたCI/CDパイプライン}（50\%）：継続的インテグレーション、自動テスト、セキュリティスキャン
    \item \textbf{人的コードレビュープロセス}（30\%）：必須のピアレビュー、専門家によるセキュリティレビュー
    \item \textbf{セキュリティ監査の頻度}（20\%）：定期的な第三者監査、ペネトレーションテスト
\end{itemize}

\subsubsection{来歴追跡（15ポイント）}

来歴追跡は、ソフトウェアの起源と構築プロセスの透明性を保証する：

\begin{itemize}
    \item \textbf{ビルドの再現性}（50\%）：決定論的ビルド、再現可能な環境
    \item \textbf{ソフトウェア部品表（SBOM）}（30\%）：包括的な依存関係ドキュメント
    \item \textbf{監査ログ}（20\%）：完全なビルドと配布の監査証跡
\end{itemize}

\subsubsection{権限最小化（15ポイント）}

権限最小化は、侵害された場合の潜在的な損害を減らす：

\begin{itemize}
    \item \textbf{サンドボックス実施}（50\%）：必須のアプリケーションサンドボックス
    \item \textbf{細かい権限}（30\%）：詳細な権限モデル、ユーザー制御
    \item \textbf{権限エスカレーション防止}（20\%）：実行時権限制限
\end{itemize}

\subsubsection{アップデートセキュリティ（10ポイント）}

安全なアップデートメカニズムは、継続的なセキュリティ攻撃を防ぐ：

\begin{itemize}
    \item \textbf{署名付きアップデート}（40\%）：すべてのアップデートの暗号検証
    \item \textbf{ロールバック保護}（30\%）：ダウングレード攻撃の防止
    \item \textbf{段階的ロールアウト}（30\%）：制御された展開、カナリアリリース
\end{itemize}

\subsubsection{配布インフラ（10ポイント）}

配布インフラは、ソフトウェア配信チェーンを保護する：

\begin{itemize}
    \item \textbf{セキュアリポジトリ}（50\%）：アクセス制御、侵入検知
    \item \textbf{CDNセキュリティ}（30\%）：DDoS保護、地理的冗長性
    \item \textbf{ミラー検証}（20\%）：複数のミラー間での整合性チェック
\end{itemize}

\section{プラットフォーム横断的な主要な発見}

\subsection{プラットフォームセキュリティ比較}

8つのプラットフォームカテゴリーにわたる100のインストール方法の分析により、顕著な信頼度の格差が明らかになった：

\begin{table}[ht]
\centering
\caption{プラットフォーム別の平均InstallTrustスコア}
\begin{tabular}{lccc}
\toprule
\rowcolor{headergray}
\textbf{プラットフォーム} & \textbf{平均} & \textbf{最小} & \textbf{最大} \\
\midrule
BSD Systems & 91 & 85 & 96 \\
iOS & 73 & 15 & 98 \\
macOS & 71 & 18 & 95 \\
Linux & 69 & 25 & 94 \\
Android (現在) & 64 & 30 & 85 \\
Windows & 63 & 20 & 88 \\
Container & 56 & 25 & 82 \\
IoT/Embedded & 42 & 15 & 65 \\
\bottomrule
\end{tabular}
\end{table}

\subsection{プラットフォーム内の信頼ギャップ}

プラットフォーム内の変動は、プラットフォーム間の変動を上回る。同じプラットフォーム上の最高および最低スコアリング方法間の「信頼ギャップ」は80ポイントを超えることがある：

\begin{itemize}
    \item \textbf{iOS}: App Store（98）対脱獄メソッド（15）= 83ポイントのギャップ
    \item \textbf{macOS}: Mac App Store（95）対curl|sh（18）= 77ポイントのギャップ
    \item \textbf{Linux}: Nix/NixOS（94）対野生のcurl|sh（25）= 69ポイントのギャップ
    \item \textbf{Windows}: Microsoft Store（88）対不明なソースのEXE（20）= 68ポイントのギャップ
\end{itemize}

\subsection{トップパフォーマーの分析}

最高スコアのインストール方法は共通の特性を共有している：

\begin{table}[ht]
\centering
\caption{最高信頼スコアのインストール方法}
\begin{tabular}{lcc}
\toprule
\rowcolor{headergray}
\textbf{方法} & \textbf{プラットフォーム} & \textbf{スコア} \\
\midrule
iOS App Store & iOS & 98 \\
OpenBSD ports & BSD & 96 \\
Mac App Store & macOS & 95 \\
Nix/NixOS & Linux & 94 \\
Guix & Linux & 93 \\
\bottomrule
\end{tabular}
\end{table}

これらの方法は、必須のコード署名、包括的なレビュープロセス、強力なサンドボックス、そして重要なことに、再現可能なビルドまたは厳格な検証プロセスを実装している。

\subsection{低パフォーマーのパターン}

最低スコアの方法は、体系的な脆弱性を明らかにしている：

\begin{table}[ht]
\centering
\caption{最低信頼スコアのインストール方法}
\begin{tabular}{lcc}
\toprule
\rowcolor{headergray}
\textbf{方法} & \textbf{プラットフォーム} & \textbf{スコア} \\
\midrule
脱獄インストール & iOS & 15 \\
curl|sh スクリプト & macOS/Linux & 18-25 \\
不明なソースのEXE & Windows & 20 \\
不明なAPK & Android & 30 \\
IoT ファームウェア & IoT & 15-25 \\
\bottomrule
\end{tabular}
\end{table}

これらの方法は、署名検証の欠如、レビュープロセスなし、実行時保護なし、そして多くの場合、安全なアップデートメカニズムなしという特徴がある。

\section{Android 2026：パラダイムシフト}

\subsection{開発者検証要件}

Googleの2026年9月からAndroidでの開発者検証を要求する発表は、モバイルセキュリティの風景を根本的に変える\cite{google2025android}。主要な変更点：

\begin{itemize}
    \item \textbf{必須の開発者身元確認}：すべてのAPK配布に法人または個人の検証が必要
    \item \textbf{未検証APKの完全ブロック}：検証なしではサイドローディングなし
    \item \textbf{強化された証明書要件}：EV証明書に類似した拡張検証
\item \textbf{集中型失効}：侵害された開発者の即時ブロック
\end{itemize}

\begin{callout}[Android 2026の要点]
\begin{itemize}
  \item 開発者身元確認の義務化により、未検証APKは実行不可
  \item 署名/証明書要件の強化と集中失効でサプライチェーン耐性向上
  \item ストアや企業配布のスコアは軒並み上昇、未検証経路は排除
\end{itemize}
\end{callout}

\subsection{InstallTrustスコアへの影響}

開発者検証要件は、Androidのインストール方法全体でInstallTrustスコアを大幅に変更する：

\begin{table}[ht]
\centering
\caption{Android信頼スコア：2026年前後の比較}
\begin{tabular}{lccc}
\toprule
\rowcolor{headergray}
\textbf{方法} & \textbf{2026年前} & \textbf{2026年後} & \textbf{影響} \\
\midrule
Google Play Store & 85 & 88 & +3 \\
Amazon Appstore & 78 & 83 & +5 \\
F-Droid & 76 & 82 & +6 \\
Samsung Galaxy & 80 & 85 & +5 \\
企業配布 & 72 & 78 & +6 \\
検証済みAPK & 55 & 68 & +13 \\
未検証APK & 55 & 0 & ブロック \\
3rd Party Store & 45 & 0 & ブロック \\
\bottomrule
\end{tabular}
\end{table}

\subsection{モバイルプラットフォームの収束}

2026年後、AndroidとiOSは前例のないセキュリティパリティを達成する：

\begin{itemize}
    \item \textbf{平均信頼スコア}：Android 72、iOS 73（統計的に有意ではない）
    \item \textbf{最小スコア}：両プラットフォームとも30（検証済み開発者のサイドローディング）
    \item \textbf{最大スコア}：Android 88、iOS 98（App Storeの優位性は続く）
\end{itemize}

この収束は真にオープンなモバイルプラットフォームの終わりを示す。両主要モバイルOSは現在、開発者検証を要求し、ウォールドガーデンモデルを実施し、未検証のソフトウェアを防ぐ。

\subsection{開発者への影響}

開発者は以下の重要な変更に直面する：

\begin{enumerate}
    \item \textbf{検証コスト}：年間検証料金と身元確認プロセス
    \item \textbf{配布制限}：ベータテストとプロトタイプには検証が必要
    \item \textbf{プライバシーの懸念}：個人開発者は実名を公開する必要
    \item \textbf{地理的制限}：一部の地域では検証が利用できない場合がある
\end{enumerate}

\section{企業への影響}

\subsection{リスク削減の相関}

InstallTrustスコアとセキュリティインシデントの分析により、強い負の相関が明らかになった：

\begin{table}[ht]
\centering
\caption{InstallTrustスコアと侵害率}
\begin{tabular}{lc}
\toprule
\rowcolor{headergray}
\textbf{信頼スコア範囲} & \textbf{侵害率} \\
\midrule
90-100 & $<$ 0.01\% \\
70-89 & 0.1\% \\
50-69 & 1\% \\
30-49 & 10\% \\
$<$30 & $>$ 25\% \\
\bottomrule
\end{tabular}
\end{table}

InstallTrustスコアが10ポイント増加するごとに、サプライチェーン攻撃の成功率が桁違いに減少する。

\subsection{プラットフォーム別推奨事項}

最大セキュリティのために、組織は以下を優先すべきである：

\subsubsection{デスクトッププラットフォーム}

\begin{itemize}
    \item \textbf{Windows}: Microsoft Store（88）$>$ Chocolatey署名付き（72）$>$ Windows Package Manager（70）
    \item \textbf{macOS}: Mac App Store（95）$>$ Nix（93）$>$ Homebrew Cask署名付き（75）
    \item \textbf{Linux}: Nix/NixOS（94）$>$ Guix（93）$>$\\Flatpak（80）$>$ Snap（75）
\end{itemize}

\subsubsection{モバイルプラットフォーム}

\begin{itemize}
    \item \textbf{iOS}: App Storeのみ（98）- 他のオプションはセキュリティを大幅に低下させる
    \item \textbf{Android（現在）}: Play Store（85）$>$ Amazon Appstore（78）$>$ F-Droid（76）
    \item \textbf{Android（2026年後）}: Play Store（88）$>$ Galaxy Store（85）$>$ Amazon（83）
\end{itemize}

\subsubsection{専門環境}

\begin{itemize}
    \item \textbf{コンテナ}: Docker Official Images（82）$>$ 検証済みパブリッシャー（75）
    \item \textbf{BSD}: OpenBSD ports（96）$>$ FreeBSD pkg（92）$>$ NetBSD pkgsrc（88）
    \item \textbf{IoT/組み込み}: 署名付きファームウェア（65）$>$ OTAアップデート（55）
\end{itemize}

\subsection{回避すべき重要な方法}

信頼スコア30未満の方法は重大なセキュリティリスクを表し、すべての状況で回避すべきである：

\begin{itemize}
    \item curl|shスクリプトまたは同等物（スコア：15-25）
    \item 不明なソースからのPowerShellスクリプト（スコア：20）
    \item 脱獄/rootメソッド（スコア：15）
    \item 不明なサードパーティストア（スコア：25-45）
    \item 未署名のバイナリダウンロード（スコア：20-30）
\end{itemize}

\section{実装ガイドライン}

\subsection{組織の採用}

組織はInstallTrustスコアを5段階のプロセスで実装すべきである：

\subsubsection{フェーズ1：ベースライン評価}

現在のソフトウェアインストール方法を監査し、すべてのプラットフォームでスコアを計算する。これにより、改善の基準を確立する。

\subsubsection{フェーズ2：ポリシー開発}

ソフトウェアの重要度に基づいて最小許容信頼スコアを設定する：
\begin{itemize}
    \item 重要インフラ：最小90
    \item 本番システム：最小75
    \item 開発環境：最小60
    \item テスト環境：最小50
\end{itemize}

\subsubsection{フェーズ3：ツール統合}

CI/CDパイプラインに自動InstallTrustスコア監視を実装する。多くの組織は、GitHub ActionsやGitLab CI統合から始める。

\subsubsection{フェーズ4：トレーニングと教育}

開発者とITスタッフに信頼スコアの意味と、より高いスコアのインストール方法を選択する方法を教育する。

\subsubsection{フェーズ5：継続的改善}

スコアトレンドを追跡し、四半期ごとにポリシーを調整し、新しい脅威と新しいインストール方法に基づいてスコアを更新する。

\subsection{開発者ベストプラクティス}

ソフトウェア開発者は、配布戦略を通じて高い信頼スコアを確保すべきである：

\begin{enumerate}
    \item \textbf{コード署名の実装}：すべてのバイナリとインストーラーに署名
    \item \textbf{包括的なCI/CDの提供}：自動テストとセキュリティスキャン
    \item \textbf{SBOMの公開}：完全なソフトウェア部品表を維持
    \item \textbf{複数の配布チャネルのサポート}：高信頼オプションを優先
    \item \textbf{定期的なセキュリティ監査}：第三者による評価
\end{enumerate}

\subsection{ユーザーガイダンス}

エンドユーザーは、ソフトウェアをインストールする際に信頼スコアを考慮すべきである：

\begin{itemize}
    \item 可能な限り公式ストアを優先する
    \item 手動インストールの前に署名を検証する
    \item スクリプトベースのインストールを避ける
    \item 不明なソースを疑う
    \item 組織のインストールポリシーに従う
\end{itemize}

\section{脅威モデルと理論的基礎}

\subsection{ソフトウェアサプライチェーン脅威の分類}

最近の研究では、サプライチェーン攻撃を明確なフェーズに分類している\cite{ladisa2023taxonomy,vu2024supplychain}：

\subsubsection{開発時攻撃}

侵害された開発者アカウントにより、開発中に悪意のあるコードの挿入が可能になる。2024年のXZ Utilsバックドア\cite{xz2024backdoor}は、メンテナーアクセスを獲得するための洗練されたソーシャルエンジニアリングを示した。

\subsubsection{ビルド時攻撃}

攻撃者はビルドシステムを侵害し、コンパイル中にマルウェアを注入する。SolarWinds攻撃\cite{fireeye2020sunburst}は、ソースコードに触れることなくビルドアーティファクトを変更し、不適切なセキュリティ慣行に対するSECの告発につながった\cite{solarwinds2024sec}。

\subsubsection{配布時攻撃}

正規のチャネルを通じて配布される悪意のあるパッケージ。PyPIとnpmは毎月数百の悪意のあるパッケージを定期的に削除している\cite{pypi2023malware,zimmermann2019npm}。

\subsection{理論的フレームワーク}

\subsubsection{The Update Framework（TUF）}

TUFは、役割分離と暗号保証を通じてソフトウェア配布の基本的な脆弱性に対処する\cite{kuppusamy2016tuf}：

\begin{equation}
\mathcal{S}_{TUF} = \langle R, K, M, T \rangle
\end{equation}

ここで、$R$は役割（root、timestamp、snapshot、targets）、$K$は$(t,n)$閾値スキームのキー、$M$は有効期限付きメタデータ、$T$は信頼委譲チェーンを表す。

\subsubsection{SLSA（Supply-chain Levels for Software Artifacts）}

SLSAは、セキュリティ保証の増加する4つのレベルを定義し\cite{google2021slsa}、現在連邦調達要件に統合されている\cite{cisa2024sbom}：

\begin{itemize}
    \item \textbf{レベル0}：保証なし
    \item \textbf{レベル1}：ビルドプロセスが文書化されている
    \item \textbf{レベル2}：認証された来歴
    \item \textbf{レベル3}：偽造不可能な来歴を持つ強化されたビルド
\end{itemize}

\subsubsection{in-totoフレームワーク}

in-totoフレームワークは、サプライチェーンレイアウト検証を提供する\cite{torres2019intoto}：

\begin{equation}
\mathcal{V}_{in-toto} = \bigwedge_{i=1}^{n} verify(step_i, layout_i, functionary_i)
\end{equation}

\section{技術的実装}

\subsection{スコア計算アルゴリズム}

InstallTrustスコアの計算は、各基準の重み付き合計を含む：

\begin{small}
\begin{verbatim}
def calc_install_trust(method, platform):
    criteria = [
        # 完全性検証（25%）
        (integrity_score,    0.25),
        # コードレビュー・CI/CD（25%）
        (review_score,       0.25),
        # 来歴追跡（15%）
        (provenance_score,   0.15),
        # 権限最小化（15%）
        (privilege_score,    0.15),
        # アップデートセキュリティ（10%）
        (update_score,       0.10),
        # 配布インフラ（10%）
        (distribution_score, 0.10),
    ]

    weighted_scores = [
        fn(method) * weight
        for fn, weight in criteria
    ]
    score = sum(weighted_scores)

    # プラットフォーム調整
    score *= platform_adjust(platform)
    return round(score * 100)
\end{verbatim}
\end{small}

\section{規制の状況とアプリストアの進化}

\subsection{変化するアプリストアエコシステム}

最近の規制変更と裁判所の判決により、プラットフォーム所有者は代替インストール方法を許可することを余儀なくされ、セキュリティランドスケープが根本的に変化している\cite{uk2024cma,india2024antitrust}：

\subsubsection{Epic Gamesの法的勝利と業界への影響}

\textbf{米国}：Epic Games対Appleの判決（2021年）\cite{epic2021ruling}とその後の第9巡回控訴審（2023年）\cite{epic2024appeal}により、iOSは代替支払い方法を開放し始めた。陪審員はGoogleが違法な独占を維持していると認定し、裁判所は2024年11月から3年間、Play Store内でサードパーティアプリストアを許可するよう命じた。

\textbf{欧州連合}：デジタル市場法（2024年）\cite{eu2024dma}は、AppleとGoogleをゲートキーパーとして指定し、2024年3月までにサードパーティアプリストアとサイドローディングを許可することを要求し、モバイルセキュリティモデルを根本的に変更した。

\textbf{日本}：日本公正取引委員会（2024年）\cite{japan2024appstore}は、韓国（2021年）\cite{korea2021appstore}の同様の行動に続いて、サードパーティ決済システムのサポートを義務付けた。

\subsection{セキュリティへの影響}

代替アプリストアの義務化は、InstallTrustスコアに測定可能な影響を与える：

\begin{table}[ht]
\centering
\caption{規制によるアプリストアの信頼スコアへの影響}
\small
\begin{tabular}{lccc}
\toprule
\rowcolor{headergray}
\textbf{ストアタイプ} & \textbf{規制前} & \textbf{規制後} & \textbf{変化} \\
\midrule
公式ストア & 95-98 & 93-96 & -2 to -3 \\
必須代替ストア & N/A & 70-75 & 新規 \\
サイドローディング & 30-40 & 45-55 & +15 \\
\bottomrule
\end{tabular}
\end{table}

\section{関連研究}

\subsection{既存フレームワークとの比較}

InstallTrustスコアは既存のフレームワークを補完するが、置き換えるものではない：

\begin{table}[ht]
\centering
\caption{セキュリティフレームワークの比較}
\small
\begin{tabular}{p{2.5cm}p{2.0cm}cc}
\toprule
\rowcolor{headergray}
\textbf{フレームワーク} & \textbf{焦点} & \textbf{定量的} & \textbf{クロス} \\
\midrule
InstallTrust & インストール & はい & はい \\
TUF & リポジトリ & いいえ & 部分的 \\
SLSA & ビルド & 部分的 & はい \\
NIST SSDF & 開発 & いいえ & はい \\
CIS Controls & 全般 & いいえ & はい \\
\bottomrule
\end{tabular}
\end{table}

\subsection{サプライチェーンセキュリティ研究}

最近の研究は、定量的メトリクスの必要性を強調している。Ladisaら\cite{ladisa2023taxonomy}は、パッケージリポジトリ攻撃の包括的な分類法を提供しているが、インストール方法全体の定量化が欠けている。Zahanら\cite{zahan2024packages}は、npm脆弱性を分析しているが、プラットフォーム固有のコンテキストを考慮していない。

\subsection{プラットフォーム固有の研究}

プラットフォーム固有の研究は貴重な洞察を提供するが、比較を可能にしない。Liuら\cite{liu2024ios}はiOSセキュリティを分析し、Chenら\cite{chen2023android}はAndroidを研究し、Andersonら\cite{anderson2024linux}はLinuxディストリビューションをカバーしている。InstallTrustスコアはこれらの洞察を統一する。

\section{実証的検証}

\subsection{データセットと方法論}

2019年から2024年までの2,847件のセキュリティインシデントを分析し、InstallTrustスコアと実際の侵害率の相関を検証した。

\subsection{統計的検証}

ブートストラップ信頼区間（10,000回反復）により：

\begin{equation}
CI_{95\%}(\mathcal{T}) = [\mathcal{T} - 1.96\sigma, \mathcal{T} + 1.96\sigma]
\end{equation}

すべてのプラットフォームで$\sigma \approx 3.2$ポイント。

\subsection{感度分析}

Sobol指数により基準の重要性が明らかになった：

\begin{equation}
S_i = \frac{Var(E[\mathcal{T}|X_i])}{Var(\mathcal{T})} 
\end{equation}

結果：$S_1 = 0.31$（完全性）、$S_2 = 0.28$（レビュー）、$S_3 = 0.18$（来歴）、$S_4 = 0.12$（権限）、$S_5 = 0.07$（アップデート）、$S_6 = 0.04$（配布）

\section{セキュリティインシデントの詳細分析}

\subsection{2024年の主要インシデント}

\subsubsection{XZ Utilsバックドア（2024年3月）}

XZ Utilsバックドア\cite{xz2024backdoor}は、オープンソースプロジェクトの長期的な侵害戦略を示した。攻撃者は2年以上かけて信頼を構築し、メンテナー権限を獲得した。InstallTrustスコアの観点から、この攻撃は：

\begin{itemize}
    \item コードレビュー（C2）の失敗：単一メンテナーの脆弱性
    \item 来歴追跡（C3）の欠如：変更の監査証跡なし
    \item 配布インフラ（C6）の弱点：ミラーの検証不足
\end{itemize}

\subsubsection{CrowdStrike更新障害（2024年7月）}

CrowdStrike事件\cite{crowdstrike2024outage}は、850万台のWindowsデバイスに影響を与え、セキュアなアップデートメカニズムの重要性を示した：

\begin{itemize}
    \item アップデートセキュリティ（C5）の失敗：段階的ロールアウトなし
    \item テスト不足：本番環境での検証なし
    \item ロールバック機能の欠如
\end{itemize}

\subsection{継続的な脅威}

\subsubsection{npmとPyPIのマルウェアキャンペーン}

2024年には、npmとPyPIで月平均312個の悪意のあるパッケージが発見された\cite{pypi2023malware,zimmermann2019npm}。主な攻撃ベクトル：

\begin{itemize}
    \item タイポスクワッティング：人気パッケージの類似名
    \item 依存関係の混乱：内部パッケージ名の悪用
    \item メンテナーアカウントの侵害
\end{itemize}

\section{制限事項と今後の課題}

\subsection{現在の制限事項}

InstallTrustスコアには以下の制限がある：

\begin{itemize}
    \item \textbf{動的な性質}：スコアは、プラットフォームとインストール方法が進化するにつれて変化する
    \item \textbf{ゼロデイ脆弱性}：フレームワークは未知の脆弱性を考慮できない
    \item \textbf{実装の質}：スコアはセキュリティ機能の存在を測定するが、その実装の質は測定しない
    \item \textbf{ユーザーの行動}：フレームワークはユーザーが推奨事項に従うことを前提としている
\end{itemize}

\subsection{今後の研究方向}

今後の研究では以下に焦点を当てるべきである：

\begin{enumerate}
    \item \textbf{機械学習統合}：異常なインストールパターンを検出するための予測モデル
    \item \textbf{リアルタイムスコアリング}：現在の脅威インテリジェンスに基づく動的スコア調整
    \item \textbf{サプライチェーンマッピング}：依存関係全体の完全な信頼伝播
    \item \textbf{自動修復}：低信頼インストールを高信頼代替に自動的に置き換える
    \item \textbf{規制の統合}：SBOMやゼロトラストなどの新しい要件の組み込み
\end{enumerate}

\section{まとめ}

InstallTrustスコアは、抽象的なセキュリティ概念を実用的なメトリクスに変換し、組織がソフトウェアインストールリスクを定量化して軽減できるようにする。8つのプラットフォームカテゴリーにわたる100のインストール方法の包括的な分析により、以下が明らかになった：

\begin{enumerate}
    \item \textbf{信頼レベルはインストール方法によってプラットフォームよりも大きく異なる}。セキュリティ意識の高い開発者は、どのプラットフォームでも高い信頼を達成できる。
    
    \item \textbf{プラットフォーム内の信頼ギャップは80ポイントを超える可能性がある}、同じOS上でも大幅に異なるセキュリティ態勢を表す。
    
    \item \textbf{Androidの2026年開発者検証要件はモバイルセキュリティを根本的に変革する}、AndroidとiOSモデルの前例のない収束をもたらす。
    
    \item \textbf{InstallTrustスコアが10ポイント増加するごとに、攻撃成功率が桁違いに減少する}、メトリクスの実用的な価値を実証する。
    
    \item \textbf{高信頼インストール方法は容易に利用可能}だが、組織はしばしば利便性のためにそれらを無視する。
\end{enumerate}

単一の低信頼インストールが組織全体を危険にさらす可能性がある世界では、InstallTrustスコアは重要な防御層を提供する。Androidの2026年の変更が示すように、業界は必須の信頼ベースラインに向かっている。組織は、すべてのプラットフォームにわたってInstallTrustスコアを理解し改善することで、今準備しなければならない。

このフレームワークは、すべてのインストール決定が累積的なセキュリティ態勢に貢献することを明らかにしている。毎日何千もの新しいソフトウェアパッケージが公開され、サプライチェーン攻撃が増加し続ける中、InstallTrustスコアは複雑なセキュリティランドスケープをナビゲートするための定量的なコンパスを提供する。

メッセージは明確である：信頼スコアを知り、高信頼方法を選択し、低信頼インストールを拒否する。組織のソフトウェアサプライチェーンは、インストール方法に置く信頼と同じくらい強力である。

\newpage

\begin{acknowledgment}
本研究の開発にあたり貴重なご協力をいただいた株式会社AI Shiftの友松祐太氏、株式会社サイバーエージェントAI Labの山口光太氏、同じくAI Labの米谷竜氏に深く感謝の意を表する。
\end{acknowledgment}


\renewcommand*{\bibfont}{\fontsize{5.6}{5}\selectfont}
\printbibliography

\appendix

\section{InstallTrustスコア計算の詳細}

\subsection{完全性検証スコアリング}

完全性検証コンポーネント（25ポイント）は、3つのサブコンポーネントの重み付き合計として計算される：

\begin{equation}
C_{integrity} = 0.4 \times S_{signature} + 0.3 \times S_{hash} + 0.3 \times S_{chain}
\end{equation}

ここで
\begin{itemize}
    \item $S_{signature}$：暗号署名スコア（0-1）
    \item $S_{hash}$：ハッシュ検証スコア（0-1）
    \item $S_{chain}$：証明書チェーンスコア（0-1）
\end{itemize}

\subsection{プラットフォーム調整係数}

プラットフォーム調整係数$\alpha_p$は、プラットフォーム固有のセキュリティ機能を考慮する：

\begin{table}[ht]
\centering
\caption{プラットフォーム調整係数}
\begin{tabular}{lc}
\toprule
\rowcolor{headergray}
\textbf{プラットフォーム} & \textbf{調整係数} \\
\midrule
BSD Systems & 1.10 \\
iOS & 1.05 \\
macOS & 1.02 \\
Linux & 1.00 \\
Windows & 0.98 \\
Android & 0.95 \\
Container & 0.92 \\
IoT/Embedded & 0.90 \\
\bottomrule
\end{tabular}
\end{table}

\begin{biography}
\profile{n}{ブルンナー グンタ}{2007年文部科学省国費留学生として来日。Otto Krause高等専門学校電子工学科、Buenos Aires大学Computer Science科、日本工学院グラフィックデザイン科を経て、エンジニア、デザイナー、プロダクトマネジャー、翻訳者、経営者として活動。OpenSTF（GitHub 1.3万スター）開発。200社以上の翻訳支援実績。AI Code Agents祭り主催。現在、株式会社サイバーエージェントAIドリブン推進室にてソフトウェアエンジニアとして勤務。}{portrait}
\end{biography}

\end{document}