Application Security

誤検知

誤検知とは、セキュリティツールが実際には存在しない問題を報告することです。

誤検知

TL;DR

セキュリティにおいて、誤検知とは、実際には存在しない問題をツールが報告することを指します。

誤検知とは?

誤検知とは、セキュリティツールが実際には存在しない問題を報告することです。

簡単な例:

  • 実際の問題:火事が原因で煙探知機が作動する。
  • 誤検知:料理の蒸気が原因で煙探知機が作動する。

警報は本物ですが、実際の危険はありません。

誤検知が問題となる理由

誤検知は時間を無駄にするだけではありません。時間が経つにつれて、実際の問題を引き起こす可能性があります。

それにより以下のことが起こります:

  • 存在しない問題を修正するために時間を無駄にする
  • セキュリティチームと開発チームの間でのフラストレーション
  • 実際の問題が無視されるため、リスクが高まる

誤検知が発生する理由

セキュリティツールは慎重に設計されています。実際の攻撃を見逃すよりも、多くの警告を出す方が安全です。

一般的な理由:

  1. コンテキストの欠如

    ツールがハードコーディングされたパスワードを検出しますが、それはテストファイルにのみ存在します。

  2. 複雑なコード

    ツールはユーザー入力が安全でないと考えますが、コードはすでにそれをクリーンにしています。

  3. 古いルール

    新しい安全なソフトウェアが古い脅威のように見えます。

  4. ルールが広すぎる

    例えば、安全であってもすべてのeval()の使用をフラグする。

誤検知の実際のコスト

あまりにも多くの警告が蓄積されると、実際の問題が発生します。

  • チームは警告に注意を払わなくなります。
  • ビルドとリリースが遅くなります。
  • 熟練したエンジニアが偽の問題をレビューするために時間を無駄にします。

偽陽性と偽陰性

用語意味
真陽性実際の問題が正しく発見される
偽陽性問題が報告されるが実際には存在しない
真陰性安全なコードが正しく無視される
偽陰性実際の問題が見逃される(これは危険です)

関連用語

FAQ

アラートが偽陽性かどうかを知るにはどうすればいいですか?

実際のユーザーが問題を引き起こす可能性があるかどうかを判断するためにコードをレビューする必要があります。

ツールに偽陽性がゼロであることは可能ですか?

いいえ。目標はそれらを完全に排除するのではなく、減らすことです。

偽陽性が多いツールの使用をやめるべきですか?

すぐにはやめないでください。ほとんどのツールはコードベースに合わせて調整する必要があります。

Ready to validate what matters?

Ready to validate what matters?

Plexicus is Proof-Driven AppSec: validated findings, contextual understanding, and reviewed remediation — anchored in evidence, scoped with you.

Qualification

Check whether AI Swarm Pentest fits your environment.

Share the minimum context. We will review the scope and tell you the next commercial step.

Before submitting — verify you fit

Teams with fewer than 50 developers: start a 14-day Trial instead of booking a demo. Start a 14-day Trial →

0 / 280

No commitment. If you don't fit, we'll tell you.

SAMPLE HANDOVER · ILLUSTRATIVE

Sample evidence handover

A trimmed view of what your team receives at the end of an AI Swarm Pentest engagement. Real engagements include full technical evidence, executive narrative, and a remediation plan.

VALIDATED FINDING Evidence attached

Server-Side Request Forgery in webhooks/receiver

demo-project/sample-app · src/webhooks/receiver.py:42

SeverityHigh CVSS 3.18.6 Priority79 Confirmedvia replay

Untrusted caller-supplied URLs reach an internal egress without an allowlist. Replayed in a sandbox against a fresh authorised target — the same control was validated to fail twice.

REVIEWER-READY REMEDIATION Merge-ready PR

Validate the target URL against an allowlist of permitted hostnames. Reject private/internal IP ranges. Enforce HTTPS only.

plexicus/remediation/webhooks-ssrf 3 changed · 0 new files
42resp = requests.get(target_url)
42+if not is_allowed_host(target_url):
43+  raise WebhookRejected(target_url)
44+resp = requests.get(target_url, timeout=5)
Every engagement hands over:
  • Executive briefing
  • Validated findings list
  • Merge-ready PRs
  • Compliance mapping (NIS2 · DORA · CRA)