研發長要建的漏洞流程，29147 和 30111 各管哪一段？
| 標準 | 管什麼 | 典型產出 |
|---|---|---|
| ISO/IEC 29147（漏洞揭露） | 對外：通報受理、與通報者溝通、公告發布 | 通報窗口與 security.txt、協調揭露政策、公告範本 |
| ISO/IEC 30111（漏洞處理） | 對內：驗證、分級、根因分析、修補與發布 | 處理流程、分級準則、處理紀錄與時限 |
兩份標準條文互相引用、流程互相銜接，分開導入會在交接處留下稽核缺口，所以建議成對建立。現行有效版本是 ISO/IEC 29147:2018 與 ISO/IEC 30111:2019；修訂已在 ISO/IEC JTC 1/SC 27 立案，新版尚未發布。
EU CRA 對研發的漏洞處理有哪些硬要求與時限？
CRA 附件 I 第二部分要求製造商：
- 以通用、機器可讀格式製作至少涵蓋頂層相依性的 SBOM（第 (1) 點）；
- 「無延遲」處理並修補漏洞，技術可行時安全更新與功能更新分開提供（第 (2) 點）；
- 建立並執行協調式漏洞揭露（CVD）政策（第 (5) 點），提供漏洞通報聯絡地址（第 (6) 點）；
- 安全更新可用時「無延遲」散布，除客製化產品另有約定外免費提供（第 (8) 點）。
第 14 條通報：知悉主動遭利用的漏洞後，經 ENISA 單一通報平台同時送交被指定為協調者的 CSIRT 與 ENISA，24 小時內早期預警、72 小時內通報、矯正或緩解措施可用後 14 天內最終報告。自 2026 年 9 月 11 日起適用，也及於 2027 年 12 月 11 日前已上市的產品。
收到漏洞通報後，研發內部的處理關卡怎麼設計？
核心是把「誰收單、誰驗證、誰定級、誰修、誰發布、多快」寫成可稽核的流程與時限：
| 關卡 | 要決定的事 | 常見缺口 |
|---|---|---|
| 受理與驗證 | 通報是否成立、能否重現、影響哪些產品與版本 | 沒有產品與元件清單，無法判斷影響範圍 |
| 分級 | 依什麼準則定嚴重度與處理時限 | 分級準則只寫在個人經驗裡 |
| 修補 | 修補、繞道措施與測試由誰負責 | 舊版本與停產型號沒人負責 |
| 發布 | 安全更新怎麼送到使用者手上、公告何時發布 | 安全更新與功能更新綁在一起 |
| 檢討 | 根因分析與流程改善 | 同類漏洞重複發生 |
分級準則可依產品情境在地化（例如 CVSS 在地化準則）；多產品線廠商另需設計橫向的漏洞影響範圍評估機制。
SBOM、定期測試與安全更新派送，29147 和 30111 沒涵蓋怎麼辦？
依歐盟聯合研究中心（JRC）與 ENISA 2024 年的對映分析：
- 30111 對應附件 I 第二部分第 2、4、5、6、8 點；
- 29147 對應第 2、4、5、6 點；
- SBOM（第 1 點）、定期測試與審查（第 3 點）、更新安全派送（第 7 點） 沒有對應到這兩份標準，要以其他標準或程序補齊。
該報告是分析文件、不是調和標準，不產生符合性推定；也指出沒有任何單一標準能完整涵蓋所有面向。研發長要在工具鏈與發布流程補上三件事：產品版本對應的 SBOM、定期資安測試，以及安全更新的派送機制。30111 的修補流程必須接上 SBOM（知道產品裡有什麼，才知道哪個元件的漏洞與您有關）與安全更新交付機制（修了要能送到用戶手上）。
舊版本、停產型號與已上市產品，支援期內也要處理漏洞嗎？
要。CRA 要求製造商自產品上市起、在整個支援期間依附件 I 第二部分有效處理漏洞（第 13 條第 8 項）：
- 支援期：至少 5 年（產品預期使用時間較短者依其預期使用時間），結束日（至少含年、月）須在購買時清楚標示（第 13 條第 19 項）。
- 安全更新保留：支援期內發布的每項安全更新，至少保留 10 年或至支援期結束，以較長者為準（第 13 條第 9 項）。
- 已上市產品：第 14 條通報義務也及於 2027 年 12 月 11 日前已上市的產品（第 69 條第 3 項）。
對研發長的意義：舊版本的修補與測試要有明確負責人，版本分支與建置環境要能在支援期內重現。
工程人力：小公司需要 PSIRT 嗎？已有事件應變程序夠嗎？
不需要大編制，但需要明確的接收管道、責任人與回覆流程；29147 的最低要求本就考量規模彈性，制度可以精實但不能缺席。
已有資安事件處理程序是好基礎，但不等於漏洞處理：事件處理（ISO/IEC 27035）處理「已發生的攻擊」，漏洞處理（30111）處理「被回報的弱點」，兩者的觸發來源、時限與產出不同，CRA 稽核的是漏洞專屬流程與證據。30111 流程要與既有事件應變（27035）、供應商管理（27036）銜接。已有 ISO 27001 的組織，可以把 CVD 流程掛載於既有 ISMS，文件與稽核機制共用。
積穗科研怎麼協助研發長處理 ISO/IEC 29147 與 30111？
由副總、董事級顧問全程親自輔導、不外包，29147 與 30111 成對導入。服務頁所列交付：
- 29147 揭露端：security.txt 與通報信箱或表單、通報受理與回覆時限、含安全港聲明的協調式漏洞揭露政策、公告範本與發布流程，必要時的 CVE 編號申請程序。
- 30111 處理端：漏洞處理政策與流程文件、分級準則、處理紀錄與時限報表機制、SBOM 銜接程序、與 29147 揭露端的介接文件，全部以可被公告機構與客戶稽核為標準。
- 實作經驗：積穗科研自身交付管線每日產製、簽章並監測 SBOM，這套機制是輔導內容的活教材。
服務頁未列導入月數。
深入：ISO/IEC 29147 漏洞揭露導入輔導、ISO/IEC 30111 漏洞處理流程導入輔導、29147 顧問怎麼選、研發長要放進研發流程的要求。申請免費機制診斷
其他角色怎麼看這項服務
同一角色的其他服務
- 研發長因應 EU CRA：開發流程、SBOM 與上市時程要改什麼？
- 研發長導入 IEC 62443-4-1：安全開發流程要改什麼、要多久？
- 研發長導入 ISO/SAE 21434：TARA 怎麼掛進既有開發流程？
- 研發長面對 ISO 42001 與 EU AI Act：AI 產品要準備什麼？
- 研發長導入 ISO 27701 與 GDPR：產品與系統的隱私設計怎麼做？
- 研發長做營業秘密保護：研發資料怎麼分級、要留哪些紀錄？
- 研發長導入 ISO 56001：創新專案怎麼試行、ESG 怎麼加分？
- 研發長面對 TISAX 原型保護：ISA2027 改了什麼、要準備什麼？
- 研發長推動數位轉型：導入 ERP、MES、IoT 時資安怎麼同步？
- 研發長推動 AI 轉型：第一個場景怎麼選、治理要先建什麼？