上个月，Seal 软件供应链防火墙 v0.2（以下简称“Seal”）正式发布，这一版本实现了可扩展架构，用户可以根据自身需求插件式集成原生或第三方解决方案，灵活扩展扫描能力。

在前一个版本中，Seal 集成了 SCA、SAST 和配置检查等功能，在这一架构中最大的优势是调试方便、调用链路短，但同时也伴随着模块耦合、依赖树深以及扩展困难等问题。因此，在新版本中使用了新的 ⌈插件化框架⌋ 来重构了 SCA、SAST 和配置检查的集成，并以此解决上面谈及的扩展性问题。

之前的演示中，我们展示了如何使用 v0.2.0 的插件管理：把 IaC 配置检查 ⌈插件⌋，⌈无缝⌋地集成到 Seal 里。本文将介绍插件化框架的底层原理以及演示如何将代码规范工具集成到 Seal 软件供应链防火墙中。

插件化框架的工作原理

通常，实现一个框架的插件化，我们需要考虑以下问题：

1. 降低插件化的成本。

2. 规范插件调用的输入输出。

3. 配置（限制）插件调用的权限。

4. （可选）管理插件调用的状态数据。

Seal 通过让插件的改动最小化来降低插件化的成本，换言之，Seal 可以让插件保留其原有的配置方式，用户仅需适配插件调用的输入输出即可。插件的配置项可以通过 Seal 的策略面板暴露成策略，最终作用到 Seal 的各个拦截点上。

# policies.yaml- code: # <string>, 策略代码，唯一标识  category: # <string>, 策略分类，所在的一级组  type: # <string>, 策略类型，所在的二级组  name: # <string>, 策略名称（或原有配置项的名称）  description: # <string>, 策略描述（或原有配置项的描述）  enabled: # <bool>, 默认启用  builtIn: # <bool>, 默认内置（内置，是相对于使用插件的使用者而言）  bindings: # 作用的拦截点    isAllResource: # <bool>, 作用于源代码仓库    isAllProxy: # <bool>, 作用于代理  constraint: {} # 约束，结构化的配置  expression: "" # 表达式或原配置项  action: # <string>, 违反该策略后，应该做出的动作  severity: # <string>, 违反该策略后，应该声明的严重程度 - code: ...   category: ...   ...

然后， Seal 在某个拦截点上运行检查时，会拉取相应的已启用的策略，生成配置文件和拦截点上的状态数据（例如，对于源码仓库的检测，拦截点为源码仓库，状态数据为检测时刻的源代码）作为插件调用的输入。当插件检查完毕后，将结果以 SARIF的格式输出到指定路径。

最后， Seal 将所有插件的 SARIF 输出汇总，并根据策略定义的行为（action）决定实施拦截、通过还是告警。

另外，对于信任（trusted）的插件，Seal 会在插件调用时注入 API Token （SEAL_API_TOKEN），从而允许插件获得 Seal 的能力：风险评估、漏洞数据、合规信息等。

集成代码规范工具

假设，有个 style-checker 的组件，它可以检查源代码的书写规范，支持丰富的风格检查配置。其中，有一条配置项：K&R 风格检查。当源代码中有风格违反配置规则时，style-checker 会输出失败信息。

style-checker \  --path="/path/to/your/code" \  --kr-style="true" \  --msvc-style="false" \  --... \  --report="/path/to/record/illegal/result"

首先，需要给 style-checker 做一个包裹器（wrapper-style-checker），这个包裹器是用来接收 Seal 的输入输出。wrapper-style-checker 可以用任何语言编写，在运行时，从环境变量中获取以下内容：

SOURCE_DIR="/path/to/your/code" \PLUGIN_POLICY_FILENAME="/path/to/receive/configuration" \PLUGIN_OUTPUT_FILENAME="/path/to/output/sarif_report" \SEAL_API_TOKEN="" \SEAL_URL="" \  wrapper-style-checker

然后，规整 style-checker 的配置项，按照合适的粒度构建出相应的策略。这里，以每个配置项作为一条策略。Seal 会在安装插件的阶段阅读这个策略文件（policies.yaml），把其中的每一项都呈现到 Seal 的策略面板。

# policies.yaml- code: STYLE-CHECKER-POL-1  category: sast  type: style  name: kr-style  description: 检查是否严格使用K&R风格编码。  enabled: true  builtIn: true  bindings:    isAllResource: true  expression: |    KRStyle: true    MSVCStyle: false

接着，实现 wrapper-style-checker 对策略文件的理解（转换），把 expression 的信息转化成对 style-checker 的调用，并把执行后的结果按 SARIF 格式输出。

# pseudo codevar policies = read(${PLUGIN_POLICY_FILENAME})var config = parseInput(policies)var result = call("style-checker") on (${SOURCE_DIR}) with (config)var sarif = parseOutput(result)write(${PLUGIN_OUTPUT_FILENAME}) with (sarif)

最后，用元信息文件（metadata.yaml）描述 wrapper-style-checker 插件的信息，包括 UI 展示，多语言等。

category: sastformat: yamlresourceKinds: ["repository"]policies:- type: style  conditions: []locales:  en:    "policy.style": "Style Checker"  zh:    "policy.style": "风格检查"

插件安装

完成以上步骤后，可以把 wrapper-style-checker（二进制可执行文件） 、策略文件（policies.yaml）和元信息文件（metadata.yaml）打包成一个 tar.gz 包，并通过 Seal 的 ⌈插件管理⌋ 页面进行下载安装，实现开箱即用。

总结

得益于插件化框架的扩展能力，Seal 为用户提供了 IaC 配置检查功能，并且可以快速适应部署环境已有的复杂性。用户也可以根据自身需求利用插件化框架灵活扩展扫描能力，轻松为代码安全提供进一步保障。在后续版本中，Seal 研发团队会持续丰富插件功能，优化插件策略及配置机制，为用户提供丝滑的可插拔体验。

欢迎访问下方链接，申请产品试用，体验灵活的插件化扩展：

https://seal.io/trial