面對不斷增加的詢問量，您無法靠增聘人力解決，也無法永遠持續加快分級研判的速度。PSIRT 要能擴展，靠的是根據每個版本建置時記錄的資料回答大多數「我們受影響嗎？」的問題，並在客戶詢問之前就發布答案。如今成本最高的步驟，是詢問工程團隊產品裡有什麼。把這個步驟移到建置時，大多數詢問就會變成客服可以自行結案的查詢。

本文假設您已經在營運 PSIRT；如果您正要成立 PSIRT，請先閱讀什麼是 PSIRT 以及如何建立。以下內容包括：詢問量為何改變、一般流程中時間耗在哪裡，以及應該依序改變什麼。

詢問量為何改變

這波增加是結構性的，而不是某一季運氣不好。有四股力量同時壓在同一個佇列上。

CVE 變多了。 CVE Program 在 2024 年發布了 39,718 筆 CVE 紀錄，2025 年則為 47,801 筆。2026 年的數量在年底前很早就超過了 2025 年的全年總數；我們的即時 CVE 發布趨勢逐日追蹤這項數據。FIRST 的 2026 年漏洞預測更新（2026 年 6 月 15 日）將該年的估計值上調至約 66,000 個 CVE，並直接點出原因：AI 能找到的缺陷遠多於人類分析師，而且「限制不再是發現，而是人類驗證、協調與修補的能力」。PSIRT 正是這份人類能力。

客戶會掃描您的產品。 客戶會對您的映像檔、韌體與設備執行掃描器，並把每一項發現都當成工單轉寄過來。這些發現大多是掃描器雜訊，涉及您沒有交付的元件，或未受影響的版本，而這些雜訊就成了您的受理量。減少漏洞雜訊說明了掃描器這一端的做法。

法規加上了時限。 自 2026 年 9 月 11 日起，歐盟 Cyber Resilience Act（CRA）的通報義務開始適用。在歐盟銷售的產品中若有遭積極利用的漏洞，製造商必須在知悉後 24 小時內發出早期預警。

NVD 的協助變少了。 2026 年 4 月 15 日，NIST 將國家漏洞資料庫（NVD）改為以風險為基礎的資料補充：CISA KEV 目錄中的 CVE、聯邦政府使用的軟體與 EO 14028 關鍵軟體優先處理，其餘則標示為「Lowest Priority - not scheduled for immediate enrichment」。附帶 CPE 資料的 CVE 變少，因此在數量增加的同時，依產品名稱比對的效果也變差了。

驅動因素對 PSIRT 佇列的影響
CVE 數量、AI 輔助的發現每個產品每月需要評估的第三方 CVE 變多
客戶掃描每個 CVE 的詢問變多，其中許多涉及您沒有交付的元件
CRA 通報遭積極利用的漏洞有 24 小時的時限
NVD 資料補充減少將 CVE 對應到受影響產品的人工作業變多

時間耗在哪裡：一般的詢問處理流程

我們一再從產品資安團隊聽到相同的流程。一家硬體廠商的兩人 PSIRT 是這樣向我們描述的：客戶詢問客服台，客服透過 CRM 將問題轉給 PSIRT，案件進入 PSIRT 的追蹤系統，PSIRT 調查客戶最常詢問的產品，接著把問題交給工程團隊，然後等待。

一般的客戶詢問處理流程：客戶、客服、CRM 案件、PSIRT 追蹤系統、PSIRT 調查、詢問工程團隊、等待、回覆，以及每次交接會遺失的資訊

舉一個示意性的詢問為例。客戶轉寄了一份掃描器報告，列出韌體版本 X 的 40 個 CVE。客服開立案件並附上報告，卻沒有附上客戶實際執行的確切建置。PSIRT 檢查這 40 個中哪些已經評估過，發現有十幾個尚未評估，於是詢問負責的工程團隊這些元件是否在版本 X 中。工程團隊必須找出版本 X 的原始碼、釐清其中放入了哪些相依套件版本，然後回覆。這些數字是虛構的，但情況的樣貌是真實的。

真正耗時的很少是分析本身。兩項隱藏成本是：

  1. 每有一位客戶詢問，同一個 CVE 就要重新調查一次。 當答案存在於電子郵件討論串中時，下一位客戶詢問時，調查就得從頭開始。
  2. 「最常被問到的產品優先」會讓長尾問題一直沒有答案。 仍在現場使用的舊產品永遠不會被檢查，而風險往往就在那裡：元件較舊、更新較少，記得它們如何建置的人也較少。

受理：將詢問與通報分開

研究人員的漏洞通報與客戶的「我們受影響嗎？」是不同的工作，需要不同的處理途徑。FIRST PSIRT Services Framework 早已預期輸入會很雜亂：PSIRT 應「預期會透過各種管道收到品質不一的漏洞」（子功能 2.1.1.1）。其分級研判服務領域更進一步指出：「收到大量漏洞通報的組織，可考慮在建立案件前先進行初步分級研判以驗證通報。」請將此視為不必為每一則詢問都開立 PSIRT 案件的許可。

在客服台將詢問分成三條途徑：

客戶詢問的內容途徑由誰回答
您已評估過的第三方元件中已發布的 CVE依據已發布的 VEX 聲明或資安公告回答；不開立 PSIRT 案件客服
您尚未評估的已發布 CVE每個 CVE 開立一件 PSIRT 案件，而不是每位客戶一件；將每則詢問都連結到該案件PSIRT，之後由客服回覆所有已連結的客戶
您自己程式碼中的新漏洞視為漏洞通報：走完整的協同漏洞揭露（CVD）流程PSIRT

客服需要兩樣東西才能處理第一條途徑：一份可依產品與版本搜尋的已評估 CVE 清單，以及回覆範本。供應鏈攻擊後如何回覆客戶提供了可供您調整使用的範本。

在受理時就記下客戶執行的產品與確切版本。沒有版本，每個答案都只能是「看情況」，案件也會再度被退回。

依暴露程度排定優先順序，而不只看熱門程度

「最常被問到的產品優先」是合理的經驗法則，但它需要第二個面向。保留熱門程度（安裝基數、營收、客服詢問頻率），再加上暴露程度：產品是否仍在支援期內、在典型部署中是否面向網際網路，以及該 CVE 是否列在 CISA 的 KEV 目錄中，或 EPSS 分數很高？漏洞優先排序指南深入說明了這些訊號。

低暴露高暴露
安裝基數高依資產清冊回答；為未受影響的版本發布 VEX優先調查；以最短期限發布資安公告與修正
安裝基數低有人詢問時依資產清冊回答；不主動處理不要略過：依資產清冊回答，再決定要修正或發布緩解措施通知

這個矩陣的重點在於左欄與下列。長尾問題透過資料得到答案，而不是靠一場沒有人有時間進行的調查。

在 CRA 之下，您為每項產品宣告的支援期間，決定了您仍需為哪些舊產品提供答案與安全性更新（CRA 的要求）。

工程交接是瓶頸

本節寫給接收 PSIRT 升級案件的工程主管。

PSIRT 的期限是公開的：客戶、主管機關或揭露日期都在等待。工程團隊的期限通常不是，因此由 PSIRT 承擔其中的落差。一個在週一交出的重大問題，若到週二仍未回覆，距離公開答覆的期限就只剩兩天。

PSIRT 會向工程團隊提出兩種不同的問題，其中只有一種應該需要工程團隊：

  • 「元件在產品裡嗎？」 是資料問題。它應該由紀錄回答，而不是由人去閱讀建置檔案。
  • 「您能在 X 日前修正嗎？」 是工作問題。這個問題才屬於工程團隊。

FIRST 框架說明了如何讓第一個問題不再落到工程團隊身上。功能 2.3.5 要求 PSIRT「建立自動化管道，將已識別的第三方漏洞通知直接發送給受影響產品的開發團隊」，讓第三方資安公告在開發流程中處理，PSIRT 需要手動處理的數量也隨之減少。

一個重大 CVE 的示意時間軸，公開答覆期限為第 5 天：工程調查佔去大部分時間，而查詢則能把整段時間留給修正與資安公告

與工程團隊約定三件事：

  1. 每項產品一位負責人。 在大型廠商中，修補工作分散在各產品團隊；框架之所以有分散式模型，正是因為它能讓 PSIRT 的任務透過負責產品的工程師擴展。
  2. 依嚴重程度訂定的回應目標，以書面記錄，針對的是修正而不是調查。
  3. 未達目標時該怎麼辦。 功能 4.2.4 要求「針對未在內部 SLA 時限內修補的任何漏洞，建立正式的風險接受流程」。由有權限的人簽署接受該風險，而不是讓它一直懸而未決。

修正的節奏各不相同。有的團隊一夜之間就推出修補程式，有的則需要六個月的平台升級。資安公告必須說明是哪一種，讓客戶能夠規劃。

將「我們受影響嗎？」變成查詢：為每個已交付版本保留 SBOM

這是能省下最多工作的改變。FIRST 功能 2.3.1（產品元件資產清冊）稱其為「快速識別受繼承漏洞影響之產品的關鍵」。PSIRT 成熟度等級將具備相依性對應的產品登錄列為中級，將產品元件漏洞監控列為進階。

資產清冊只有在面對大量詢問時仍站得住腳，才能真正減少工作。以下每項要求都有其理由：

  • 每個已交付版本一份 SBOM，而不是每個儲存庫一份，也不是預設分支的 SBOM。客戶執行的是版本，而不是分支。
  • 取自產生該版本的建置。 日後重新建置，或掃描今天的儲存庫，描述的都是不同的軟體（建置時 SBOM）。
  • 包含遞移與隱藏的相依套件。 有漏洞的套件很少是您自己加入的（遞移相依套件），而安裝腳本、基礎映像檔與還原的快取會引入任何 lockfile 都沒有列出的元件。
  • 完整性訊號。 把不完整的紀錄當成完整紀錄，會產生自信滿滿卻錯誤的「未受影響」答案。
  • 在版本的支援期間內持續保存。 三年前某個版本的紀錄，正是在沒有人記得它如何建置時您會需要的那一份。
  • 外購元件的廠商 SBOM，讓第三方軟體與您自己的軟體位於同一份資產清冊中。
  • 持續重新比對新發布的 CVE，而不是在有人詢問時才重新掃描。

舉個實際例子。某個廣泛使用的壓縮函式庫發布了新的 CVE。沒有資產清冊時，PSIRT 要詢問每個產品團隊，答案在幾天內陸續回來，而最舊的產品永遠不會被檢查。有了資產清冊，一次查詢就能回傳受影響的產品與版本，以及包含該漏洞版本的第一個與最後一個建置。這就是客戶接下來會詢問的暴露期間；我們受 CVE 影響嗎？說明了如何針對單一案例確認這段期間。

嵌入式與 Yocto 產品組合的處境最艱難。讀取完成之韌體映像檔的掃描器，必須猜測其中編譯了什麼，而與我們交談過的團隊，就曾遇過掃描器的概念驗證在 Yocto 產品上失敗。在建置執行時就加以記錄，可以避免這種猜測（在 CRACI 上進行 Yocto 建置）。

當客戶接著以特定格式索取 SBOM 本身時，請參閱回覆客戶的 SBOM 請求。

輸出端：在有人詢問前就提供答案的資安公告與 VEX

成本最低的詢問，是從來不會出現的詢問。

  • 以 VEX 發布「未受影響」，讓客戶的掃描器不再標示該 CVE；並以資安公告發布「受影響」與「已修正」，附上確切版本。
  • 使其可供機器讀取。 FIRST 子功能 5.3.2.3 建議 PSIRT「考慮以 Common Security Advisory Framework（CSAF）等機器可讀格式發布資安公告」，讓客戶能用自己的工具取用。CSAF 指南說明了如何從網頁與 RSS feed 轉換到 CSAF。
  • 發布前先向客服簡報。 功能 5.3.4：「針對即將發布的資安公告，事先提供機密通知與常見問題，能讓發布時可能被詢問的人做好準備。」如此一來，客服就能在當天回答。
  • 主動推送，而不只是張貼。 子功能 5.4.1.3 指出，資安公告的網頁瀏覽量偏低，「可能促使您的策略轉向主動通知」。Feed 與通知能觸及從不造訪資安公告頁面的客戶。

CRA 將其中一部分列為義務。第 14 條第 8 項要求製造商在知悉遭積極利用的漏洞或嚴重資安事件後，通知受影響的使用者，「並在適當時通知所有使用者」，且「在適當時以結構化、機器可讀、易於自動處理的格式」進行。該法規並未指定格式。

目標流程：每次版本建置都記錄 SBOM，新的 CVE 會與每個受支援的版本比對，PSIRT 對每個 CVE 只做一次判定，發布 VEX 與資安公告，客服以查詢回答，工程團隊只需負責修正

依序該自動化的項目

每個步驟都會減少一種工作；指標則顯示它是否真的做到了。

步驟減少的工作顯示成效的指標
1. 從建置取得依版本區分的資產清冊向工程團隊詢問「裡面有什麼？」每月的工程調查請求數下降
2. 持續將新的 CVE 與每個受支援的版本比對應要求重新掃描從 CVE 發布到做出受影響或未受影響判定的時間
3. 每個 CVE 一件案件，並連結相關詢問重複的調查每件案件的詢問數上升，每個 CVE 的案件數維持一件
4. 自動將受影響的發現項目指派給負責團隊（FIRST 2.3.5）人工交接從做出判定到負責人確認的時間
5. 可搜尋的已發布 VEX 聲明與資安公告資料庫PSIRT 參與重複的問題由客服結案的詢問比例
6. 以機器可讀格式發布（CSAF）客戶詢問其工具原本就能取得的資訊每則已發布資安公告的詢問數下降
7. 以 AI 協助草擬資安公告與回覆撰寫時間從做出判定到發布資安公告的時間

AI 排在最後是有原因的。它在已記錄的資料之上能寫出好的草稿，但它絕不應該成為「受影響」判定的來源。

有些事不應該自動化：「未受影響」的判斷與嚴重程度的判定，仍應由人負責，並附上佐證資料。自動化決定的是這個人多快能取得佐證資料。

顯示 PSIRT 正在擴展的指標

  • 不需開立 PSIRT 案件即可回答的詢問比例。
  • 每項產品從 CVE 發布到做出受影響或未受影響判定的時間。
  • 每月的工程調查請求數。這個數字應該下降。
  • 依嚴重程度區分的準時修補率；框架的子功能 4.4.2.4 將其定義為產品團隊達成從通報到修正之約定時間的程度。
  • VEX 與資安公告對您仍在支援之版本的涵蓋率。

我們不引用這些指標的產業基準。我們信任的第一手來源中，沒有任何一個發布過這類基準。

CRACI 的角色

對於在 GitHub Actions 中建置的軟體，CRACI 涵蓋步驟 1 與 2，以及步驟 4 與 5 的部分內容。您的建置在 CRACI 的執行器上執行，CRACI 會在每個作業執行時記錄它實際引入的內容：直接與遞移相依套件、由腳本安裝的套件，以及從 CI 快取還原的套件。每個作業的 SBOM 都帶有完整性狀態，因此不完整的紀錄絕不會被誤認為完整紀錄。

CRACI 會保留建置歷程，因此當新的 CVE 發布時，您可以在保存期限允許的範圍內，看到哪些建置包含有漏洞的相依套件，以及從何時開始。受監控的 SBOM 會持續重新評估，發現項目會彙整各個建置與儲存庫的結果，您也可以加入廠商 SBOM，讓外購元件與您自己的建置一起受到監控。CRACI 會將新漏洞及其嚴重程度通知相關人員。資產清冊檢視會顯示哪些軟體版本部署到了哪些產品，資安團隊則可在 CRACI 中研判每個發現項目，並將其指派給負責修正的團隊。CRACI 支援 VEX。請參閱適用於 PSIRT 的 CRACI 與漏洞追蹤。

查看您已交付的哪些版本包含某個 CVE。

CRACI 不適合的情況

  • 您的瓶頸在於受理與案件管理，也就是從 CRM 到追蹤系統的那一段。CRACI 不是案件管理或資安公告發布工具；這一半的工作需要案件管理工具（PSIRT 工具比較）。
  • 您的產品不是在 Linux 執行器上以 GitHub Actions 建置。 目前支援的 CI 是 GitHub Actions；GitLab CI 與 Jenkins 已列入產品藍圖，但尚無時程。
  • 您需要對非自行建置的產品進行二進位或韌體分析。 這是輸出分析工具的工作（嵌入式資安工具比較）。
  • 您需要可達性分析來論證「未受影響」。 CRACI 不提供這項功能。

常見問題

如何在不增聘人力的情況下擴展 PSIRT？

停止反覆調查同一個問題。在每個已交付版本建置時記錄其內容，持續將新的 CVE 與其比對，每個 CVE 只做一次判定，並將判定以 VEX 或資安公告的形式發布，讓客服可以引用。如此一來，PSIRT 處理的是真正懸而未決的案件，而工程團隊被要求的是修正，而不是調查。

PSIRT 應如何處理客戶「我們受影響嗎？」的詢問？

將它們視為與漏洞通報分開的受理管道。對於您已評估過的 CVE，由客服依據已發布的資料回答。尚未評估的 CVE 則開立一件 PSIRT 案件，並將每則客戶詢問都連結到該案件。只有您自己程式碼中的新漏洞，才需要走完整的揭露流程。

FIRST PSIRT Services Framework 對詢問量與自動化有什麼看法？

它預期會收到「透過各種管道收到品質不一」的通報，允許在詢問量高時於建立案件前先進行分級研判，稱產品元件資產清冊是「快速識別受影響產品的關鍵」，並要求建立自動化管道，將第三方漏洞通知直接發送給受影響產品的開發團隊（功能 2.3.5）。

PSIRT 應該優先自動化什麼？

從建置取得依版本區分的資產清冊，接著持續將新的 CVE 與每個受支援的版本比對。這兩項能省下最多重複的工作：向工程團隊詢問「裡面有什麼？」，以及應要求重新掃描。案件去重、指派、可搜尋的 VEX 與資安公告資料庫，以及 CSAF 發布，則在其後。

如何讓工程團隊準時回答 PSIRT 的問題？

少問工程團隊問題。以建置紀錄回答「元件在產品裡嗎？」，只把「您能在這個日期前修正嗎？」交給工程團隊。約定每項產品一位負責人、依嚴重程度訂定的修正回應目標，以及未達目標時的正式風險接受流程。

為何每個版本一份 SBOM 對 PSIRT 很重要？

客戶執行的是特定版本，而且往往是舊版本。預設分支的 SBOM 無法說明兩年前的版本 X 有什麼。每個已交付版本一份 SBOM，從產生該版本的建置記錄，並在支援期間內保存，才能讓 PSIRT 為每個仍在現場使用的版本提供答案，包括暴露期間。

客戶想要的是 VEX 還是資安公告？

兩者都要，用於不同的狀態。VEX 告訴客戶的掃描器哪些 CVE 不影響產品，讓這些發現項目不再出現。資安公告則告訴人們哪些受影響、哪些已修正，以及該怎麼做。兩者都發布，並盡可能採用機器可讀格式，就能在大多數問題被提出之前先給出答案。