AI & CYBERSECURITY / OCTOBER 2026

AIが出した脆弱性レポート、何を確認して発注する？OSS Scannerの発表から

候補件数を成果にせず、重複・該当性・影響・修正の受入を分ける。

資料確認 2026-10-26 / 2026年10月特集

SONAEの提案 / 01

受け取った指摘に、対象版と根拠を求める

SONAEの運用案では、所見の識別子、対象版、該当する機能、成立条件、確認の根拠を必須欄にします。実行すべきでない再現物は、本番で動かさず専門担当が隔離環境で扱う判断へ渡します。説明が欠けた候補は確認待ちにし、報告書の見栄えや深刻度の色だけで発注を確定しません。

SONAEの提案 / 02

候補、重複、対象外、確認済み、修正済み、再確認済みは別の状態です。架空例で候補十件のうち重複があっても、十件の侵害が見つかったとは報告しません。受入前に状態と根拠を更新することで、見つける作業と直す作業の間を追えます。未確認をゼロへ変えるための安易な一括クローズも避けます。

SONAEの整理・受入の概念図。攻撃再現や実測の合格記録ではありません。

図の内容を文章で読む

生成した候補 → 人が該当性確認 → 修正後の受入。状態ごとの根拠を保持。未確認を有効件数へ足さない。概念図であり、実測ではありません。

SONAEの提案 / 03

候補パッチをそのまま本番へ入れず、影響する画面、API、保存形式、権限を確認します。架空データで機能と拒否の両方を確かめ、既存業務を壊さない条件を決めます。自動生成のコードであっても、反映する責任者と元へ戻す条件は必要です。修正の採用と脆弱性判定の承認を、記録上も区別します。

SONAEの提案 / 04

相談時には、どの候補を誰が判定するか、再確認を何回まで含めるか、対象外の条件は何かを見積もりへ入れます。SONAEが目指すのは指摘一覧を渡すだけの支援ではなく、担当と期限、未確認、改善後の根拠が残る成果物です。診断の本番提供は別の開始条件があるため、記事の特集公開と混同しません。

SONAEの提案 / 05

最初に重複と対象外を整理し、有効性と影響、業務の優先度を確認します。成立条件が不明の指摘を一括で本番再現することは避けます。修正の担当と再確認の条件を決め、候補の受付から閉じる判断までを追える状態にします。件数が多いことだけをもって被害や支援の価値を誇張しません。

SONAEの未実行の計画例です。診断の合格実績ではありません。

記入例はすべて架空です。秘密鍵、認証コード、個人情報の値は記入しないでください。