產品經理為什麼要管漏洞揭露與處理？CRA 要的是什麼結果？
CRA 的漏洞義務綁在產品上，持續整個支援期。附件 I 第二部分列出八項漏洞處理要求；依歐盟 JRC 與 ENISA 2024 年的對映分析：
| 標準 | 對應附件 I 第二部分 |
|---|---|
| ISO/IEC 29147 | 八項中的四項（第 2、4、5、6 點） |
| ISO/IEC 30111 | 八項中的五項（第 2、4、5、6、8 點） |
SBOM（第 1 點）、定期測試與審查（第 3 點）、更新安全派送（第 7 點）沒有對應到這兩份標準，要以其他標準或程序補齊。該報告為分析文件，並非調和標準，不產生符合性推定。
對外要公布什麼？客戶和研究人員怎麼找到我們的通報窗口？
29147 的典型交付，就是產品對外的漏洞窗口：
- security.txt 與通報信箱或表單
- 通報受理與回覆 SLA
- CVD 政策文件（含安全港聲明）
- 公告模板與發布流程，必要時的 CVE 編號申請程序
CRA 也要求提供漏洞通報聯絡地址（附件 I 第二部分第 6 點），並指定單一聯絡窗口（第 13 條第 17 項）。這些資訊會寫進產品文件與官網，產品經理要確認窗口有負責人、回覆時限做得到。
修補與安全更新怎麼排進產品版本與出貨節奏？
30111 把收到通報後的處理拆成五個關卡，每一關都要有負責人與時限：
| 關卡 | 要決定的事 |
|---|---|
| 受理與驗證 | 通報是否成立、能否重現、影響哪些產品與版本 |
| 分級 | 依什麼準則定嚴重度與處理時限 |
| 修補 | 修補、繞道措施與測試由誰負責 |
| 發布 | 安全更新怎麼送到使用者手上、公告何時發布 |
| 檢討 | 根因分析與流程改善 |
CRA 要求無延遲修補，技術可行時安全更新與功能更新分開提供。常見缺口是兩者綁在一起，以及沒有產品與元件清單、無法判斷影響範圍。
支援期內的舊型號與停產型號，也要處理漏洞嗎？
要。CRA 要求製造商自產品上市起、在整個支援期間依附件 I 第二部分有效處理漏洞（第 13 條第 8 項）：
- 支援期至少五年，預期使用時間少於五年者依其預期使用時間
- 支援期結束日（至少含年、月）須於購買時清楚標示（第 13 條第 19 項）
- 支援期內發布的每項安全更新，至少保留 10 年或至支援期結束，以較長者為準（第 13 條第 9 項）
- 安全更新除客製化產品另有約定外應免費提供
「舊版本與停產型號沒人負責」是修補關卡的常見缺口，產品停產計畫要指定支援期內的負責人。
CRA 的通報時限會不會打亂產品上市後的維護？
第 14 條通報義務自 2026 年 9 月 11 日起適用，也及於 2027 年 12 月 11 日前已上市的產品：
- 主動遭利用的漏洞：知悉後 24 小時內早期預警、72 小時內通報、矯正或緩解措施可用後 14 天內最終報告
- 對產品安全有影響的嚴重事件：24 小時內早期預警、72 小時內通報、事件通報後一個月內最終報告
通報經 ENISA 單一通報平台提交。已有資安事件處理程序是好基礎，但事件處理針對已發生的攻擊，漏洞處理針對被通報的弱點，觸發來源、時限與產出不同，仍要有漏洞專屬的流程與紀錄。
小公司也要 PSIRT 嗎？做到什麼程度才交得出證據？
不需要大編制，但需要明確的接收管道、責任人與回覆流程。導入產出以可被公告機構與客戶稽核為標準：
- 漏洞處理政策與流程文件
- 分級準則（如 CVSS 本地化準則）
- 處理紀錄與 SLA 報表機制
- SBOM 銜接程序
- 與 29147 揭露端的介接文件
現行有效版本是 ISO/IEC 29147:2018 與 ISO/IEC 30111:2019；修訂已在 ISO/IEC JTC 1/SC 27 立案，新版尚未發布。
積穗科研怎麼協助產品經理處理 ISO/IEC 29147 與 30111？
積穗科研把 29147 與 30111 成對導入，避免交接面留下稽核缺口：
- 建立 security.txt、通報信箱或表單、受理與回覆時限、CVD 政策與公告流程
- 把「誰收單、誰驗證、誰定級、誰修、誰發布、多快」寫成可稽核的流程與 SLA
- 多產品線廠商設計漏洞影響面評估的橫向機制
- 已有 ISO 27001 者，把 CVD 流程掛載於既有 ISMS，文件與稽核機制共用
積穗科研自身交付管線每日產製、簽章並監測 SBOM；由副總、董事級顧問全程親自輔導、不外包。延伸：ISO/IEC 29147、ISO/IEC 30111、29147 顧問怎麼選、30111 顧問怎麼選。申請免費機制診斷