关于安全:乐高式扩展在Seal软件供应链防火墙中轻松集成代码规范工具

35次阅读

共计 2918 个字符，预计需要花费 8 分钟才能阅读完成。

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

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

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

通常，实现一个框架的插件化，咱们须要思考以下问题：

升高插件化的老本。
标准插件调用的输入输出。
配置（限度）插件调用的权限。
（可选）治理插件调用的状态数据。

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 code
var 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: sast
format: yaml
resourceKinds: ["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

正文完