智能制造软件的应用安全平台如何选择

仪表盘显示温度骤升。这个数字来自某个源头。一个API采集了它。一个服务把它传递下去。一条查询把它从存储中取出。

这条链路中任何一个薄弱环节出问题，读数就可能失真。本文介绍的工具关注的是构建这些链路的软件本身，不是电缆、交换机，也不是机器设备本身。

五款平台，都是面向编写工厂应用、云服务以及车间人员查看的仪表盘的团队。

有两个话题不在本文讨论范围内：监控控制网络，以及认证安全功能。这些需要专门的工具来解决。

Aikido

运行工厂车间的软件是由人编写的，而不是机器。Aikido正是为这些人打造的。过去，机器人和装配线只靠硬件运转，如今代码承载的工作量同样举足轻重。

该平台同时监控三个层面：

第一，开发者编写的源代码。注入漏洞、跨站脚本、缓冲区溢出，每一项都会对照已公开的CVE记录进行核查。

第二，从公共仓库引入的一切内容。软件包、框架、辅助库。可达性分析会剔除那些从未被执行的代码，确保镜像不留冗余。

第三，服务所依赖的镜像本身。扫描会深入到基础操作系统层，老旧软件包往往藏在那里。

发现漏洞只是完成了一半工作，更难的一半是把它修复掉。

三项独立扫描通常意味着三个独立的问题队列。Aikido把它们汇总到一个界面上。排在前面的内容遵循上下文判断，而不是单纯的严重程度。四个人的团队没有时间处理上百条警告，但有时间处理那些真正可能造成问题的少数几条。

噪音可降低多达85%。在此基础上，一个AI步骤会把每一个真实命中的问题推向对应的修复方案，这样没有人需要面对一张空白的页面。

部署几乎无需额外操作。不在任何机器上安装任何东西，也不需要维护。整套系统通过API通信。GDPR和ISO 27001的合规检查内置其中，为需要满足监管要求的团队省去了一道步骤。

源代码、依赖库、镜像——一个界面，一个队列，一个知道接下来该怎么做的人。

核心能力：

涵盖主流语言的SAST静态分析，并结合CVE数据库核查

具备可达性过滤和一键自动修复的软件成分分析

基于敏感度优先级排序的容器镜像扫描

针对Terraform、CloudFormation和Kubernetes Helm图表的基础设施代码（IaC）扫描

针对暴露端点的API和DAST动态分析覆盖

无需安装代理，基于API的部署方式

Snyk

Snyk最初专注于外部组件：导入的软件包、引入的库，这仍是它的强项所在。后来它又扩展到团队自己编写的代码以及部署的镜像。它为编辑器、代码仓库和构建服务器都提供了扩展插件。

想想典型的工厂项目：一个仪表盘引入了图表库；一个API基于某个Web框架搭建；一个工作进程引入了队列客户端和数据库驱动。这些都不是内部编写的，全部来自外部。

这正是问题所在：每一个引入的组件都可能是一个漏洞。Snyk会逐一检查这些组件，对照已公开的CVE列表进行匹配，然后在开发者已经打开的编辑器中，把建议的修复方案直接放在需要修改的那行代码旁边。

镜像扫描也同步进行。打包给工厂机器使用的服务，会和其中封装的代码接受同样的检查。

具体深度取决于订阅层级，部分功能可能被限制在更高级的方案中。在将其推广给整个团队之前，请确认当前层级所涵盖的内容。

核心能力：

针对已知CVE的开源依赖扫描

针对部署包的容器镜像扫描

集成IDE、代码仓库和CI系统，实现工作流内反馈

第三方软件包的许可证合规检查

针对具体发现问题的修复建议

Semgrep

你把Semgrep指向一个文件夹，它会逐一处理里面的文件。

真正有意思的是它的规则。这些规则读起来就像它们所检查的语言本身。一位Java开发者打开一条规则，无需额外帮助就能看懂。如果某条规则需要调整，修改只需一分钟。

它运行速度也很快，快到可以在每次拉取请求时都触发扫描，这样处理机器数据的服务在每次提交代码时都会被检查一遍，这比等到发布周才检查要好得多。它还能追踪函数之间传递的数值，这正是单文件扫描工具通常无法做到的地方。

但也存在局限。它只针对源代码，软件包和镜像需要其他工具来处理。规则的可用性因订阅层级而异，需确认你的方案能开放哪些内容。

核心能力：

规则语法贴合所分析的编程语言

支持Python和Java的跨文件数据流分析

适合拉取请求检查的快速扫描

针对常见Web框架的专用规则

功能集因版本而异，需自行核实

Checkmarx

Checkmarx支持Java，支持Python，还支持一长串其他语言。它真正的卖点在于结构化——报告、审计记录，这正是安全团队在需要就十几个应用程序同时负责时所需要的那种文档支撑。

这种结构化是有代价的。完整扫描一次所需的时间比专为开发者打造的快速工具要长。团队通常会把重度扫描安排在夜间进行，没有人会为了一个小改动而等待扫描结果。

回报在于深度和证据留存。当审计人员问起某个发现是如何处理的，答案就保存在这个平台里。

一家在多个厂区运营不同产品线的制造商，能从中获得真正的价值。而一个每天下午都要推送代码的五人团队，则会觉得这个流程对日常工作来说太慢了。

核心能力：

无需编译步骤即可进行SAST静态分析

为合规审查提供报告和审计追踪

覆盖企业代码库的多语言支持

支持跨多个团队分配发现问题的工作流程

与现有构建和发布流水线集成

GitLab

GitLab承载源代码，运行构建流程，扫描也在同一个地方进行。代码检查、软件包检查、镜像检查，每一项都作为流水线中的一个阶段触发，输出结果会显示在触发它的那次提交旁边。

已经按这种方式工作的工厂团队能免费获得这项能力，无需安装第二个工具，无需第二次登录。发现的问题会直接出现在开发者已经打开的合并请求里，就在他们本来就在用的那个标签页中。

不过并非所有功能都已解锁，较低的订阅层级会缺少部分检查功能。在向团队说明预期之前，先确认你的层级实际包含哪些内容。

核心能力：

作为流水线任务的静态分析

针对第三方软件包的依赖扫描

针对部署镜像的容器扫描

发现结果直接显示在合并请求旁

安全功能因订阅层级而异，需自行核实

如何将应用安全融入智能制造开发流程

一个躲在菜单里的工具自身不会产生任何作用，真正起作用的是围绕它建立的习惯。

在分支还未合并时发现问题，代价只是一次编辑，开发者本就在这个文件里，修复只需几分钟。

同样的问题要是在发布之后才被发现，账单就完全不同了：回滚、紧急补丁、以及一场复盘它是如何被漏过的会议。

同一个漏洞，两种截然不同的处理过程。密切关注你所借用的一切——图表库、Web框架、队列客户端、数据库驱动，这些都来自外部。把检查设定为定期任务，这样新出现的CVE能被及时发现，而不是等某个人想起来才去查看。

对镜像也要做同样的事。一年前还是干净的基础镜像层，现在未必还是干净的，里面的软件包会在不知不觉中老化。

按可见范围给结果排序，面向公共互联网的漏洞，理应比只有内部员工能接触到的同类漏洞得到更多关注。

给每个工单都指定一个负责人，没人认领的发现问题只会被搁置积灰，有负责人的发现问题才会被真正解决。

举个例子：一个工作进程从温度探头采集读数，把它们传给仪表盘，并保存到数据表中。在这段代码合并之前，一项检查发现了一个用户输入未经验证的漏洞；另一项扫描发现了一个刚刚被列入CVE列表的辅助库；第三项发现了一个几个月前拉取、从未更新过的基础镜像。这三个问题都会在开发者本就花在这个分支上的那个下午被发现，没有任何一项被拖延到评审周才处理。

总而言之

先看看你的团队目前是如何交付软件的，再据此选择与这种节奏相匹配的工具。

三个问题决定答案：它是否覆盖了你实际运行的所有层面——编写的代码、借用的软件包、部署的镜像？发现问题能否顺利转化为修复而不产生阻力？它是否能融入开发者每天早上打开的那个流水线？

Aikido为构建制造应用和云服务的团队把这三者整合在了一起。把它和其他工具对比一下，然后选择最适合团队现有工作方式的那一个。

Q&A

Q1：Aikido具体能监控哪些安全层面？

A：Aikido同时监控三个层面：开发者编写的源代码、从公共仓库引入的软件包和依赖库，以及服务部署所依赖的容器镜像，三者结果汇总到同一界面进行统一管理。

Q2：Semgrep和Snyk的主要区别是什么？

A：Semgrep主要针对源代码进行快速扫描，适合在每次拉取请求时触发检查；Snyk则更专注于开源依赖和容器镜像扫描，能在编辑器中直接给出修复建议，两者覆盖的安全层面不同。

Q3：企业该如何选择适合自己的应用安全平台？

A：需要考察三点：工具是否覆盖了实际运行的代码、依赖库和镜像；发现的问题能否顺利转化为修复；以及该工具是否能融入团队日常使用的开发流水线中。