CSAF：機械可読なアドバイザリのためのCommon Security Advisory Framework

CSAFとは

Common Security Advisory Framework（CSAF）は、OASIS CSAF Technical Committeeによる標準で、セキュリティアドバイザリを構造化されたJSONとして記述し、自動的に検出、処理できるように配布するためのものです。CSAFドキュメントは、脆弱性がどの製品とバージョンに影響するか、どれが影響を受けないか、どれが修正済みか、そしてユーザーが何をすべきかを示します。

現行バージョンはCSAF 2.0で、2022年11月18日にOASIS Standardとして承認されました。CSAF 2.1も準備が進んでおり、その第4版Committee Specification Draftは2026年10月23日から11月6日までパブリックレビューにかけられましたが、まだ承認された標準ではありません。

アドバイザリを作成するのはベンダー（通常はその製品セキュリティインシデント対応チーム（PSIRT））と、各国のCERTなどの調整機関です。この2種類のチームの違いについては、PSIRTとCSIRTの比較をご覧ください。

CVRFからCSAFへ

CSAFは、XML形式のCommon Vulnerability Reporting Framework（CVRF）から発展したものです。ICASIが2012年5月にCVRF 1.1を、OASISが2017年9月にCVRF 1.2を公開しました。CSAF 2.0はこれを、JSON形式、検証用のJSONスキーマ、ドキュメントの種類ごとのプロファイル、アドバイザリの配布と検出のルールで置き換えました。仕様には、CVRFドキュメントをCSAFに変換する方法も引き続き定義されています。

CSAFドキュメントの構造

CSAFドキュメントは、3つの最上位要素で構成されます。

• document：メタデータ。必須のプロパティは5つで、カテゴリー（ドキュメントが従うプロファイル）、CSAFのバージョン、発行者、タイトル、トラッキングデータです。トラッキングには、アドバイザリID、ステータス、バージョン、初回と現在のリリース日、改訂履歴が含まれます。
• product_tree：ドキュメントが言及するすべての製品。通常はベンダーから製品名、バージョンへと分岐する形で記述され、ドキュメントの他の部分が参照する製品IDが付けられます。製品はpackage URL（purl）、CPE、ハッシュで識別することもできます。
• vulnerabilities：脆弱性ごとに1つのエントリ。CVEなどのID、注記、スコア、そして製品IDをリストに分類するプロダクトステータスを含みます。リストはknown_affected、known_not_affected、fixed、first_affected、last_affected、first_fixed、recommended、under_investigationです。対処方法はvendor_fix、workaround、mitigation、no_fix_planned、none_availableに分類されます。

CSAFの5つのプロファイル

CSAF全体で必須のフィールドはわずかです。プロファイルは、特定の種類のドキュメントにどのフィールドが必要かを定め、/document/categoryの値がそのドキュメントが従うプロファイルを示します。

プロファイル	カテゴリーの値	用途
CSAF Base	csaf_base	すべてのCSAFドキュメントが満たす最低限の要件。他のどのプロファイルにも当てはまらないドキュメントの受け皿
セキュリティインシデント対応	csaf_security_incident_response	他組織で発生したものも含む、セキュリティ侵害やインシデントへの対応
情報提供アドバイザリ	csaf_informational_advisory	危険な設定ミスなど、脆弱性ではない問題
セキュリティアドバイザリ	csaf_security_advisory	脆弱性とその対処方法。従来型のベンダーアドバイザリ
VEX	csaf_vex	各製品が脆弱性の影響を受けるかどうか、そしてその理由の表明

セキュリティアドバイザリには、プロダクトツリー、脆弱性、各脆弱性の注記、プロダクトステータスが必要です。VEXプロファイルはさらに厳格で、known_not_affectedとして記載されたすべての製品には、機械可読なフラグまたはテキストによる影響に関する説明が必要であり、known_affectedのすべての製品には、ユーザーが何をすべきかを伝える対処方法が必要です。

CSAF VEX

VEX（Vulnerability Exploitability eXchange）は、製品のコンポーネントに含まれる脆弱性のうち、実際に製品に影響するものをユーザーに伝えます。CSAF VEXは、OpenVEXやCycloneDX VEXと並ぶ3つの一般的なVEX形式のひとつです。そのフラグは、component_not_presentやvulnerable_code_not_in_execute_pathなど、CISAのVEX要件と同じ5つの「影響なし」の根拠を使います。TrivyとGrypeはどちらもCSAF VEXを読み取り、影響なしとされた検出結果を除外します。たとえばRed Hatは、CSAFアドバイザリとは別のディレクトリでCSAF VEXドキュメントを公開しています。

CSAFアドバイザリの配布方法

標準形式が役立つのは、ツールがドキュメントを見つけられる場合だけです。CSAF 2.0の第7章は、その方法を定めています。

• provider-metadata.jsonは、発行者とそのアドバイザリの所在を記述します。ツールは3つの経路のうち少なくとも1つでこれを見つけます。ドメインのsecurity.txtにあるCSAFフィールド、ウェルノウンURLの/.well-known/csaf/provider-metadata.json、またはドメインの前に付けたDNS名csaf.data.security.です。
• アドバイザリの一覧は、index.txtとchanges.csvを備えた年ごとのフォルダー、またはROLIEフィードで提供され、リダイレクトなしでTLS経由で配信されます。
• 各ファイルの名前はトラッキングIDに基づいて付けられます。TLP:WHITEのアドバイザリは自由にアクセスできる必要があり、TLP:AMBERやTLP:REDのものはアクセス制御の背後に置く必要があります。
• 完全性：信頼できるプロバイダーは、各ドキュメントにハッシュとOpenPGP署名を付け、公開鍵を公開します。

標準では、配布する側が名乗ることのできる5つの役割を定義しています。

役割	内容
CSAF publisher	有効なCSAFドキュメントを、自らの名義でのみ、TLS経由で公開する
CSAF provider	publisherの要件に加え、provider-metadata.json、検出経路、ディレクトリまたはROLIEフィードを提供する
CSAF trusted provider	providerの要件に加え、ハッシュ、OpenPGP署名、公開鍵を公開する
CSAF lister	他の当事者のCSAFドキュメントの所在リストを、コピーせずに維持する
CSAF aggregator	少なくとも2つの独立した発行元のドキュメントを、ハッシュと署名付きで1か所にミラーする

利用者は一度ダウンローダーを設定すれば、数十ものベンダーのWebページを見張る代わりに、自社製品が依存するすべてのプロバイダーから新しいアドバイザリを取得できます。

CSAFを公開している組織

CSAFは、産業、エンタープライズ、インフラのベンダーと、各国のCERTで最も広く使われています。

• Ciscoは、ウェルノウンCSAF URLでprovider-metadata.jsonを提供しています。
• Siemens ProductCERTは、アドバイザリをCSAF ROLIEフィードとして公開しています。
• Red Hatは、CSAFアドバイザリと、それとは別にCSAF VEXドキュメントを公開しています。
• ドイツの国家CERTであるBSIのCERT-Bundは、アドバイザリのCSAFフィードを公開しています。
• CISAは、ICSアドバイザリに2017年までさかのぼってCSAFドキュメントを付けることを2023年9月に発表し、ベンダーにこの標準の採用を促しました。

IEC 62443-4-1に取り組む産業機器のサプライヤーには、製品のセキュリティ問題をユーザーに伝えるプロセスが必要であり、機械可読なアドバイザリは顧客の期待に応える一般的な方法です。

CSAFのツール

• Secvisogramは、BSIが提供するCSAFドキュメント用のWebエディターで、フォームエディター、JSONエディター、HTMLプレビュー、検証機能を備えています。
• BSIとIntevationによるcsafツール（gocsaf/csaf、csaf_distributionとも呼ばれます）は、trusted provider、チェッカー、アグリゲーター、ダウンローダーを実装しており、CSAF 2.1版も開発中です。
• TrivyやGrypeなどのスキャナーは、CSAF VEXドキュメントを読み込みます。

WebページとRSSフィードからCSAFへ移行する

多くのベンダーは5つのステップでCSAFに移行します。製品とバージョンの一覧を整える、必要なCSAFのロールを選ぶ、検出用ファイルとフィードを公開する、アドバイザリを手書きせず生成する、そしてVEXと過去分のアーカイブを最後に加える、の5つです。CSAFへの移行は、JSONの問題であることはほとんどありません。アドバイザリが参照できる製品一覧と、機械がそれを見つけるための経路を用意することが本題です。

多くのベンダーの出発点

よくある構成は、アドバイザリごとのHTMLページ、ときにPDF、RSSまたはAtomフィード、メーリングリストです。人は読めますが、顧客側のツールにはあまり使い道がありません。安定した製品識別子がなく、バージョンごとの影響あり・影響なしのステータスもなく、ベンダーのアドバイザリをすべて見つける手段も、完全性の確認手段もありません。BSIも同じ問題を指摘しています。購読しなければならないRSSフィードがあるか、新しいアドバイザリが誰かが見に行かなければならないWebサイトにしか載らないか、のどちらかだというのです。従来の構成の各要素には、CSAFでの対応物があります。

従来の要素	CSAFでの対応物
アドバイザリのWebページ	プロファイルcsaf_security_advisoryのCSAFドキュメント
文章で書かれた「影響を受けるバージョン」	product_treeとproduct_status
RSSフィード	ROLIEフィード、またはindex.txtとchanges.csvを置いたディレクトリ
「購読」ページ	provider-metadata.jsonと検出経路
PDFの署名、または署名なし	ハッシュとOpenPGP署名（trusted provider）
「最終更新」の表記	trackingとrevision_history

RSSフィードは配信チャネルで、CSAFは形式です。FIRST PSIRT Services Frameworkは、アドバイザリを届ける方法として「Webドキュメント、RSSフィード、購読」を挙げ、それとは別に、顧客が自動で処理できるよう「Common Security Advisory Framework（CSAF）のような機械可読形式で」アドバイザリを公開することを勧めています。フィードはそのまま残せます。

ステップ1：まず製品一覧を整える

移行がつまずくのはproduct_treeです。最初のCSAFドキュメントの前に、顧客が自社の機器や資産台帳で目にするものと一致する、製品とバージョンの正式な一覧が必要です。できればそれぞれにCPEまたはpackage URLを付けます。これは、PSIRTがCVEの影響を受けるバージョンを知るために必要な一覧と同じもので、PSIRTをスケールさせる方法がバージョンごとのインベントリから始まるのもそのためです。ブランチはベンダーから製品ファミリー、製品、バージョンへとつながります。

"product_tree": {
  "branches": [{
    "category": "vendor",
    "name": "Example Networks",
    "branches": [{
      "category": "product_family",
      "name": "EX Series",
      "branches": [{
        "category": "product_name",
        "name": "EX-200",
        "branches": [{
          "category": "product_version",
          "name": "4.2.1",
          "product": {
            "product_id": "EX200-4.2.1",
            "name": "Example Networks EX-200 4.2.1",
            "product_identification_helper": {
              "cpe": "cpe:2.3:o:example:ex-200_firmware:4.2.1:*:*:*:*:*:*:*"
            }
          }
        }]
      }]
    }]
  }]
}

オープンソースのコンポーネントを含む製品の場合、アドバイザリに書くのは自社の製品バージョンです。判断の裏付けとなるコンポーネントのインベントリ、つまりどのバージョンが脆弱なライブラリを含むかは、SBOMが担います（SBOMとは）。

ステップ2：ロールを選ぶ

5つのロールは前述のとおりです。ベンダーにとって、選択肢は実質的に3つです。

ロール	選ぶべき場面	追加されるもの
CSAF publisher	まずは自社サイトに有効なCSAFドキュメントを置ければよい場合	TLSで提供する有効なドキュメント。ツールは自力では見つけられません
CSAF provider	顧客にアドバイザリを自動取得してもらいたい場合。現実的な最低ライン	provider-metadata.json、検出経路、ディレクトリまたはROLIEフィード
CSAF trusted provider	顧客や当局が署名付きのアドバイザリを求める場合	ハッシュ、OpenPGP署名、公開された公開鍵

listerとaggregatorはコーディネーター向けのロールで、ベンダー向けではありません。gocsaf/csafのツールには、trusted providerを実装するcsaf_providerと、プロバイダーの構成を標準の第7節に照らして検査するcsaf_checkerが含まれています。フィードを告知する前にcheckerを実行してください。

ステップ3：検出経路とフィード

• provider-metadata.jsonを公開します。場所は自社ドメインの/.well-known/csaf/です。
• security.txtからそれを指します。RFC 9116がこのファイルを定義し、CSAF 2.0の要件8がCSAF:フィールドを追加しています。URLはhttps://で始まる必要があります。

Contact: mailto:[email protected]
Expires: 2027-11-11T00:00:00.000Z
# Our security advisories
CSAF: https://www.example.com/.well-known/csaf/provider-metadata.json

• RSSフィードをROLIEフィードに置き換えるか、両方を運用します。ROLIE（Resource-Oriented Lightweight Information Exchange、RFC 8322）はAtomを基盤としているため、すでに公開しているフィードの自然な後継になります。index.txtとchanges.csvを置いたディレクトリでも構いません。
• 各フィードにTLPのレベルを付けます。CSAF 2.0はTLP 1.0のラベルWHITE、GREEN、AMBER、REDを使います。2022年8月から正式版となっているFIRSTのTLP 2.0はCLEAR、GREEN、AMBER、REDを使い、AMBERの拡張としてAMBER+STRICTがあります。CSAF 2.1の草案はこれらのラベルを採用しています。CSAF 2.0では、公開アドバイザリはTLP:WHITEです。

ステップ4：手書きせず生成する

新しいアドバイザリは、脆弱性ごとにすでに管理している記録、つまりトラッカーの案件や脆弱性データベースから生成し、公開前にそれぞれをスキーマと標準のテストで検証します。件数が少ない場合や編集には、Secvisogramが向いています。人が読むページも同じJSONドキュメントから生成すれば、WebページとCSAFファイルの内容が食い違うことはありません。改訂では同じドキュメントのtracking/versionとrevision_historyを更新し、新しいドキュメントは公開しません。

ステップ5：VEXとアーカイブ

顧客から最も多く問い合わせのあるCVEについては、影響なしの表明をCSAF VEXとして公開します。1件ごとに、繰り返される問い合わせが1つ止まります。過去のアドバイザリの移行は最後に、まだサポート中の製品から進めます。古いアドバイザリがCVRF形式なら、仕様の変換ルールで対応できます。

CSAF 2.0か2.1か

今すぐ2.0で公開してください。2.0は承認済みのOASIS Standardで、国際規格ISO/IEC 20153:2025としても発行されています。CSAF 2.1はまだCommittee Specification Draftで、第4版の草案は2026年10月21日に承認され、パブリックレビューは2026年11月6日に終了しました。ツールも準備を進めています。Secvisogramはすでに2.1のドキュメントを編集でき、gocsaf/csafのツールでは次のメジャーバージョンに向けて2.1対応の開発が進んでいます。

CRAとBSIが求めていること

• Cyber Resilience ActはCSAFを名指ししていません。第14条第8項は、積極的に悪用されている脆弱性または重大なインシデントを認識した製造者に対し、影響を受ける利用者、適切な場合にはすべての利用者に、「適切な場合には、構造化され、機械可読で、自動処理が容易な形式で」知らせるよう求めています。附属書I第II部は、セキュリティアップデートが提供された時点で修正済みの脆弱性に関する情報を公開すること、そして協調的な脆弱性開示の方針を持つことを求めています。CSAFは、機械可読の部分を満たす方法の1つです。
• BSIは自らのCERT-BundのアドバイザリをCSAFで公開しています。BSIの技術ガイドラインTR-03183-3（Vulnerability Reports and Notifications、v1.0.0、2025年8月）は、CSAFを用いて製造者のWebサイトで公開することを、アドバイザリ配布の推奨方法としています（3.1.5節）。security.txtファイルを必須とし（4.2節）、製造者はそこにprovider-metadata.jsonをCSAF:フィールドで記載すべきだとしています（4.2.8節）。技術ガイドラインは指針であり、法律ではありません。
• ENISAのSingle Reporting Platformは、CRAに基づく当局への通知のためのもので、利用者向けのアドバイザリのためのものではありません。CSAFアドバイザリを公開しても通知の代わりにはならず、通知をしても利用者に知らせたことにはなりません。

最小限のCSAF構成

• 製品とバージョンの一覧（可能であればCPEまたはpackage URLの識別子付き）
• publisherのメタデータ：名前、カテゴリー、名前空間、連絡先
• プロファイルcsaf_security_advisoryによる最初のアドバイザリ
• スキーマと標準のテストによる検証
• provider-metadata.json（/.well-known/csaf/に配置）
• security.txtのCSAF:行
• ROLIEフィード、またはindex.txtとchanges.csvを置いたディレクトリ
• すべてのURLでTLS、リダイレクトなし
• JSONから生成した人が読めるページ
• trusted providerに移行する時点で、公開された署名鍵

優れたセキュリティアドバイザリの書き方

CSAFを使うかどうかにかかわらず、役に立つアドバイザリは同じ問いに答えます。以下は多くのPSIRTが行き着くテンプレートで、各回答を格納するCSAFのフィールドも併記しています。

アドバイザリの要素	記載する内容	CSAFでの位置
IDとタイトル	安定したアドバイザリIDと、製品名と問題の種類を示すタイトル	tracking/id, title
日付と改訂	初回公開日、最終更新日、各改訂での変更内容	trackingの日付とrevision_history
影響を受ける製品	「旧バージョン」ではなく、正確な製品とバージョン範囲	product_tree, known_affected
影響なしと修正済み	影響を受けない製品とバージョン、および修正を含むバージョン	known_not_affected, fixed, first_fixed
脆弱性	CVE ID、わかりやすい説明、影響と悪用の方法。ただし攻撃者向けの手順は書かない	cve, ids, notes
深刻度	読み手が確認できるよう、ベクトル付きのCVSSスコア	scores
対処方法	修正済みバージョン、回避策や緩和策、または修正予定がないことの明確な表明	remediations
謝辞と参考情報	報告者、関連するアドバイザリや修正へのリンク	acknowledgments, references
連絡先	問題の報告先と問い合わせ先	publisher/contact_details

いくつかの習慣が、行動につながるアドバイザリと無視されるアドバイザリの違いを生みます。

• バージョンを正確に示す。顧客が行動の基準にするのは影響範囲です。製品ラインごとに、最初に影響を受けたバージョンと最初に修正されたバージョンを明記してください。
• 影響を受けないものを示す。対象外と判断した製品を使っている顧客は問い合わせをやめ、VEXも公開すれば、そのスキャナーもフラグを立てなくなります。
• 置き換えずに更新する。問題ごとにアドバイザリを1つにまとめ、修正のリリースに合わせて改訂を追加してください。
• 合意した日に公開する。アドバイザリは協調的な脆弱性開示の最終段階であり、修正が利用可能になり、報告者に通知した時点で公開します。

受付やトリアージから修正までのアドバイザリ以前の段階は脆弱性管理のライフサイクルで、この業務を担う人々についてはPSIRTの役割で解説しています。

難しいのは、何が影響を受けるかを把握すること

CSAFでも他の形式でも、すべてのアドバイザリはひとつの答えにかかっています。脆弱なコンポーネントを含むのはどの製品とバージョンか、です。オープンソースパッケージから構築されたソフトウェアの場合、それは各リリースにどの依存関係のバージョン（推移的依存関係を含む）が入ったかを正確に把握することを意味します。

CRACIはアドバイザリを作成も公開もしません。CRACIが提供するのは、アドバイザリの製品ステータスの根拠となる記録です。CRACIはGitHub Actionsのビルドを自社のランナーで実行し、各ジョブが実際に取得したパッケージを記録します。推移的依存関係、キャッシュから復元されたパッケージ、どのロックファイルにも載っていない依存関係も含みます。新しい脆弱性が公開されると、監視対象のSBOMが再評価され、ビルド履歴によって、脆弱な依存関係を直接的または推移的に含んでいた過去のビルドとリリース、そしていつからかがわかります。インベントリビューではどのバージョンがどの製品にデプロイされているかがわかり、トリアージによって各検出結果が修正を担当するチームに割り当てられます。SBOMはCycloneDXまたはSPDXでエクスポートでき、CRACIはVEXに対応しています。詳しくは脆弱性トラッキングをご覧ください。

CSAF：よくあるご質問

CSAFは何の略ですか？

セキュリティの分野では、CSAFはCommon Security Advisory Frameworkの略です。セキュリティアドバイザリを機械可読なJSONドキュメントとして記述し、ツールが自動的に検出して処理できるように配布するためのOASIS標準です。

CSAFの現在のバージョンは何ですか？

CSAF 2.0です。2022年11月18日にOASIS Standardとして承認され、ISO/IEC 20153:2025としても発行されています。CSAF 2.1は策定中で、第4版Committee Specification Draftが2026年10月21日に承認され、2026年11月6日にパブリックレビューを終えました。まだ承認されたOASIS Standardではありません。

CSAFとCVEの違いは何ですか？

CVEレコードは1つの脆弱性を識別し、一般的な内容を説明するものです。CSAFアドバイザリはベンダーや調整機関が発行し、その脆弱性（多くの場合は他の複数の脆弱性も）が特定の製品とバージョンにどう影響するか、そして何をすべきかを示します。CSAFアドバイザリはCVE IDを参照します。

CSAF VEXとは何ですか？

CSAF VEXは、CSAFのcsaf_vexプロファイルです。VEXステートメントを伝えるもので、製品ごとに、影響あり、影響なし、修正済み、調査中のいずれであるかを示し、影響のない製品には影響に関する説明を、影響のある製品には対処方法を記載します。TrivyとGrypeはこれを読み取って検出結果を抑制できます。

CSAFプロバイダーとは何ですか？

CSAFプロバイダーとは、自らのCSAFドキュメントをツールが検出できる形で公開する組織です。security.txt、ウェルノウンURL、またはDNS名で見つけられるprovider-metadata.jsonファイルと、アドバイザリのディレクトリまたはROLIEフィードを用意します。信頼できるプロバイダー（trusted provider）は、さらにハッシュ、OpenPGP署名、公開鍵を公開します。

CSAFは何を置き換えたのですか？

XML形式のCommon Vulnerability Reporting Framework（CVRF）です。CVRF 1.1は2012年にICASIが、CVRF 1.2は2017年にOASISが公開しました。CSAF 2.0はJSONに移行し、プロファイル、プロダクトツリー、配布のルールを追加しました。

CSAFアドバイザリはどのように作成しますか？

多くのチームは、BSIが提供するCSAF用のWebエディターであるSecvisogramなどのエディターから始めるか、自社の脆弱性トラッキングからJSONを生成します。プロファイル（通常はcsaf_security_advisory）を選び、発行者、トラッキングデータ、プロダクトツリー、脆弱性を記入し、スキーマに照らして検証したうえで、プロバイダーを通じて公開します。

セキュリティアドバイザリをWebページからCSAFに移行するには？

まず製品とバージョンの正式な一覧を用意し、次にCSAFプロバイダーになります。provider-metadata.jsonを公開し、security.txtからそれを指し、ROLIEフィードまたはディレクトリでアドバイザリを一覧にします。新しいアドバイザリは脆弱性の記録から生成し、Webページも同じJSONから生成し、過去のアドバイザリは最後に移行します。

CSAFを公開してもRSSフィードは残せますか？

はい。RSSフィードは配信チャネルで、CSAFは形式なので、両者は共存できます。人と機械の両方に向けた1つのフィードにしたい場合、ROLIEフィードはAtomを基盤としているためRSSフィードを置き換えられます。両方を同じアドバイザリデータから生成すれば、内容が食い違うことはありません。

必要なCSAFのロールはpublisher、provider、trusted providerのどれですか？

多くのベンダーに必要なのはCSAFプロバイダーです。有効なドキュメント、provider-metadata.json、検出経路、ディレクトリまたはROLIEフィードをそろえ、顧客がアドバイザリを自動で取得できるようにします。publisherだけではツールに見つけてもらえない出発点にとどまります。顧客や当局が署名付きのアドバイザリを求めるようになったら、ハッシュ、OpenPGP署名、公開鍵を備えた信頼できるプロバイダー（trusted provider）になります。

Cyber Resilience ActはCSAFを義務付けていますか？

いいえ。CRAは形式を指定していません。第14条第8項は、積極的に悪用されている脆弱性や重大なインシデントについて、影響を受ける利用者に、適切な場合には構造化され機械可読で自動処理しやすい形式で知らせるよう製造者に求めています。CSAFはそれを満たす方法の1つで、BSIが推奨する形式です。

BSIはCSAFについて製造者に何を求めていますか？

BSI TR-03183-3は法律ではなく技術ガイドラインで、CSAFを用いて製造者のWebサイトで公開することを、アドバイザリ配布の推奨方法としています。security.txtファイルを必須とし、製造者はそこにprovider-metadata.jsonをCSAF:フィールドで記載すべきだとしています。BSI自身もCERT-BundのアドバイザリをCSAFで公開しています。

CSAF 2.0で公開すべきですか、それとも2.1を待つべきですか？

今すぐ2.0で公開してください。2.0は承認済みのOASIS StandardでありISO/IEC 20153:2025でもあり、ツールも対応しています。CSAF 2.1はまだCommittee Specification Draftで、第4版の草案は2026年10月から11月にかけてレビューされました。後から2.1に移るのはツールの更新で済むため、待つ理由にはなりません。