Wazuh 代码库 Coverity 静态分析容器化扫描工具链的使用与原理【免费下载链接】wazuhWazuh - The Open Source Security Platform. Unified XDR and SIEM protection for endpoints and cloud workloads.项目地址: https://gitcode.com/GitHub_Trending/wa/wazuh导读本文围绕 Wazuh 仓库tools/testing/coverity/目录下的扫描工具链展开讲解如何借助 Coverity Scan 对 Wazuh 这个大型 C/C 安全平台代码库执行静态分析。读完本文你将掌握coverity.sh帮助脚本与配套Dockerfile的完整用法——包括镜像构建、本地/CI 分析、结果打包与上传的全流程并理解其背后的构建参数COVERITYYES、元数据生成逻辑以及仓库内 GitHub Actions 工作流的真实调用方式。目录组成与工具定位tools/testing/coverity/目录下只有三个文件职责非常清晰文件作用coverity.sh主辅助脚本负责下载 Coverity 分析工具、构建 Docker 镜像、在容器内运行分析、打包并上传结果Dockerfile定义用于编译 Wazuh 的分析镜像镜像内预置cov-build工具与编译依赖README.md使用说明即本文的骨架来源这套设计的关键点在于本地与 CI 使用同一套容器化环境执行分析从而保证分析结果的可复现性。CI 场景下仓库提供了对应的 GitHub Actions 工作流见下文与 CI 集成一节。快速上手命令与参数脚本的调用格式如下./coverity.sh [--build-image] [--build] [--upload] [--clean] [--jobs N]不带任何参数运行时脚本会依次执行编译分析和结果上传两个阶段即等价于--build --upload。各选项的语义如下选项行为--build-image下载 Coverity 分析工具并构建 Docker 镜像完成后脚本立即退出必须设置COVERITY_TOKEN--build使用 Coverity Docker 镜像编译项目生成分析输出wazuh.tgz--upload将wazuh.tgz上传至 Coverity Scan必须设置COVERITY_TOKEN且 tarball 不存在时直接报错退出--clean清理生成物删除cov-int/目录与wazuh.tgz压缩包--jobs N指定编译时并行任务数默认取系统nproc--help打印使用信息另外从 coverity.sh 的源码可以看到脚本还额外支持--tag tag选项用于指定所使用分析镜像的 tag默认latest该选项虽未写入 README但在脚本的参数解析与帮助文本中均已实现。环境变量变量说明PROJECTCoverity 项目名必须是wazuh或ossec-wazuh默认wazuh。ossec-wazuh通常用于开发分支的分析避免污染正式项目的缺陷统计COVERITY_TOKENCoverity 项目令牌--build-image与--upload阶段的必填项EMAIL与 Coverity 账号关联的邮箱默认develwazuh.com用于接收分析报告通知注意README 中以TOKEN指代令牌但脚本实际读取的环境变量名为COVERITY_TOKEN见 coverity.sh 中的COVERITY_TOKEN${COVERITY_TOKEN:-}。实际使用时请以COVERITY_TOKEN为准。构建产物分析结果生成在项目根目录下的cov-int目录中项目根目录会生成压缩包wazuh.tgz随后被上传至 Coverity。一次完整扫描的执行流程源码级解析下面结合 coverity.sh 的源码拆解每个阶段在底层究竟做了什么。1. 构建分析镜像--build-imagewget -q https://scan.coverity.com/download/linux64 \ --post-data token${COVERITY_TOKEN}projectwazuh%2F${PROJECT} \ -O $TOOL_TGZ docker build -t $IMAGE $COVERITY_DIR该阶段用wget以POST方式向 Coverity 官方下载站点请求 Linux 64 位分析工具包保存为coverity_tool.tgz随后调用docker build基于 Dockerfile 构建镜像。脚本通过trap机制保证退出时清理临时下载的工具包文件coverity.sh。2. 编译分析--buildmake -C $ROOT_DIR/src clean-internals make -C $ROOT_DIR/src clean-windows rm -rf $COV_DIR docker run --rm \ -v $ROOT_DIR:/src \ -w /src \ -u $(id -u):$(id -g) \ $IMAGE \ make -C src TARGETmanager COVERITYYES -j$JOBS关键点逐条说明先清理源码目录确保分析从干净状态开始docker run将仓库根目录挂载到容器/src以当前用户 UID/GID 运行避免生成 root 属主的文件并使用--rm在结束后自动删除容器容器内执行的是make -C src TARGETmanager COVERITYYES -j$JOBS即以 manager 为目标、开启 Coverity 插桩的编译。COVERITYYES这个开关在 src/Makefile 中有专门处理它会导出COVERITY_UNSUPPORTED_COMPILER_INVOCATION1用于放宽 cov-build 对不常见编译器调用方式的检测确保 Wazuh 复杂的构建脚本多编译器包装、跨模块链接等能正常插桩由于镜像的ENTRYPOINT被设置为cov-build --dir cov-int见下文容器实际执行的命令等价于cov-build --dir cov-int make -C src TARGETmanager COVERITYYES -jN——即所有编译动作都会把发射emit数据写入cov-int目录编译结束后用tar czf wazuh.tgz -C $ROOT_DIR cov-int将分析数据压缩为wazuh.tgz。3. 上传结果--uploadcurl -s -w %{http_code} \ --form token$COVERITY_TOKEN \ --form email$EMAIL \ --form file$TARBALL \ --form version$VERSION \ --form description$DESCRIPTION \ https://scan.coverity.com/builds?projectwazuh%2F${PROJECT}上传通过curl以 multipart/form-data 方式提交携带token、email、file、version、description五个字段。脚本用-w %{http_code}把 HTTP 状态码拼在响应末尾随后解析出响应体与状态码状态码 ≥ 400 视为失败并退出coverity.sh。上传前还会检查wazuh.tgz是否存在不存在则报错提示先执行--build。4. 清理--clean删除cov-int/目录与wazuh.tgz用于在分析结束后释放磁盘空间。Docker 镜像解析Dockerfile 采用多阶段构建基于ubuntu:24.04FROM ubuntu:24.04 AS builder ARG COVERITY_HOME/opt/cov-analysis COPY coverity_tool.tgz /tmp/ RUN mkdir -p $COVERITY_HOME \ tar -zxf /tmp/coverity_tool.tgz -C $COVERITY_HOME --strip-components1 FROM ubuntu:24.04 ARG COVERITY_HOME/opt/cov-analysis ENV PATH$COVERITY_HOME/bin:$PATH RUN apt-get update \ DEBIAN_FRONTENDnoninteractive apt-get install -y curl make cmake gcc g file \ rm -rf /var/lib/apt/lists/* COPY --frombuilder $COVERITY_HOME $COVERITY_HOME ENTRYPOINT [cov-build, --dir, cov-int]设计要点第一阶段解压coverity_tool.tgz到/opt/cov-analysis--strip-components1去除顶层目录最终镜像安装 Wazuh 编译所需的最小依赖集curl、make、cmake、gcc、g、file并清理 apt 缓存控制镜像体积将cov-build加入PATH并把ENTRYPOINT固定为cov-build --dir cov-int——这正是--build阶段容器内编译能够自动产出cov-int分析数据的原因。版本与描述元数据每次上传的分析都会附带从项目提取的元数据VERSION取自仓库根目录的 VERSION.json.version - .stage例如当前仓库为5.1.0-alpha0DESCRIPTION格式为Version $VERSION - Git ref branch其中branch优先取最近的精确 taggit describe --tags --exact-match无 tag 时回退为当前分支名coverity.sh。这些信息会展示在 Coverity Scan 的项目页面上便于区分不同版本/分支的分析结果。与 CI 的集成README 提到同一扫描可以直接跑在 GitHub Actions 的4_codeanalysis_coverity工作流中。对照仓库当前内容该工作流实际有两代实现4_codeanalysis_coverity.yml 与 4_codeanalysis_coverity-image.yml已标记为deprecated仅在手动触发时打印警告不应再使用5_codeanalysis_coverity.yml当前 5.X 分支的正式工作流支持通过workflow_dispatch手动触发可配置projectwazuh/ossec-wazuh、threads、编译targetmanager / agent与镜像 tag。其内部流程与本地脚本高度一致preparejob 计算PROJECTwazuh→wazuh/wazuhossec-wazuh→wazuh/ossec-wazuh、JOBS、VERSION与DESCRIPTIONbuildjob 执行make -C src deps下载依赖、登录容器仓库ghcr.io、调用.github/actions/coverity/build复合动作执行make -C src TARGETtarget COVERITYYES -j$JOBS随后打包wazuh.tgz并上传到内部 S3 暂存uploadjob 从 S3 取回产物调用.github/actions/coverity/upload复合动作完成上传其中 token 按项目区分正式项目使用COVERITY_SCAN_WAZUH_TOKEN开发项目使用COVERITY_SCAN_OSSEC_TOKEN。5_codeanalysis_coverity-image.yml负责构建并发布分析镜像触发条件为workflow_dispatch手动触发或push 到tools/testing/coverity/**路径即工具目录内容变更时自动重建镜像发布到ghcr.io/wazuh/coverity-scan:tag默认 tag 为5.x。这意味着一旦分析工具链或构建依赖有改动CI 会自动重建并推送新镜像本地与 CI 始终基于同一镜像版本避免了本地能跑、CI 报错的环境漂移问题。实战示例完整工作流以下是 README 给出的标准操作序列令牌也可通过环境变量COVERITY_TOKEN注入# 1. 构建镜像仅在首次或依赖变更时需要执行 COVERITY_TOKENyour_token ./coverity.sh --build-image # 2. 运行分析并上传结果 COVERITY_TOKENyour_token ./coverity.sh # 3. 仅将已生成的分析包上传到 ossec-wazuh 项目 COVERITY_TOKENyour_token PROJECTossec-wazuh ./coverity.sh --upload # 4. 分析完成后清理生成物 ./coverity.sh --clean若希望控制编译并行度可追加--jobs 4等参数若本地已构建好分析镜像并打了自定义 tag可用--tag tag指定。注意事项--build-image需要从scan.coverity.com下载工具包必须联网且持有有效令牌否则wget拿到的不是合法压缩包镜像构建会失败--upload依赖网络可达 Coverity 上传端点上传失败时脚本会打印响应体并依据 HTTP 状态码退出非零便于在 CI 中直接暴露失败分析对象当前固定为manager 编译目标本地脚本写死TARGETmanager如需分析 agent 目标可参照 5_codeanalysis_coverity.yml 工作流中的target参数用法调整命令本地分析会占用较大磁盘空间cov-int中的发射数据库完成后记得执行./coverity.sh --clean回收空间。【免费下载链接】wazuhWazuh - The Open Source Security Platform. Unified XDR and SIEM protection for endpoints and cloud workloads.项目地址: https://gitcode.com/GitHub_Trending/wa/wazuh创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考