オープンソース流「広報戦略“虎の巻”」：オープンソースソフトウェアの育て方（3/4 ページ）

[Karl Fogel， ]

• CAN／CVE番号

　これまでに、セキュリティの問題の中でCAN番号やCVE番号といったものをみたことがある人がいるかもしれません。例えば「CAN-2004-0397」あるいは「CVE-2002-0092」といった形式のものです。

　これらの番号は、どちらも同じ型の内容を表しています。これはCVEで管理されている“Common Vulnerabilities and Exposures”リストのエントリを表します。このリストの目的は、既知のセキュリティ問題についての共通の呼び名を提供することにあります。そうすることで、個々の問題をはっきり区別できるようになります。また、詳細な情報を探すための中央広場としての働きもあります。

　「CAN」番号と「CVE」番号の唯一の違いは、前者はまだ正式に認定される前の状態であるということです。CVE Editorial Boardによって認定されて公式リストに登場したものが後者となります。しかし、どちらの情報も一般に公開されており、認定の前後で番号自体は変わりません。単に、番号の前の「CAN」が「CVE」に置き換わるだけのことです。

　CAN／CVEのエントリ自体には、バグの詳細な説明や対処方法などは含まれていません。その代わりに、そのバグの概要説明と外部リソース（メーリングリストのアーカイブなど）へのリンクを用意し、詳細な情報が知りたい人はそちらを参照すればいいようになっています。CVEの真の目的は、きちんと整理整頓された場所を用意してすべての脆弱性に名前をつけ、詳細なデータを得るための道筋を示すことです。例えば、エントリの例としてこちらを見てみましょう。その記述内容は非常に簡潔なものであり、なにやら怪しげな略語をつけたリンクがあるだけです。これらの略語の意味はこちらでご確認ください。

　あなたが対応した脆弱性がCVEの条件を満たすようなら、CAN番号の取得を検討するといいでしょう。取得方法は、意図的に難しくしてあります。基本的に、まずあなたが誰かの知り合いであるか、誰かの知り合いの知り合いである必要があります。何だかよく分からない言い方ですが要するにこういうことです。脆弱性でもない内容や中身のないような報告に対応するのを避けるため、CVE Editorial Boardは既知の信頼できる情報源からの報告しか受け取らないのです。従って、脆弱性をリストに載せてもらうには、あなたのプロジェクトとCVE Editorial Boardの橋渡しをする仲介役が必要になるということです。

　周囲の開発者に聞いてみましょう。その中に一人くらいは、「以前に一度CANを取得したことがある」とか「知り合いがCANを取得していた」とかいう人がいるでしょう。この方式の利点は、知り合いのつてをたどっていくうちに、a）それはMITREの言うところの脆弱性に該当しないから投稿する必要はないとか、b）その脆弱性にはすでにCANあるいはCVE番号が割り当てられているといったことを教えてくれるかもしれないということです。

　後者の可能性としては、そのバグが既に別のセキュリティメーリングリストで報告されているといったことがあります。例えばCERT、あるいはSecurityFocusのBugTraqメーリングリストなどがこれに当たります（もしあなたのプロジェクトに対して何も連絡がないまま後者の状態になっているのだとしたら、自分たちのうかがい知れないところで何かが起こっているということを心配しなければなりません）。

　どうせCAN／CVE番号を得るのなら、普通はバグの調査段階のできるだけ早いうちに番号を取得したいものです。そうすれば、その後のやり取りはその番号を使用して進めることができます。CANエントリは、一般に公開される日まで使用できません。それまでは空のエントリが存在するだけ（場所を確保するだけ）であり、あなたがバグの存在と修正を公表するまで、そこには何の情報も掲載されません。

　CAN／CVEのプロセスについてのより詳細な情報はCVE Candidates Explainedで得られます。またCAN／CVE番号を非常にうまく使っているオープンソースプロジェクトの例としてはDebianとCVEの互換性があります。