CSAF：讓資安公告機器可讀的通用資安公告框架

什麼是 CSAF？

通用資安公告框架（Common Security Advisory Framework，CSAF）是 OASIS CSAF 技術委員會制定的標準， 用於將資安公告撰寫成結構化 JSON 並加以發布，讓公告能被自動找到與處理。 CSAF 文件會說明漏洞影響哪些產品與版本、哪些不受影響、 哪些已修正，以及使用者應採取哪些行動。

目前的版本是 CSAF 2.0，於 2022 年 11 月 18 日核准為 OASIS 標準。CSAF 2.1 即將推出：其 第四版 Committee Specification Draft 已於 2026 年 10 月 23 日至 11 月 6 日接受公開審查，目前尚未成為核准的標準。

資安公告由廠商撰寫（通常由其產品資安事件應變小組 （PSIRT）負責），也由國家級 CERT 等協調機構撰寫。關於這兩種團隊的差異，請參閱 PSIRT vs 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 文件有三個頂層部分：

• document：中繼資料。其中五個屬性為必填：類別（文件遵循哪個設定檔）、 CSAF 版本、發布者、標題與追蹤資料。追蹤資料包含資安公告 ID、狀態、版本、 首次與目前的發布日期，以及修訂歷程。
• product_tree：文件提及的每項產品，通常以從廠商、產品名稱到版本的分支表示， 並附有文件其他部分所引用的產品 ID。產品也可以透過 package URL（purl）、CPE 或雜湊值來識別。
• vulnerabilities：每個漏洞一個項目，包含其 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 的五種設定檔

就 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 是三種常見 VEX 格式之一，另外兩種是 OpenVEX 與 CycloneDX VEX。其旗標使用的五種「不受影響」理由與 CISA 的 VEX 要求相同，例如 component_not_present 與 vulnerable_code_not_in_execute_path。Trivy 與 Grype 都能讀取 CSAF VEX，並略過其標示為不受影響的檢測結果。例如 Red Hat 會將其 CSAF VEX 文件發布在 CSAF 資安公告旁的獨立目錄中。

CSAF 資安公告如何發布

標準格式唯有在工具能找到文件時才有幫助。CSAF 2.0 第 7 節規定了做法：

• provider-metadata.json 描述發布者及其資安公告的所在位置。工具 至少可透過以下三種途徑之一找到它：網域 security.txt 中的 CSAF 欄位、 well-known URL /.well-known/csaf/provider-metadata.json，或在網域前加上 csaf.data.security. 的 DNS 名稱。
• 資安公告的列出方式可以是按年份分的資料夾，並附上 index.txt 與 changes.csv，也可以是 ROLIE feed，並透過 TLS 提供且不經重新導向。
• 每個檔案的命名都依據其追蹤 ID。TLP:WHITE 資安公告必須可自由存取， TLP:AMBER 或 TLP:RED 的公告則必須設有存取控制。
• 完整性：trusted provider 會為每份文件附上雜湊值與 OpenPGP 簽章，並公開 其公鑰。

標準定義了發布方可以擔任的五種角色：

角色	職責
CSAF publisher	僅以自身名義，透過 TLS 發布有效的 CSAF 文件
CSAF provider	除了 publisher 的職責外，還提供 provider-metadata.json、探索途徑，以及目錄或 ROLIE feed
CSAF trusted provider	除了 provider 的職責外，還發布雜湊值、OpenPGP 簽章與其公鑰
CSAF lister	維護一份其他方 CSAF 文件所在位置的清單，但不複製文件
CSAF aggregator	將至少兩個獨立發布方的文件鏡像到同一處，並附上雜湊值與簽章

使用方只需設定一次下載工具，就能從其產品所依賴的每個 provider 拉取新的資安公告， 而不必監看數十個廠商網頁。

有哪些組織發布 CSAF

CSAF 最常見於工業、企業與基礎設施廠商，以及國家級 CERT：

• Cisco 在其 well-known CSAF URL 提供 provider-metadata.json。
• Siemens ProductCERT 以 CSAF ROLIE feed 發布其資安公告。
• Red Hat 發布 CSAF 資安公告，並另外發布 CSAF VEX 文件。
• 德國國家級 CERT BSI 的 CERT-Bund 以 CSAF feed 發布其資安公告。
• CISA 於 2023 年 9 月宣布 其 ICS 資安公告附有 CSAF 文件（可回溯至 2017 年），並呼籲廠商採用此標準。

依循 IEC 62443-4-1 的工業供應商需要建立一套流程，向使用者告知 其產品的資安問題，而機器可讀的資安公告是滿足客戶期望的常見方式。

CSAF 工具

• Secvisogram 是 BSI 推出的 CSAF 文件網頁編輯器，提供表單編輯器、JSON 編輯器、 HTML 預覽與驗證功能。
• 由 BSI 與 Intevation 推出的 csaf 工具（gocsaf/csaf，常被稱為 csaf_distribution）實作了 trusted provider、檢查工具、aggregator 與下載工具，CSAF 2.1 版本正在開發中。
• Trivy 與 Grype 等掃描工具可使用 CSAF VEX 文件。

從網頁與 RSS feed 轉移到 CSAF

大多數廠商分五個步驟轉移到 CSAF：整理好產品與版本清單、選擇所需的 CSAF 角色、 發布探索檔案與 feed、以產生取代手寫資安公告，最後加入 VEX 與 歷史公告。轉移到 CSAF 的重點大多不在 JSON，而在於擁有一份資安公告可以指向的產品清單， 以及一條讓機器能找到公告的路徑。

大多數廠商的起點

常見的做法是每則資安公告一個 HTML 頁面，有時附上 PDF，再加上 RSS 或 Atom feed 與郵寄名單。人可以 閱讀，但客戶端的工具能做的事很有限：沒有穩定的產品識別碼、沒有各版本受影響 或不受影響的狀態、無法探索廠商的所有資安公告，也沒有完整性檢查。BSI 描述的也是同樣的問題：要嘛有可訂閱的 RSS feed，要嘛新的資安公告只會出現在 需要有人造訪的網站上。舊做法的每個部分，在 CSAF 中都有對應：

舊有元素	CSAF 對應項目
資安公告網頁	採用 csaf_security_advisory 設定檔的 CSAF 文件
以文字描述的「受影響版本」	product_tree 加上 product_status
RSS feed	ROLIE feed，或附有 index.txt 與 changes.csv 的目錄
「訂閱」頁面	provider-metadata.json 與探索途徑
PDF 簽章，或沒有簽章	雜湊值與 OpenPGP 簽章（trusted provider）
「最後更新」文字	tracking 與 revision_history

RSS feed 是傳遞管道，CSAF 則是格式。FIRST PSIRT Services Framework 將「網頁文件、RSS feed 或訂閱」列為傳遞資安公告的方式，並另外建議以「機器可讀的格式，例如 Common Security Advisory Framework（CSAF）」發布資安公告，讓客戶能以自動化方式使用。 您可以保留 feed。

步驟 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：選擇您的角色

五種角色已在上文說明。對廠商而言，選擇範圍可縮小為三種：

角色	適用時機	增加的內容
CSAF publisher	您只需要在網站上提供有效的 CSAF 文件，作為起點	透過 TLS 提供有效文件；工具無法自行探索
CSAF provider	客戶應能自動擷取您的資安公告：實務上的最低要求	provider-metadata.json、探索途徑，以及目錄或 ROLIE feed
CSAF trusted provider	客戶或主管機關期望收到經簽署的資安公告	雜湊值、OpenPGP 簽章與公開的公鑰

Lister 與 aggregator 適用於協調機構，而非廠商。gocsaf/csaf 工具包含 實作 trusted provider 的 csaf_provider，以及依標準第 7 節測試 provider 設定的 csaf_checker。請在公布 feed 之前執行檢查工具。

步驟 3：探索與 feed

• 發布 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

• 以 ROLIE feed 取代 RSS feed，或兩者並行。ROLIE（Resource-Oriented Lightweight Information Exchange，RFC 8322）以 Atom 為基礎，因此是您現有 feed 的自然接班者。附有 index.txt 與 changes.csv 的目錄也同樣可行。
• 為每個 feed 標示 TLP 等級。CSAF 2.0 使用 TLP 1.0 的 WHITE、GREEN、AMBER 與 RED 標籤。 FIRST 的 TLP 2.0 自 2022 年 8 月起成為正式版本，使用 CLEAR、GREEN、AMBER 與 RED，並以 AMBER+STRICT 作為 AMBER 的延伸，CSAF 2.1 草案也採用了這些 標籤。在 CSAF 2.0 中，公開的資安公告為 TLP:WHITE。

步驟 4：以產生取代手寫

從您為每個漏洞已維護的紀錄（追蹤系統中的案件或 漏洞資料庫）產生新的資安公告，並在發出前依結構描述與標準中的測試逐一驗證。 Secvisogram 適用於少量公告與編輯作業。請用同一份 JSON 文件產生供人閱讀的頁面，讓 網頁與 CSAF 檔案永遠一致。修訂時，在同一份文件中更新 tracking/version 與 revision_history；不需發布新文件。

步驟 5：VEX 與歷史公告

針對客戶最常詢問的 CVE，將不受影響聲明以 CSAF VEX 發布，因為每一則 這樣的聲明都能免去一次重複的詢問。最後再補齊較舊的資安公告，從仍在支援期內的產品開始。若 您的舊資安公告採用 CVRF，規格中的轉換規則也涵蓋了它們。

CSAF 2.0 還是 2.1？

現在就發布 2.0。它是已核准的 OASIS 標準，也已發布為國際標準 ISO/IEC 20153:2025。CSAF 2.1 仍是 Committee Specification Draft： 第四版草案 於 2026 年 10 月 21 日核准，其公開審查已於 2026 年 11 月 6 日結束。工具也正在做準備： Secvisogram 已能編輯 2.1 文件，而 gocsaf/csaf 工具的 2.1 支援則正為其下一個主要版本 開發中。

CRA 與 BSI 的期待

• Cyber Resilience Act（CRA）並未指定 CSAF。第 14 條第 8 項要求 得知遭積極利用漏洞或嚴重資安事件的製造商，告知受影響的 使用者（在適當情況下告知所有使用者），並「在適當情況下採用結構化、機器可讀且易於 自動處理的格式」。附件 I 第 II 部分要求製造商在資安更新推出後，公開揭露已修正 漏洞的相關資訊，並訂定協同漏洞揭露政策。 CSAF 是滿足其中機器可讀要求的方式之一。
• BSI 本身以 CSAF 發布其 CERT-Bund 資安公告。其技術指引 TR-03183-3（Vulnerability Reports and Notifications，v1.0.0，2025 年 8 月）將「在製造商網站上以 CSAF 發布」列為發布資安公告的 建議方式（第 3.1.5 節）。它要求提供 security.txt 檔案（第 4.2 節），並指出 製造商應將其 provider-metadata.json 以 CSAF: 欄位列在其中（第 4.2.8 節）。技術指引屬於指導性文件，而非法律。
• ENISA 的 Single Reporting Platform 用於依 CRA 向主管機關通報，而非向使用者發布 資安公告。發布 CSAF 資安公告不能取代通報，而通報也不會 告知您的使用者。

最小可行的 CSAF 設定

• 產品與版本清單，並盡可能附上 CPE 或 package URL 識別碼
• 發布者中繼資料：名稱、類別、命名空間與聯絡資訊
• 第一份採用 csaf_security_advisory 設定檔的資安公告
• 依結構描述與標準中的測試進行驗證
• provider-metadata.json，放在 /.well-known/csaf/
• security.txt 中的 CSAF: 行
• ROLIE feed，或附有 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，他們的掃描工具也不會再標示這些產品。
• 更新，而非取代。每個問題維持一則資安公告，並在修正推出時新增修訂。
• 在約定的日期發布。資安公告是 協同漏洞揭露（CVD）的終點，在修正 推出且已告知通報者後發布。

資安公告之前的步驟，從受理、分級研判到修正，請參閱 漏洞管理生命週期，負責這項 工作的人員則請參閱 PSIRT 角色。

困難之處在於掌握哪些受到影響

每一則資安公告，無論是否採用 CSAF 或其他格式，都取決於一個答案：哪些產品與版本包含 有漏洞的元件。對於以開源套件建置的軟體，這代表必須確切知道每個版本中放入了哪些相依套件 版本，包括遞移相依套件。

CRACI 不撰寫也不發布資安公告。它提供的是資安公告中產品狀態所依據的紀錄。 CRACI 在自己的執行器上執行 GitHub Actions 建置，並記錄每個作業實際擷取的套件，包括 遞移相依套件、從快取還原的套件，以及任何 lockfile 都未列出的相依套件。當新的漏洞 公布時，受監控的 SBOM 會重新評估，而建置歷程會顯示過去哪些建置與版本包含 該有漏洞的相依套件（無論直接或遞移），以及從何時開始包含。資產清冊檢視會顯示哪些版本 部署到哪些產品上，而分級研判會將每項檢測結果分派給負責修正的團隊。SBOM 可匯出為 CycloneDX 或 SPDX，且 CRACI 支援 VEX。請參閱 漏洞追蹤。

CSAF：常見問題

CSAF 是什麼的縮寫？

在資安領域，CSAF 是 Common Security Advisory Framework（通用資安公告框架）的縮寫。這是一項 OASIS 標準，用於將資安公告撰寫成機器可讀的 JSON 文件並加以發布，讓工具能自動找到並處理。

CSAF 目前的版本是什麼？

CSAF 2.0，於 2022 年 11 月 18 日核准為 OASIS 標準，並已發布為 ISO/IEC 20153:2025。CSAF 2.1 仍在制定中：其第四版 Committee Specification Draft 於 2026 年 10 月 21 日核准，並於 2026 年 11 月 6 日完成公開審查。它尚未成為核准的 OASIS 標準。

CSAF 與 CVE 有什麼不同？

CVE 紀錄用於識別單一漏洞，並以一般性的方式加以描述。CSAF 資安公告則由廠商或協調機構發布，說明該漏洞（通常還包括其他幾個漏洞）如何影響特定產品與版本，以及應採取哪些措施。CSAF 資安公告會引用 CVE ID。

什麼是 CSAF VEX？

CSAF VEX 是 CSAF 的 csaf_vex 設定檔，用於承載 VEX 聲明：針對每項產品說明其是否受影響、不受影響、已修正或調查中，並為不受影響的產品附上影響聲明，為受影響的產品附上修補措施。Trivy 與 Grype 可讀取它來抑制檢測結果。

什麼是 CSAF provider？

CSAF provider 是以工具可探索的方式發布自身 CSAF 文件的組織：提供一個 provider-metadata.json 檔案（可透過 security.txt、well-known URL 或 DNS 名稱找到），以及資安公告的目錄或 ROLIE feed。Trusted provider 則另外提供雜湊值、OpenPGP 簽章與公開的公鑰。

CSAF 取代了什麼？

取代了 XML 格式的 Common Vulnerability Reporting Framework（CVRF）。CVRF 1.1 由 ICASI 於 2012 年發布，CVRF 1.2 則由 OASIS 於 2017 年發布。CSAF 2.0 改用 JSON，並新增了設定檔、產品樹與發布規則。

如何撰寫 CSAF 資安公告？

大多數團隊會從編輯器著手，例如 BSI 為 CSAF 提供的網頁編輯器 Secvisogram，或從自己的漏洞追蹤資料產生 JSON。選擇一個設定檔（通常是 csaf_security_advisory），填入發布者、追蹤資料、產品樹與漏洞，依結構描述驗證後，再透過 provider 發布。

如何將我們的資安公告從網頁轉移到 CSAF？

先建立一份權威的產品與版本清單，再成為 CSAF provider：發布 provider-metadata.json，從 security.txt 指向它，並在 ROLIE feed 或目錄中列出資安公告。從您的漏洞紀錄產生新的資安公告，用同一份 JSON 產生網頁，最後再補齊舊的資安公告。

發布 CSAF 後，還能保留 RSS feed 嗎？

可以。RSS feed 是傳遞管道，CSAF 則是格式，兩者可以並存。若您希望用同一個 feed 同時服務人與機器，ROLIE feed 是以 Atom 為基礎，可以取代 RSS feed。請從同一份資安公告資料產生兩者，確保內容永遠一致。

我們需要哪一種 CSAF 角色：publisher、provider 還是 trusted provider？

大多數廠商需要成為 CSAF provider：提供有效的文件、provider-metadata.json、探索途徑，以及目錄或 ROLIE feed，讓客戶能自動擷取資安公告。單純的 publisher 只是起點，工具無法自動探索。當客戶或主管機關期望收到經簽署的資安公告時，請成為具備雜湊值、OpenPGP 簽章與公鑰的 trusted provider。

Cyber Resilience Act 要求使用 CSAF 嗎？

不要求。CRA 並未指定格式。第 14 條第 8 項要求製造商將遭積極利用的漏洞或嚴重資安事件告知受影響的使用者，並在適當情況下採用結構化、機器可讀且易於自動處理的格式。CSAF 是滿足此要求的方式之一，也是 BSI 建議的格式。

BSI 對製造商在 CSAF 方面有什麼期待？

BSI TR-03183-3 是技術指引而非法律，它將「在製造商網站上以 CSAF 發布」列為發布資安公告的建議方式。它要求提供 security.txt 檔案，並指出製造商應將其 provider-metadata.json 以 CSAF: 欄位列在其中。BSI 本身也以 CSAF 發布其 CERT-Bund 資安公告。

我們應該發布 CSAF 2.0，還是等待 2.1？

現在就發布 2.0。它是已核准的 OASIS 標準，也是 ISO/IEC 20153:2025，而且工具都支援它。CSAF 2.1 仍是 Committee Specification Draft，其第四版草案於 2026 年 10 月與 11 月接受審查。日後改用 2.1 只需更新您的工具，不構成等待的理由。