Genesis，以及例外清單上的格式

Glasswall 先前的引擎已能以原生方式重建日常格式。Genesis 於 8 月 17 日推出，將同樣的重建能力帶到 140+ 種副檔名，以其自身格式處理，速度最高可達兩倍。這句話裡，數字是最不有趣的部分。

「支援」的兩種含義

先從「支援某種檔案類型」的意思開始，因為它其實有兩種不同的含義，而只有其中一種算是控制。

第一種是辨識格式並對其做些處理：把它扁平化成圖片、移除看起來危險的內容，或因為看起來沒問題就直接放行。多年來，許多工具都能在長長的檔案類型清單上做到這一點。

第二種是把檔案拆解開來，依照製造商公開的規格驗證每一個結構，然後從這個中介表示法製作出一個新的檔案，並維持它原本送進來的格式。原始檔案從未通過。那才是重建，而這也是唯一會改變使用者實際接收到內容的「支援」版本。

例外清單

每個檔案控制都有一份例外清單，不論有沒有寫下來：CAD 圖面、地理空間影像、DICOM 研究、可執行檔，因為控制無法重建它們，所以都被繞過。沒有人會這樣稱呼它。它可能是一條郵件規則、一個繞過閘道的共用資料夾，或是一條固定指示：工程檔案直接送到工程部門。

扁平化從未真正填補那個落差，即使它曾被提供。檔案圖片的問題不在於沒人看得懂；今天，模型甚至能從試算表照片中讀出數字。問題在於，圖片不是可工作的檔案。公式、幾何、圖層、座標，以及下游系統需要的中繼資料都不見了，因此它無法回到工作流程中，原始檔案也就得在控制之外被重新索取。讓檔案變安全的控制，同時也讓工作變成手動，而報告裡只會寫其中一項。

Genesis 帶來什麼

Genesis 帶來的是同樣的重建機制，但套用到承載專業工作的格式上。根據 Glasswall 公開的涵蓋範圍：NITF 與 SIDD 影像、DWG、DXF 與 STEP AP242、DICOM、PE、ELF、Mach-O 與 Windows shortcuts、含巢狀附件的 email、audio 與 video、structured data 與 web formats，以及日常文件。每一種都以其原生格式重建，保留 CMYK 準確影像、嵌入字型完整無缺，且座標不受影響。

這就是讓例外清單變短的原因：不是 policy 決策，而是一個能觸及更遠的控制。

有兩件事比涵蓋範圍更重要。

沒有捷徑。 每種格式都會被完整處理並重建，且巢狀內容會一路追蹤到底，而不是只到時鐘允許的深度。文件中的圖片、email 中的文件、文件中的圖片，都必須依照自身條件符合 policy，而不是繼承外層容器的信任。這個產業中的每一個深度限制，最初都只是工程上的折衷，後來卻悄悄變成了 policy；而另一邊會把它解讀成一條指示：把它放在他們停止處理位置的下一層。

速度。 Glasswall 表示，其處理速度比前一代引擎最高快 2 倍，而前一代本來就已經很快。這聽起來像註腳，但其實不是。延遲正是 inline 控制被改成僅監控、在大型檔案上被跳過，或一開始就被加上深度限制的原因。足夠快、能跑在所有內容上的控制，才是真正能跑在所有內容上的控制。

在底層，這個引擎以受管理的 .NET 撰寫，並編譯為一個 獨立的 Native AOT 二進位檔，這縮小了在解析惡意檔案時所伴隨的記憶體損毀暴露面， 而且它可在 Windows、Linux 和 macOS 上執行， 可部署於容器、戰術邊緣環境或完全隔離網路環境，且不依賴 簽章或信譽服務。每條規則都帶有結構化來源資訊、 其所依據的已發布規格、追溯到的 CVE 或公告，以及報告會顯示 發現了什麼、採取了什麼處置，以及檔案離開時所處的狀態。

為任何簽核邊界的人提出的問題

今天哪些格式被列在你的例外清單上，而它們被放進去的原因是 因為它們安全，還是因為你手上沒有任何東西能重建它們？

Genesis、Halo 和 Meteor 各自適用於哪裡，請見我們的 products page。 至於讓例外清單在新加坡成為稽核問題的檔案處理義務，請參閱 Singapore compliance page。