PoC/Exploitとは
（公開された時の優先度判断）
PoC は Proof of Concept の略で、脆弱性が 「どう悪用できるか」を示す実証コードや再現方法 を指します。
CISAはKEVの説明ページで、PoCを「実行すれば脆弱性の悪用を可能にするコード」と説明しつつ、PoCが公開されていること自体は active exploitation（実際の悪用中）を意味しない と明記しています。cisa.gov
一方、Exploit はより広く、脆弱性を利用するコードや手法全体を指します。
CISAはKEVの文脈で、active exploitation / exploited を「脅威アクターが無許可でコードを実行し、実際に脆弱性を利用した状態」と整理しています。cisa.gov
つまり実務上は、
PoC = 再現可能性の公開
Exploit = 実際の悪用
と分けて考えると分かりやすいです。
PoCが公開された時、なぜ優先度が上がるのか
PoC（実証コード）がGitHubやセキュリティブログなどで公開されると、攻撃者にとっての再現コストが下がるため、一般にトリアージの優先度は上がります。
CISA の SSVC（Stakeholder-Specific Vulnerability Categorization）フレームワークでは、Public PoC を exploitation status の1つとして明確に分けており、典型的な public PoC や well-known method of exploitation が存在する状態を、何もない状態（None）よりも一段上の扱い（リスクが高い状態）にしています。cisa.gov
ただし注意が必要な点
PoCの公開は「すでに攻撃されている」ことと同義ではありません。CISAは KEV の説明で、PoCの公開は悪用可能性（リスク）を上げるが、KEV 収載の条件は active exploitation の確たる証拠 であって、PoCの存在そのものではない と明確に区別しています。cisa.gov
実務での優先度判断（トリアージの指針）
サプライヤー実務において、PoCやExploitの情報が入った際は、次のような3段階の温度感で見ると整理しやすいです。
→ 最優先候補。対象版数と到達性をすぐ確認する。
すでに野外で悪用されている状態です。CISAは KEV（Known Exploited Vulnerabilities）を優先修正のための authoritative source と位置づけており、OEMからの照会も厳しくなります。cisa.gov
→ 優先度を1段上げる。影響対象版数、外部IF、成立条件を早めに確認する。
攻撃のハードルが下がっている状態です。放置すれば active exploitation に発展する可能性が高いため、調査の順番を早めます。cisa.gov
→ CVSSスコア、到達性、期限、EPSSなど他要素と組み合わせて判断する。
FIRSTは EPSS を exploitation activity の確率指標であり、リスク全体ではなく threat（脅威）の一部を見るものだと説明しています。PoCがない場合は、こうした予測指標も参考にしつつ通常のトリアージフローに乗せます。first.org
よくある誤解
-
誤解1：PoCがあれば即“影響あり”である
違います。 PoCはあくまで「そのコンポーネントにおける再現方法の公開」であって、自社製品でそれが成立するかは別問題です。対象版数・到達性・前提条件（設定など）の確認が必ず必要です。cisa.gov
-
誤解2：PoCがないなら安全である
違います。 CISAも、PoCの有無は active exploitation の有無とは別だと整理しています。PoCが一般に公開されていなくても、水面下でゼロデイ攻撃として実際に悪用されているケースは存在します。cisa.gov
-
誤解3：PoCとExploitは同じ意味だ
違います。 実務上は、PoCは“再現できる状態（実証コード）”、Exploitは“実際に脆弱性を利用するコードや手法全般”、さらに active exploitation は“無許可で実際の悪用が行われている状態”と分けて考えると、対応の緊急度を見誤る混乱が減ります。cisa.gov
FAQ：PoC/Exploitとは
脆弱性がどう悪用できるかを示す実証コードや再現方法です。これがインターネット上に公開されると、攻撃のハードルが下がるため注意が必要です。cisa.gov
脆弱性を利用するコードや手法のことです。CISAのKEVなどの文脈では、active exploitation を“無許可で実際に脆弱性が使われた状態（悪用中）”として扱っています。cisa.gov
必ずしも緊急対応とは限りませんが、トリアージの優先度は上げるべきです。最終的な対応方針は、自社製品の対象版数、到達性（外部から攻撃可能か）、OEMからの回答期限、KEV収載の有無などを総合的に合わせて判断します。cisa.gov
自社に必要な脆弱性の「優先度基準」を整理しませんか？
PoCの公開やKEVへの掲載など、日々変化する脅威情報の中で「いつ、誰が、どの脆弱性を最優先で評価すべきか」。自社製品の特性に合わせたトリアージ対応の基準や、OEMへの回答フローを整理したい方はご相談ください。