本稿は2026年5月に開催された「Linux Security Summit North America 2026」において、サン氏が登壇したセッション「Exploring Function-Level Code Metrics and Developer Attributes for Linux Kernel Vulnerabilities」の内容を基に構成している。

　サン氏は、脆弱性の原因を作った「脆弱性誘発コミット」（VIC：vulnerability-inducing commits）と、それを修正した「脆弱性修正コミット」（VFC：vulnerability-fixing commits）のペアを8796組特定し、開発者の特徴やコードの複雑さとの関連を調べている。

　従来の研究はファイル単位で分析する方法が主流だ。しかし脆弱性はファイル全体ではなく特定の関数内で発生する。そのため本研究では、分析の単位を脆弱性が発生した箇所である関数レベルにそろえてデータを収集した。これによって、従来のファイル単位分析よりも詳細で正確な傾向の把握が可能になった。

　サン氏が開発者の活動履歴や経験値を比較・分析したところ、脆弱性を混入させた開発者には以下の明確な傾向が見られた。

• 経験やソースコードへの理解に欠ける
  • 過去のコミット数や直近6カ月間の活動量、対象ファイルやサブシステムへの熟知度が低い開発者ほど、脆弱性を生みやすい。
• ベテラン（メンテナー）の意外な関与
  • プロジェクトの取りまとめ役である「メンテナー」が、ドライバやファイルシステム、アーキテクチャ、メモリ管理などの主要領域において、脆弱性の修正時よりも混入時に高い割合で関与していた。

　2つ目の傾向について、サン氏が「メンテナーはより複雑なソースコードを扱っているためではないか」と仮説を立てて検証したところ、実際には非メンテナーが書いたソースコードの方がわずかに複雑であり、ソースコードの難易度だけが理由ではないことが明らかになった。

ソースコードの複雑さと脆弱性の意外な関係

　ソースコードにおける条件分岐の多さや制御フローの深さといった構造的な複雑度を比較した結果、興味深い事実が判明した。

• 脆弱性修正後のソースコードの方が複雑になる
  • 約70％の関数において、脆弱性が発生した時点よりも、脆弱性を修正した時点の方がソースコードの構造的な複雑度が高い。これは、脆弱性を直す過程で検証ロジックや条件チェックが追加されるためだと考えられる。
• 複雑さ＝脆弱性の発生源とは限らない
  • メモリ操作に関する指標を含め、構造的に複雑なソースコードが必ずしも脆弱性を生み出すわけではなく、複雑さだけを脆弱性の自動検出の指標に用いる手法には限界がある。

2015〜2025年の分析で多かった脆弱性の種類と場所

　2015年から2025年までのデータをまとめると、特定のパターンに集中していることが分かる。主な原因はメモリの安全性問題、空ポインタ参照、処理の競合の3つであり、これらが全体の80％以上を占めていた。主な発生箇所はドライバ、ネットワーク、ファイルシステムの3領域で全体の約半数を占めていた。共通処理が記述されたヘッダファイル（インクルードディレクトリ）も、頻繁にパッチが適用される箇所だった。

　今回の実証的な分析結果は、Linuxカーネルにおける脆弱性発見プロセスの効率化や、新たな脆弱性検出ツールの開発を後押しする基礎データとして活用が期待される。

本稿は、The Linux Foundationが2026年6月4日に公開した動画「Exploring Function-Level Code Metrics and Developer Attributes for Linux Kernel Vulnerabi... Yan Sun」を基に作成しました。