# Trend Microがこのブログを「Disease Vector」と誤判定 — URLを特定して再分類したら解決した > Trend MicroのSite Safety Centerが、このブログのService Workerを「Disease Vector」と評価しました。他5つのサービスで確認し、該当URLを再分類して解決しました。 - Source: https://oharu121.com/ja/blog/trend-micro-disease-vector-service-worker-false-positive/ - Published: 2026-09-21T03:00:32+09:00 - Tags: セキュリティ, Service Worker --- ## はじめに 普段からTrend Microを使っているのですが、あるとき自分のブログが検索結果でグレー 表示になっているのに気づきました。いつもの安全バッジではなく、そっけない「？」 マークが付いていたのです。 *Image: oharu tech blogのGoogle検索結果2件。それぞれのリスティングに、緑のチェックマークではなく灰色の丸い「？」バッジが表示されている* 緑のチェックマークが欲しかったので、[Trend MicroのSite Safety Center](https://global.sitesafety.trendmicro.com/)にドメインの再分類を申請しました。ところが返ってきた 結果は、以前よりも悪くなっていました。評価は「Dangerous」、コンテンツタイプは 「**Disease Vector**」です。 *Image: Trend MicroのSite Safety Centerからのメール。oharu121.comの再分類結果を示しており、新しい安全性評価はDangerous、新しいコンテンツタイプはDisease Vectorとなっている* > **あちゃー** > > **メールだけの話では済みませんでした。** Google検索にこのブログが出てくると、どの > リスティングにも赤い「×」バッジが付くようになったのです。しかもそれが見えるのは > ダッシュボードを覗く私だけではなく、Trend Microのブラウザ拡張機能を入れている > 訪問者全員でした。 *Image: oharu tech blogのGoogle検索結果2件。どちらも赤くハイライトされ、緑のチェックマークや灰色の「？」の代わりに赤い×アイコンが表示されている* 本記事では、その後に行った調査と、評価を最終的に「Safe」に変えた一つの変更について解説 します。 ## テスト結果：91ベンダー中0件が悪意ありと判定 何よりもまず、サイトが本当に侵害されているのかを確かめたいと思いました。そこで `https://oharu121.com/`を、一度のチェックで91のセキュリティベンダーに照会して くれるVirusTotalにかけてみました。結果は全ベンダーがクリーンで、フラグを立てたものは **91件中0件**でした。 *Image: oharu121.comのVirusTotalレポート。コミュニティスコアは91件中0件で、掲載されているセキュリティベンダーはすべて「Clean」と表示されている* これで一つの疑問は解消しましたが、代わりにもっと厄介な疑問が残りました。なぜ Trend Microだけが、他と違う判定をしているのか。 ## Google、Trellix、McAfee、Microsoftそれぞれで確認する VirusTotalの91ベンダーは、いずれもマルウェアスキャンエンジンです。検索結果にバッジを 表示するレピュテーションとカテゴリのデータベース（Trend MicroのSite Safety Centerもその 一つです）とは、そもそも系統が違います。こちらは別々の基盤の上で、それぞれ独自の審査 プロセスで動いているので、一つずつ確認していくことにしました。 ### Google Safe Browsing Google Safe Browsingは、Chrome・Firefox・Safariで表示される警告ページを管理しており、 実際の訪問者にとって最も影響が大きいサービスです。Search Consoleのセキュリティの問題 レポートと、一般公開されているTransparency Reportの見解は一致していました。**問題は検出されず、 安全でないコンテンツも見つかりませんでした**。 *Image: Google Transparency ReportのSafe Browsingサイトステータスページ。oharu121.comについて「現在のステータス：安全でないコンテンツは検出されませんでした」と表示されている* ### TrellixとMcAfee、分裂した2つのデータベース [McAfeeのWebレピュテーションデータベース](https://sitelookup.mcafee.com/)は、かつては一つのものでした。2024年に法人向け部門が Trellixとして独立し、コンシューマー向けのMcAfeeブランドとデータを共有しなくなりました。 そのため、**片方を確認しても、もう片方の判定はわからなくなっています**。 [TrellixのTrustedSource](https://www.trustedsource.org/)では、ドメインは「Uncategorized URL」、リスクは「Medium Risk」と 判定されていました。分裂後は別データベースとなったMcAfee独自のSite Lookupでは、 「Uncategorized」、信頼度は「Unverified」でした。どちらも危険とは判定していません。というより、 このドメインに関するデータをそもそも持っていませんでした。 *Image: TrellixのTrustedSource Customer URL Ticketing Systemの画面。oharu121.comが「Uncategorized URL」、レピュテーションは「Medium Risk」と表示されている* *Trellixのデータベース。* *Image: McAfeeのCustomer URL Ticketing Systemの画面。oharu121.comが「Uncategorized URL」、信頼度は「Unverified」と表示されている* *Trellixとは別のMcAfee独自のデータベース。上記のTrellixの結果とは無関係。* ### Microsoft SmartScreen：能動的な申請手段がない Microsoftのファイル送信ポータルは、一見すると正しい窓口に見えます。ただし `wdsi/filesubmission`は実行ファイルのマルウェア解析用で、URLは受け付けません。普通に 検索すると真っ先に出てくるページなので、この遠回りもあえて書いておきます。 サイト報告フォームは、ユーザーがすでに見た警告に対する異議申し立ての仕組みであり、 **未検出のサイトを安全だとMicrosoftに認めてもらう申請手段はありませんでした**。 SmartScreen自体のレピュテーションは、ドメインの登録年数や証明書の有効性、クロール履歴 といった要素から受動的に構築される仕組みです。そのため、異議を申し立てる対象も、申請 する窓口も存在しませんでした。 ## 自動スキャナーから見たService Workerの姿 他のどのチェックも、なぜTrend Microだけがこのサイトにフラグを立てたのかを説明してくれ ませんでした。そこで次に調べたのが、オフライン閲覧機能の裏側にあるコード、つまり Service Workerとその登録スクリプトです。 fetchハンドラーは、他の処理を行う前に、まず同一オリジンのリクエストだけに絞り込みます。 ```js title="scripts/sw/service-worker.js" if (url.origin !== self.location.origin) return; ``` このコードには、サードパーティサーバーへの通信も、スクリプトの注入も、`eval`の実行も 一切ありません。サイト自身のページとアセットをキャッシュするだけです。ただし登録 スクリプトは、永続ストレージも要求しています。7日間アクセスがないとストレージを削除する Safariの仕様から、オフラインキャッシュを守るためです。 ```js title="src/components/ServiceWorkerRegistration.astro" if (!storage?.persist) return; if (await storage.persisted?.()) return; storage.persist().catch(() => {}); ``` **Service Workerを登録し、永続ストレージを要求し、インストールを促す。このコードだけを 見れば、オフライン閲覧用に記事をキャッシュするPWAなのか、タブを閉じても生き残ろうと する詐欺ページなのか、区別がつきません。** ## sw.jsそのものを名指ししたブロック その数週間後、この仮説は直接的な形で裏付けられました。自分のマシンにインストールして いたTrend Micro製品が、実際にページ遷移をブロックしたのです。ブロックログには、対象の リソースが明確に記録されていました。 | 項目 | 値 | | --- | --- | | URL | `https://oharu121.com/sw.js` | | 脅威の種類 | 不正プログラム配信 | | スキャンの種類 | Webレピュテーションの評価 | | 処理 | ブロック | *Image: Trend Microのローカルログビューア。Web脅威対策のレコードが1件表示されており、2026年9月21日1時51分11秒にoharu121.com/sw.jsがブロックされたことを示している* *同じブロックを記録した、製品自体の履歴ログ。* これまでの検査でドメイン全体ではなく特定のファイルが名指しされたのは、これが初めて でした。最初の再分類申請はルートドメインに対するものだったので、Trend Microの データベースにあるこのファイル自体のエントリは、手つかずのままだったわけです。 > **ちなみに** > > **この失敗は表に出ません。** `ServiceWorkerRegistration.astro`は登録処理を > `.catch(() => {})`で包んでいるため、Trend Microを使っている訪問者にエラーが出ることは > なく、サイトは通常どおり読み込まれて動作します。ただオフラインキャッシュ機能だけが、 > 誰にも気づかれないまま失われているのです。 ## ドメインではなくファイルを再分類する そこで2回目の再分類申請を、今度は`https://oharu121.com/sw.js`に対して直接行いました。 コメント欄には、VirusTotalの結果と、このファイルが何をしているかの平易な説明を添え ました。 | 申請 | 対象 | 結果 | | --- | --- | --- | | 1回目、9月2日 | `https://oharu121.com/` | Dangerous、Disease Vector | | 2回目、9月3日 | `https://oharu121.com/sw.js` | Safe、Computers/Internet;Noteworthy | *Image: Trend MicroのSite Safety Centerからのメール。oharu121.com/sw.jsの再分類結果を示しており、新しい安全性評価はSafe、新しいコンテンツタイプはComputers/Internet;Noteworthyとなっている* > **よっしゃ！** > > **うまくいきました。** 確認メールは18日後に届き、Trend Microが`sw.js`を「Safe」に > 再分類したことが記されていました。 **ドメインではなく、フラグが立った具体的なリソースそのものを狙ったことが、結果を変えた 決め手でした。** ## まとめ PWAのService Workerに付いた誤った「不正プログラム配信」評価は、実際の感染ではなく、 パターンマッチングの問題に起因していました。Service Workerを登録し、永続ストレージを 要求し、インストールを促すという振る舞いは、オフライン閲覧が目的でも、詐欺サイトの 居座りが目的でも、スキャナーからは同じに見えてしまうのです。 他のすべてのレピュテーションサービスを横断的に確認したことで、このフラグが実際の侵害 ではなく、Trend Micro固有のものだと確認できました。そして最終的にうまくいった対処は、 最初の試みよりも的を絞ったものでした。ドメインではなく、**スキャナーが名指しした具体的 なファイルを再分類すること**、それが答えでした。 ## 参考リンク - [Trend Micro Site Safety CenterでのURLまたはWebサイトの再分類](https://success.trendmicro.com/en-US/solution/KA-0000017) - [Trend Micro製品による誤検知について](https://success.trendmicro.com/en-US/solution/KA-0003940) - [VirusTotal](https://www.virustotal.com)