SCI Semiconductor 新完成的 500 萬英鎊成長輪募資,不只是一次半導體新創的擴產案,也是在驗證一個資安界長期追求的想法:與其等軟體漏洞出現後不斷修補,能否直接在處理器架構中,阻止部分危險的記憶體錯誤?
這家總部位於英國雪菲爾的公司,計畫把資金用於擴大 ICENI 晶片生產,並開發下一代產品。
3
6
誰投資?資金將用在哪裡?
本輪募資獲超額認購,由 PXN Ventures 與 Mercia Ventures 領投;兩者分別管理 Northern Powerhouse Investment Fund II(NPIF II,英國支持北部地區企業成長的投資基金)的相關股權基金。專注網路資安的 Osney Capital、美國 Black Opal Ventures 與私人投資人也參與投資。
3
6
SCI 表示,當前重點是因應 ICENI 的需求擴大產能,同時推進後續晶片研發。公司已製造首批元件,並稱已取得超過 200 萬英鎊訂單;此外,還稱已獲得總額 770 萬英鎊的政府合約,並與 Google Research、Microsoft 建立合作關係。
6
12
這些數字顯示產品已有初步市場動能;但能否形成長期採用,仍取決於硬體、軟體開發工具鏈與實際應用能否在客戶產品中順利整合。
ICENI 的差異:把記憶體防護放進硬體
ICENI 採用 CHERI(Capability Hardware Enhanced RISC Instructions)架構。CHERI 是由英國支持研究發展的「能力導向」電腦架構,透過具備記憶體安全特性的指標,以及安全的記憶體區隔,控制軟體可如何存取記憶體。英國政府將其定位為「安全內建」的方法,目標是強化系統安全,並消除許多常見的記憶體安全弱點。
簡單說,系統可在硬體層級限制程式存取不該碰的記憶體範圍,讓無效存取、超出邊界讀寫等錯誤更難遭到利用。這與僅依賴程式寫完、部署後再進行軟體檢查或修補的做法不同。
這項技術受到重視,原因在於記憶體安全漏洞至今仍是資安缺陷的重要來源。英國政府援引 Google 與 Microsoft 的研究指出,記憶體安全問題約占持續出現的網路弱點 70%。
不只是資安:記憶體錯誤也可能造成大規模服務中斷
記憶體錯誤不只會造成可被攻擊的漏洞,也可能引發可靠性事故。2024 年 7 月的 CrowdStrike 全球中斷事件並非網路攻擊;不過 CrowdStrike 的技術根因分析指出,其 Content Interpreter 中潛伏的「超出邊界讀取」問題,是在有問題的更新推出後造成系統當機的因素之一。
這並不代表採用 CHERI 的設計必然能避免該事件的所有成因,但它說明了為何企業愈來愈重視:能否減少整類程式錯誤,而不只是等問題發生後再偵測與補救。
英國國家網路安全中心(NCSC)也提出類似觀點:記憶體安全漏洞十分普遍,若採取安全內建的開發方式,可望減少持續修補與事件應變的負擔。不過 NCSC 同時強調,修補程式仍不可或缺,尤其是面對外部曝露或關鍵系統時更是如此。
CHERI 能解決什麼,又不能解決什麼?
由硬體強制執行的記憶體邊界,可降低部分記憶體破壞型漏洞被利用的機率或衝擊。對於支援週期很長、或故障代價很高的設備與環境,這類能力尤其具吸引力。
但記憶體安全只是資安的一層防線。CHERI 架構硬體不會自動消除身分驗證與存取控制失誤、不安全的更新機制、錯誤設定、社交工程、供應鏈風險或應用程式商業邏輯漏洞。企業仍須落實安全軟體開發、測試、監控、弱點管理與及時更新。
因此,SCI 面臨的商業課題不只是晶片效能。客戶需要看到一條可信的導入路徑:如何在成本、相容性與開發效率可接受的前提下,把具 CHERI 意識的硬體與軟體整合至實際產品。
CRA 通報時鐘啟動,安全內建更具商業意義
歐盟《網路韌性法案》(Cyber Resilience Act,CRA)的通報義務,適用於數位元素產品的製造商。自 2026 年 9 月 11 日起,製造商若知悉產品安全受到影響的遭積極利用漏洞或重大事件,必須通報;其中初步預警須在知悉後 24 小時內提出,較完整的通報則須在 72 小時內完成。
17
18
記憶體安全架構可望協助製造商減少部分可能需要通報的記憶體破壞漏洞,並呈現較強的安全內建設計立場。然而,它不會自動帶來 CRA 合規。產品安全治理、事件偵測、弱點處理、通報流程與其他法規要求,仍須由業者自行建立並持續執行。
下一個驗證點:能否大規模落地
SCI 成立於 2022 年,並被報導為英國「Accelerated CHERI Adoption Programme」的核心供應商。公司計畫在雪菲爾與劍橋共 35 人的團隊基礎上,新增 15 個職缺。
11
14
這筆 500 萬英鎊資金,讓 SCI 有機會從首批晶片與早期訂單走向量產。它的核心主張很直接:若能由硬體強制執行記憶體存取規則,部分漏洞就能在演變成修補、服務中斷或通報事件前被阻止。
不過,這會不會成為廣泛部署的產品類別,最終仍要看客戶整合速度、開發者工具成熟度,以及在正式生產環境中的效能表現。