※個人の感想です。製品マニュアルではありません。
ManaPDFで、気を配ってるセキュリティのこと
社内の PDF が、いつの間にか書き換わっている気がした。調べるために GitHub から OSS を入れたら、自分がセキュリティ担当なのに EDR のアラートが上がった。
きっかけは、そんな少しきまずい体験でした。ManaPDF は「便利な PDF ツール」を作る前に、説明できる配布と端末内完結を優先しています。ここでは、その背景を個人的な思いと、技術的な整理の両方で書きます。
※ 社内システムや特定ベンダーの批判ではありません。法的な保証や社内承認の代わりにもなりません。プライバシーポリシーと ヘルプ もあわせてどうぞ。
Part1. きっかけ — 「サイレントに変わった？」
業務で配布されている PDF を、しばらく見ないうちに開き直すと、なぜか中身やプロパティが以前と違う——そんな違和感がありました。ユーザーが意識して保存し直したわけではなさそうなのに、Creator や更新日時、埋め込まれたメタデータだけが変わっている。いわゆるサイレント更新（利用者の操作を伴わない差し替え）ではないか、と疑い始めました。
調べるために、メタデータの比較やレポート出力ができる PDF 関連の OSS を GitHub から取得し、社内 PC で動かしてみました。正規の調査目的です。悪意のある行為ではありません。
それでも、エンドポイント保護（EDR）のアラートが上がりました。
セキュリティを見る立場なのに、「何のツールですか？」と聞かれる側になった。正直、きまずかった。
アラートの中身は、だいたい次のような文脈でした。
- GitHub から取得した、あまり知名度のない実行ファイル
- コード署名が付いていない、または社内で未登録の署名
- PDF を開いて解析し、別ファイルに書き出す振る舞い
悪意がなくても、説明コストは発生します。「調査のためです」と言えば通ることもありますが、毎回そう説明したくはない。だから ManaPDF では、配布形態そのものを最初から設計に含めました。
Part2. PDF ツールは EDR に検知されやすい
これは ManaPDF だけの話ではありません。PDF を読み書きするアプリケーションは、エンドポイント保護製品からヒューリスティック（振る舞いベース）に検知されやすい類型です。仕様上、次のような処理を行うからです。
- バイナリ形式の PDF をパースし、内部オブジェクト（ストリーム、辞書、暗号化エンベロープ）を解釈する
- メタデータや本文テキストを抽出・書き換えし、新しいファイルとして保存する
- 暗号化 PDF ではパスワード解除や再保存を行う（Unlock）
- 添付・外部リンク・スクリプトなど、マルウェア分析でも注目される構造を触る
EDR から見ると、これは「文書を開いて改変する未知のアプリ」に見えます。正規の DTP ソフトでも誤検知は起こり得ますが、配布元が小さい・署名が弱い・利用実績がないほど、スコアは上がりやすいです。
配布形態も影響します。.NET アプリを自己完結型（single-file）で 1 つの exe にまとめて配布すると、起動時に一時ディレクトリへ展開する挙動が加わり、パッキングされた実行ファイルと類似した検知パターンに当たることがあります。ZIP から取り出した未署名の manapdf.exe をそのまま実行するのも、同様に説明が必要です。
「怪しい」のではなく、「警戒される設計になりやすい」——この言い方のほうが正確だと思っています。
クラウド型の PDF サービスは、アップロードの問題は残りますが、端末への未知 exe 導入は避けられます。ローカルツールはその逆です。ManaPDF はローカル完結を選んだぶん、署名と配布経路で説明責任を取る必要があると考えています。
Part3. 署名が必要だから、Store 配布を優先した
社内でソフトを説明するとき、いちばん聞かれるのは「どこから入れたの？」と「署名は？」です。Windows では、実行ファイルのコード署名（Authenticode）と、既知の配布チャネルかどうかが、承認のハードルに直結します。
個人サイトや GitHub Releases から unsigned / 自己署名の ZIP を配る方法もありますが、セキュリティ担当として自分が使うのですらアラートが上がる——Part1 の体験がそれです。組織のポリシーによっては、そもそも許可されません。
だから ManaPDF の一般向け公式入手先は Microsoft Storeにしました。
- Store 経由の MSIX は、Partner Center のパッケージ署名のもとで配布される
- 「Microsoft Store の ManaPDF」として説明しやすい（社内のソフトウェア申請でも書きやすい）
- GUI と CLI（
manapdfApp Execution Alias）を同じパッケージで届けられる
GitHub 上のソースは MIT ライセンスで公開していますが、一般ユーザー向けのバイナリ配布の主経路は Storeです。タグ付きリリースで Actions が作る CLI 用 ZIP / SBOM は、主にメンテナー自身の検証・追跡用（後述）で、Store とは別チャネルとして扱っています。
※ Store のインストール・更新・購入で Microsoft 側の通信が発生することは、ManaPDF 本体の PDF 処理とは別です。
Part4. ManaPDF が意識していること
配布形態とあわせて、アプリの振る舞い側でも線を引いています（GUI の Policy / manapdf policy と同じ方針です）。
- 通常動作で PDF を外部へアップロードしない — 処理は端末内。テレメトリ・アカウント・オンライン認証も入れない
- 入力ファイルを上書きしない — 結果は別名・別フォルダ。CLI で上書きするのは
--forceなど明示時のみ - PDF 処理のためのネットワーク通信を行わない
- 暗号化 PDF はパスワード入力後に処理 — パスワードはログや JSON に含めない
- 依存ライブラリをアプリ内で開示 — About の Licenses、CLI の
manapdf licenses、同梱の THIRD_PARTY_NOTICES
サイレント更新の調査がきっかけだったので、Compare や Report、メタデータの差分確認といった「いつ・何が変わったか」を見える化する機能にも力を入れています。ManaPDF が勝手に PDF を書き換えることはありませんが、他の経路で変わっていないかを確認する道具にはなれます。
メタデータの読み物で書いた「アップロードしたくない」「社内で説明したい」という話と、同じ根っこです。
Part5. ビルド・SBOM・GitHub Actions
「何をしているか」を文章だけでなく、ビルドの仕組みでも残したいと考えています。現状は次のとおりです。
継続的インテグレーション（CI）
main への push と pull request のたびに、GitHub Actions 上の Windows ランナーで dotnet restore → build → test を実行しています（.github/workflows/ci.yml）。Store に出す前の品質ゲートとして、手元ビルドだけに頼らないようにしています。
リリース時の SBOM とチェックサム
v* タグを push すると、別 workflow（.github/workflows/release.yml）が動きます。
- CLI（
manapdf.exe）を Release 構成で publish し、ZIP にパッケージング - CycloneDX 形式の SBOM（
manapdf-vX.Y.Z-sbom.cdx.json）をdotnet-CycloneDXで生成 - ZIP と SBOM の SHA-256 を
checksums.txtに記録（タグ名・コミット SHA・workflow run URL 付き） - GitHub Release に ZIP / SBOM / checksums を添付
- リポジトリが public のときは、GitHub Artifact Attestations（ビルド由来の証明）も付与
SBOM を一般ユーザー向けに常時公開しているわけではありません。 Store から入れた GUI パッケージに SBOM ファイルが同梱されているわけでもありません。いま公開しているのは、アプリ内のライセンス一覧と THIRD_PARTY_NOTICES、およびメンテナー向け GitHub Release 上の SBOM です。将来、Store 版向けにもっと明示的に出すかは検討中です。
それでも、「どのコミットから、どの workflow で、何が作られたか」は追跡できる状態にしておきたい。自分が EDR に引っかかったときと違い、後から説明できる材料を残すためです。
※ ソースは GitHub で公開しています。脆弱性は Security Advisories から（公開 issue ではなく）報告してください。
Part6. やらないこと・保証しないこと
ここは誤解されやすいので、はっきり書きます。
- マルウェア除去・PDF の無害化はしない — ウイルス対策ソフトではありません
inspectは安全判定ではない — 確認項目の一覧表示のみ（CLI のみ）- PDF/A・PDF/X の準拠証明はしない
- パスワードの解析・総当たりはしない
- EDR の誤検知をゼロにするとは言えない — 振る舞いの性質上、組織のポリシー次第でブロックされる可能性はあります
- 社内規程の判断は代行しない
「この PDF は安全です」とは言いません。「見なくていいデータを勝手に送らない」「入力を勝手に上書きしない」とは言えます。
気になったらどうぞ。
ManaPDF公式サイトを見る · ほかの読み物（メタデータの話） · ほかの読み物（Unlockの話） · プライバシーポリシー · Microsoft Storeで入手
補足. よくある質問（短め）
なぜ GitHub から入れた OSS でアラートが出るの？
署名がない・レピュテーションが低い・PDF の読み書きという振る舞い、などが重なると、EDR が「要確認」と判断しやすいからです。悪意があるとは限りません。
Store 版なら EDR に引っかからない？
保証はできません。ただし、コード署名付きの既知チャネル経由のほうが、社内説明とポリシー適合はしやすいことが多いです。
SBOM はどこで見られる？
一般向けの常設ダウンロードはしていません。タグ付き GitHub Release には CLI 向け CycloneDX SBOM を添付しています。アプリ内では manapdf licenses / About の Licenses で依存関係を確認できます。
本当にネットに PDF を送らないの？
通常の PDF 処理では、ManaPDF 本体が文書を外部サービスへアップロードしません。Store のインストール・更新など OS 側の通信は別です。
入力 PDF は上書きされる？
しません。結果は別ファイル・別フォルダです。