Genesis，以及例外列表中的格式

Glasswall 之前的引擎以原生方式重建了日常格式。Genesis 于 8 月 17 日发布，将同样的重建带到 140+ 种文件扩展名，以它们自己的格式处理，速度最高可达两倍。这个句子里，数字是最不有趣的部分。

“supported”的两种含义

先从“supports a file type”是什么意思说起，因为它有两种不同的含义，而只有其中一种才是控制。

第一种是识别格式并对其做点什么：把它扁平化成图片，剥离看起来危险的内容，或者因为看起来没问题就直接放行。多年来，很多工具都能在很长的文件类型列表上做到这一点。

第二种是把文件拆开，依据制造商公开的规范验证每一种结构，然后从这个中间表示重新制造一个新文件，并保持它到达时的同一格式。原始文件从未通过。那才是重建，而只有这种“supported”的版本，才会改变用户最终接收到的内容。

例外列表

每个文件控制都有一份例外列表，不管是写下来的还是没有写下来的：CAD 图纸、地理空间影像、DICOM 检查、可执行文件，都会被绕开控制，因为控制无法重建它们。没人会这么称呼它。它可能是一个邮箱规则、一个绕过网关的共享文件夹，或者一条长期有效的指令：工程文件直接送到工程部门。

扁平化从未弥合这一差距，即使在提供这种功能的地方也是如此。文件图片的问题不在于没人能读懂它；如今，模型可以从电子表格照片里读出数字。问题在于，图片不是工作文件。公式、几何、图层、坐标，以及下游系统所需的元数据都不见了，因此它无法重新进入工作流，原始文件就会在控制之外被再次索取。让文件安全的控制，也让工作变成了手工操作，而报告里只会写其中一项。

Genesis 带来了什么

Genesis 带来的是同样的重建机制，但应用于承载专业工作的格式。根据 Glasswall 公开的覆盖范围：NITF 和 SIDD 影像、DWG、DXF 和 STEP AP242、DICOM、PE、ELF、Mach-O 和 Windows shortcuts、带嵌套附件的 email、音频和 video、结构化数据和 web 格式，以及日常文档。每一种都以其原生格式重建，图像保持 CMYK 准确，嵌入字体完整，坐标不受影响。

这就是为什么例外列表会变短：不是因为 policy 决策，而是因为控制覆盖得更远。

关于这一点，有两件事比覆盖范围更重要。

No shortcuts. 每种格式都会被完整处理并重建，嵌套会一直追踪到底，而不是只到时钟允许的深度。文档里的图片、邮件里的文档，都会按照自身条件满足 policy，而不是继承其外层包装的信任。这个行业里的每一个深度限制，最初都只是工程上的折中，后来却悄悄变成了 policy，而另一边会把它读成一条指令：把它放到他们停止的地方再往下一层。

Speed. Glasswall 报告称，其处理速度比前一代引擎最高快 2 倍，而前一代本来就已经很快了。这听起来像脚注，但并不是。延迟正是 inline 控制被改成仅监控、在大文件上被跳过，或者一开始就被赋予深度限制的原因。一个快到足以运行在所有内容上的控制，就是一个真正运行在所有内容上的控制。

在底层，engine 采用托管 .NET 编写，并编译为一个独立的 Native AOT binary，这缩小了在解析恶意文件时伴随而来的内存破坏暴露面；它可在 Windows、Linux 和 macOS 上运行，可部署在 container 中、战术边缘环境中，或完全 air-gapped 环境中，不依赖 signature 或 reputation services。每条 rule 都带有结构化 provenance、其所依据的已发布 specification、所追溯到的 CVE 或 advisory，以及 reporting 会显示发现了什么、采取了什么措施，以及文件离开时所处的状态。

负责批准边界的人需要回答的问题

今天哪些 formats 被列入了你的 exception list？它们被列入是因为它们是 safe，还是因为你手头没有任何东西能够 rebuild 它们？

Genesis、Halo 和 Meteor 各自适合的位置见我们的 products page。关于使 exception list 在 Singapore 成为审计问题的 file-handling obligations，请参见 Singapore compliance page。