セキュリティエンジニアリングはコンテキストの問題
多数の脆弱性が見つかる状況は、セキュリティエンジニアリングが抱える本質的な課題を浮き彫りにしている。
脆弱性スキャナが大量の指摘を出すものの、それが実際に攻撃を許すリスクがあるのか、誰が対応すべきかといったコンテキストが欠如しているため、対応が追いつかない。
セキュリティチームは脆弱性対応のためのツールを構築しているが、その目的はあくまで脆弱性を見つけ出し、対応するプロセスを効率化することであり、結局はコンテキストの不足がボトルネックとなっている。
開発者とセキュリティエンジニアの仕事は似ているが、コンテキストの事前知識に差があり、それが対応時間の差に繋がっている。
企業のセキュリティ対策において、膨大な数の脆弱性情報（ファインディング）が検出されるものの、それらを「どこから手をつけていいか分からない」という課題が深刻化しています。本記事は、セキュリティエンジニアリングのボトルネックは知識やツールではなく「文脈（コンテキスト）」にあるという視点から、現在のセキュリティ運用が抱える根本的な課題を解説します。
セキュリティ運用の本質はトリアージ作業
セキュリティエンジニアリングは、新しい問題を発見するだけでなく、検出された問題が「本当に重要か」「誰が責任を持つのか」「修正すると何が壊れるのか」を判断し、優先順位をつける「トリアージ（選別）」の連続であると説明されています。これは、新機能を開発するソフトウェア開発と役割が逆転している状態に似ています。つまり、セキュリティチームは「問題を取り除く」ためのツールや仕組みを構築しているのです。
ボトルネックは知識ではなく文脈の欠如
セキュリティの課題は、専門知識（例：SQLインジェクションが何か）の不足ではなく、その脆弱性がシステム全体の中でどのような意味を持つかという「文脈」の欠如にあると指摘されています。例えば、検出された脆弱性が外部からアクセス可能な経路にあるのか、機密データが流出する可能性があるのかといった判断が、作業の成否を分ける8割を占めるとのことです。
ツールが問題を複雑化させる構造的な罠
脆弱性スキャナーなどのツールは、検出を高速化する一方で、意図的に文脈を排除した状態で大量の情報を出力します。この「文脈剥奪」されたファインディングを人間が一つ一つ読み込み、関連情報を再構築する作業は非常にコストがかかります。結果として、ツールが生成する情報の量と、人間が文脈を再構築できる速度との間に大きなギャップが生じ、バックログが膨大化していると分析されています。
まとめ
セキュリティ対策の効率化には、単に検出ツールを増やすのではなく、検出された情報に「文脈」を付与し、人間が判断しやすい状態にすること、すなわち「コンテキストの再構築」に注力することが重要であると結論づけています.
原文の冒頭を表示（英語・3段落のみ）
A founder I was advising recently sent me a screenshot. 4,200 open findings in their scanner. “Where do I even start?”
I asked the grounding questions. Which ones are exploitable? Which assets are internet-facing? Which services hold customer data? Which findings are duplicates of the same root cause? Who owns each repo?
He didn’t know. The scanner didn’t know either. That’s not the scanner’s job.
※ 著作権に配慮し、引用は冒頭3段落までです。続きは元記事をご覧ください。