fuchencong

之前文章分别分析了 Grype 的整体执行流程、命令行配置系统和软件包发现过程。在 pkg.Provide() 返回 []pkg.Package 之后，runGrype() 会将这批软件包交给 VulnerabilityMatcher 执行漏洞匹配，最终生成一份扫描报告。在这一整条链路中，有三个数据结构贯穿始终：

前两篇文章从 main() 和配置系统开始，建立了 Grype 的顶层调用框架。runGrype() 完成配置加载后，第一个关键步骤就是调用 pkg.Provide()，将用户输入转换成漏洞匹配引擎可以直接使用的 []pkg.Package。这篇文章将分析 Grype 如何把 dir:、docker:、registry:、sbom: 甚至一个 PURL 字符串统一为一个软件包集合。

上一篇文章从 main() 开始，跟踪了一次扫描如何进入 runGrype()。在真正加载漏洞数据库（Database，源码和日志中常简写为 DB）和收集软件包之前，还有一个重要步骤：把默认值、配置文件、profile（配置档）、环境变量和命令行参数合并成最终的 options.Grype。这篇文章我们将分析 Grype 是如何解析命令行和配置的。

上一篇文章介绍了 Grype 的基本用法。这篇文章开始分析 Grype 的源码实现，我们先不深入某一种漏洞如何匹配，而是从程序入口开始，跟踪执行一条扫描命令最后是如何获取漏洞结果的。通过分析扫描命令的执行流程，我们将建立 Grype 的整体调用链，为后续分析配置系统、软件包 Provider、漏洞数据库和 Matcher 打下基础。

Grype 是 Anchore 开源的一款漏洞扫描工具，主要用来扫描容器镜像、文件系统和 SBOM 中的已知漏洞。SBOM（Software Bill of Materials，软件物料清单）是一份描述软件由哪些组件构成的清单，通常会记录依赖包的名称、版本、类型和来源等信息，可以把它理解为软件的 配料表。Grype 会先识别目标中包含的软件包，再将软件包名称、版本、发行版等信息与漏洞数据库进行匹配，最后输出漏洞等级、修复版本、EPSS（Exploit Prediction Scoring System，漏洞利用预测评分系统）、风险分数等信息。

Tree-sitter 是一个用于解析源代码的工具和库，核心作者是 Max Brunsfeld。它的核心目标是：快速、增量地把代码转换成语法树（Syntax Tree）。它现在被很多编辑器、IDE、代码分析工具使用，例如 Atom（最初主要使用者）、Zed、GitHub 的代码高亮/代码跳转等等。上篇文章介绍的 Bearer SAST 工具就依赖于 Tree-sitter。

这篇文章我们来学习一个开源的静态应用安全测试（Static Application Security Testing，SAST）工具：Bearer，我们将使用使用它来扫描一个示例项目，以对 SAST 有个基本的认知。

前几篇文章我们已经详细分析了 kratos gRPC Transport 的实现原理，这篇文章我们将回到服务端，开始分析 kratos 的另一条核心传输链路：HTTP Transport。本文会先介绍 HTTP Transport 的整体设计，再深入 HTTP Server 的创建流程、路由注册、Filter 与 Middleware 的分层关系，以及一次 HTTP 请求在 kratos 中的完整处理链路。

上一篇文章 我们深入 kratos gRPC Server 的中间件体系、拦截器桥接、Transport 上下文等关键实现，这篇文章我们将目光转向客户端：介绍 kratos gRPC Client 的创建流程、客户端拦截器桥接、服务发现与负载均衡、以及整个 RPC 调用的完整链路。

上一篇文章 我们介绍了 kratos gRPC Server 的整体设计、创建流程、启动与停止逻辑等。这篇文章我们将深入 gRPC Transport Server 剩余的实现细节，包括拦截器桥接机制、中间件选择器、编解码器、Transport 上下文等实现。