【產品資安實務經驗：威聯通】主動公開與修補CVE弱點，再以漏洞懸賞與安全設計鞏固防線

談到產品安全與漏洞因應，國內NAS大廠皆相當積極，包括群暉科技、威聯通科技（QNAP），都在2017年加入MITRE的CNA計畫，是臺灣最早可自行指派產品CVE漏洞編號的業者，並藉此建立起與外部資安研究人員更直接的溝通與漏洞揭露管道。

關於這方面的經驗，群暉科技很早就在多種場合暢談實務作法，我們已有多次報導，這次我們則是深入了解威聯通的實務經驗與最新進展。

強化產品資安歷經四大里程碑，從CVE指派到全球漏洞競賽

從漏洞因應到強化整體產品資安，威聯通科技軟體研發中心暨軟體安全架構部研發經理黃士展表示，他們很早就將NAS視為完整的電腦系統，而非一般網路周邊產品，這促使團隊更早投入資安議題，更關鍵是，他們認知到「漏洞必然存在」，這會是必然要面對的問題。

回顧威聯通的產品資安推進歷程，大致可分為四個重要階段：

（一）2017年。威聯通成為MITRE CNA計畫成員，此舉是促成他們正式成立產品安全應變小組（PSIRT）團隊的起點。「如果公司內沒有一個任務編組去關注自家產品的資安問題，這不是一件好事。」黃士展說。

如何打造PSIRT？黃士展表示，威聯通建立跨部門的虛擬任務編組，不僅涵蓋RD、PM，也包含DQE、QA等品質團隊，而在持續擴展之下，陸續也納入客服、行銷與法務等單位的人員。

至於PSIRT的整體主導，由具資安背景的軟體架構部負責，每週固定開會，統籌漏洞應變與安全開發相關任務。

（二）2019年。啟動加入FIRST國際資安事件應變組織的進程。黃士展強調，由於加入FIRST需要經過嚴謹的審核，代表其弱點通報與處理流程必須符合一定成熟度，因此，在準備與申請的過程中，等於也讓他們再將自身的漏洞揭露流程梳理一遍，同時也能從國際社群取得更多資安資訊。

（三）2022年。威聯通開始啟動漏洞懸賞計畫（Bug Bounty）。過去他們每年針對NAS系統選定特定主題，進行黑箱式產品滲透測試。但也希望能藉由更多研究人員之力找出產品弱點。

對於Bug Bounty計畫的執行，威聯通PSIRT採取漸進式策略，一開始先從邀請制的獎勵計畫出發，再轉成公開形式開放各界參與。有趣的是，黃士展回憶當時PSIRT雖有意推動Bug Bounty計畫，卻一直下不了決心，憂心會有大量漏洞通報湧入，最後反而是公司行銷同仁持續鼓勵他們，才讓這項計畫真正啟動。

（四）2024年。主動成為Pwn2Own 競賽的贊助商，也提供設備作為獎勵。

黃士展坦言，在此之前，Pwn2Own主辦方就已將威聯通產品納入競賽項目，因此，先前已有接獲ZDI通報產品漏洞的經驗。那些參賽隊伍提交的技術報告，帶給他們新的衝擊：因為那是內部工程師完全沒想過的攻擊手法。

他舉例，在Pwn2Own 2024競賽上，有參賽隊伍回報存取控制不當（CWE-284）與不安全隨機值（CWE-330）相關的弱點。對方先從裝置的MAC位址推導出IPv6位址，再利用實作上的疏失，進一步取得管理API的存取權。這讓他們非常深刻印象，對其團隊而言，也成為一份難得的學習教材。

到了2025年，威聯通加入資安院「資安漏洞獵捕計畫」，此舉並不令人意外。對威聯通來說，這算是順勢而為，因為早有相關經驗，此次將看重與更多臺灣資安研究人員與社群建立緊密的連結。

定期統計弱點的類型，促使類似問題的檢查工作變成可重複執行

對於產品漏洞的因應處理，黃士展闡釋其實務作法，首先是要將弱點分級，他們對應不同嚴重度畫分V1至V5等級。以最嚴重的V5等級而言，威聯通內部要求從收到通報到修補上架，必須在3個工作天內完成；V4等級則控制在12天內，V3等級則控制在60天內。他強調，這裡所說的「時間」，不只是寫程式修補的工時，而是從確認問題、修正、測試到發布更新的完整處理流程。

他進一步解釋，以一般NAS韌體發布流程來說，正規測試通常就要一星期以上，若要在更短時間完成修補，關鍵在於平時就維持「隨時準備就緒的穩定版本」，一旦完成修補與驗證，就能盡快釋出，因此威聯通對於重大風險的問題處理，可在幾天內就完成修補與發布。

畢竟從流程上來看，收到通報後需要先確認漏洞問題，修補完也需要驗證修補是否到位，包括經過PSIRT審查，以及QA團隊負責重現問題，確認修補後是否還會發生，再準備產品的更新。

處理漏洞不能只看單一事件，黃士展表示，他們還會定期統計弱點類型的分布，無論來自Bug Bounty計畫、Pwn2Own競賽、外部滲透測試或內部檢測，一旦發現某一季某類型漏洞特別多，就會展開系統性改善。

簡單來說，會先在現有專案中主動搜尋相關問題，找出類似的程式樣式與弱點，再開立內部任務工單逐一修正，而且他們還會為了這些共通弱點，設計相應的靜態分析檢查工具或自動化腳本。

黃士展解釋，有些工具是他們內部人員自行開發，有些則是導入現成工具再搭配客製化規則，重點是讓這些檢查變成可重複、可持續運作的機制。

善用集團經驗完善安全開發，並推動用AI協助程式碼審查

對於安全開發的推動，黃士展認為，即使不刻意對齊特定標準，最終實務往往也會朝相同方向發展。

他指出，市面上已有不少可借鏡的框架，例如微軟早期提出的 SDL 安全開發模式，而威聯通本身也早已建立一套產品安全開發的方法論。

如今法規與客戶要求愈來愈明確，他們更傾向對接國際標準，例如工控領域重視IEC 62443中的安全開發相關規範。

事實上，從集團角度來看，他們的母公司威強電這幾年已有行動，有產品通過IEC 62443-4-1、IEC 62443-4-2認證，威聯通也邀請集團內有經驗的團隊擔任講師，這的確減少了許多摸索的過程。

這種集團內部有豐富資源可互相支援的方很不錯，就像6年前威聯通加入FIRST組織，去年威強電也開始跟進。

談到導入IEC 62443的安全開發標準，黃士展表示，對威聯通而言，這不是推翻既有作法，而是將原本就存在的安全開發流程重新分類、對齊標準。

他表示，這麼做有幾個好處，例如：與外部顧問、客戶、主管機關溝通時，大家用的是同一套語言；日後若要進行第三方驗證，也有較紮實的基礎。過程中，他們也因此看見過去做得不夠完整之處，例如部分開發設計前的安全活動，在一開始有做，但缺乏定期執行，或原本屬於「因人而異、想到才做」的工作，現在都被納入有紀錄、有證據的例行流程。

至於是否用AI幫助產品資安團隊的能力？黃士展指出，他們主要聚焦程式碼分析與開發規範檢查，對於弱點情資彙整等任務，態度則相對保守，未來會持續觀察業界最佳實務與實際成效。

他舉例，目前威聯通已導入微軟GitHub Copilot企業版，由於內部團隊發現，AI對於檢視大量程式碼變更具備相當成效，因此已在程式碼審查流程中，逐步推動使用AI來協助程式碼審查。他並認為，AI將有助於挖掘過往遺留下來的技術負債。

另一項仍在嘗試的作法，是建置MCP Server，將安全程式開發指引整合為檢查規則的一部分，例如加解密演算法是否安全、是否落實輸入驗證等，這如同「結合LLM的靜態分析」的輔助角色，目前相關成效仍在觀察與評估中。