oss-analyzer

100% 开源代码分析套件（安全与合规），适用于 GitLab CI 和 GitHub Actions —— 涵盖 SCA、SAST、密钥和许可证，由 单一版本化策略驱动。支持多语言仓库（Go、Rust、Java/JVM、 Python、JS/TS、C/C++）。无 SaaS，不向第三方发送代码。

快速开始

oss-analyzer 在 CI 中依据安全与合规要求对仓库进行门禁检查：它 运行扫描器，应用单一版本化策略并给出一个判定结果， 附带 HTML 仪表板和合并请求报告。

flowchart LR
    repo["Your repository"]
    subgraph checks["Scanners: they collect, never block"]
        deps["Dependencies<br/>Syft SBOM<br/>Grype, OSV-Scanner"]
        licenses["Licenses<br/>license gate on the SBOM<br/>policy-licenses.yml"]
        code["Code<br/>Semgrep<br/>policy-semgrep.yml"]
        secrets["Secrets<br/>Gitleaks, whole git history<br/>policy-gitleaks.toml"]
        iac["Dockerfiles, IaC<br/>Trivy"]
        headers["SPDX headers<br/>REUSE"]
    end
    policy{{"Policy<br/>thresholds, modes, exceptions<br/>policy-global.yml"}}
    verdict(["One verdict: pass or block<br/>dashboard, merge request reports"])

    repo --> deps & licenses & code & secrets & iac & headers --> policy --> verdict

policy-* 文件是你的设置，位于你的 security/ 文件夹中：每个文件都是可选的，并补全 oss-analyzer 的默认值（参见自定义 oss-analyzer）。

每个发现都会汇总到一个仪表盘中，这里展示的是一个故意存在漏洞的演示项目（590 个发现，其中 333 个为阻断性）：

有三种运行方式，使用相同的策略并生成相同的报告：

GitLab CI/CD 组件

include:
  - component: gitlab.com/thalesgroup/oss-analyzer/[email protected]

就是这样，在 gitlab.com 上：该组件发布在其 CI/CD Catalog 中，来自 gitlab.com/thalesgroup/oss-analyzer，这是本仓库的只读副本。在只能包含自身项目的自管理实例上，请将该项目的镜像放在该实例上，并通过其在你实例上的路径来引用它；其镜像仍位于 registry.gitlab.com/thalesgroup/oss-analyzer（OSA_IMAGE_REPOSITORY），并以该组件的提交 SHA 打标签。分析在 test 阶段运行，适用于合并请求、默认分支、计划任务和标签；osa_report_aggregate 是唯一可能阻塞的作业。仪表盘在 MR 流水线组件中链接为 OSS security dashboard，MR 的 Reports 标签页会显示发现结果（Security scan、Code Quality）。

• 镜像来自其公共镜像仓库（Docker Hub、ghcr.io），使用固定版本。在镜像仓库镜像（registry mirror）之后，请覆盖 OSA_<TOOL>_IMAGE 输入——参见容器镜像。
• 设置：组织默认设置开箱即用。如需自定义，请添加 security/policy-global.yml、policy-licenses.yml、policy-semgrep.yml、policy-gitleaks.toml 中的任意一个，仅包含你的差异——参见自定义 oss-analyzer。
• 常用输入：

      inputs:
        OSA_DISTRIBUTION_MODEL: distributed   # saas | distributed | oss_library
        OSA_MODE: audit                       # onboarding: report everything, never block
        OSA_JOB_NEEDS: ["build"]              # wait for your build first
  

  每个输入都记录在组件的 CI/CD Catalog 页面以及 templates/analyze.yml 中。
• 带有积压问题的项目：OSA_MODE: audit 会报告所有内容，且 不阻止任何内容。OSA_GATE_SCOPE: new 会持续阻止新增问题：在 合并请求上，只有尚未出现在目标分支最近一次 成功报告中的问题才会被阻止；在其他情况下，发现的问题会被报告但不会 阻止（因此需要合并请求流水线）。参见 仅新增发现。
• MR 摘要评论：OSA_ENABLE_MR_COMMENT: true 会将判定结果、 阻止性发现以及仪表盘链接作为一条评论发布，并由 每条流水线更新。它需要在掩码的 OSA_GITLAB_TOKEN CI/CD 变量中配置一个项目访问令牌（作用域 api，角色 Reporter）。
• Maven 项目：Maven Central 会限制共享运行器，随后 解析出的依赖图会丢失。OSA_MAVEN_MIRROR_URL（例如你的制品仓库的 Maven Central 远程仓库），如果 需要凭据，则配合掩码的 OSA_MAVEN_MIRROR_AUTH 变量，改为通过镜像进行解析—— 参见 已知陷阱。
• 版本：固定一个次版本（@0.4 会跟随其补丁版本）。0.x 接口在 1.0.0 之前仍可能发生变化：破坏性变更会提升 次版本号，参见 CHANGELOG.md。

GitHub Actions 可复用工作流

jobs:
  security:
    uses: ThalesGroup/oss-analyzer/.github/workflows/security.yml@<ref>
    with:
      oss-analyzer-repository: ThalesGroup/oss-analyzer
      oss-analyzer-ref: <ref>   # the same ref as in `uses:`

输入、权限与密钥：参见 GitHub Actions。

本地分析，无需 CI

无需设置 CI，即可分析收到的项目归档文件（.zip、.tar.gz）或文件夹：

security/scripts/analyze-archive.sh my-project.zip

报告和 HTML 仪表盘会生成在 security-reports/<project-name>/ 下——参见 Usage。

文档

完整文档见 security/README.md： 安装配置、每一项输入与设置、报告、已知陷阱。 CHANGELOG.md 列出了各版本，破坏性变更排在最前。

为什么选择 oss-analyzer

针对每类关注点，都有优秀的开源扫描器：Semgrep、Gitleaks、 Syft、Grype、OSV-Scanner、Trivy、cdxgen、REUSE。团队缺少的 很少是再多一个扫描器。缺的是它们之间的那一环：一个统一的决策，而 不是一堆报告；规则被写下来，而不是靠记忆；许可证被像 CVE 一样认真对待。 oss-analyzer 就是这一环。

一次分析，覆盖整个软件

每次运行都会同时审视你所交付内容的三个层面：

• 你自己的代码：SAST（Semgrep，registry 规则包加上内部规则）、 整个 git 历史中的密钥（Gitleaks）、SPDX 头（REUSE）。
• 你所依赖的内容：一份 SBOM（Syft，加上 cdxgen 为 Maven/Gradle 解析出的依赖图）同时供给漏洞扫描（Grype，并以 OSV-Scanner 作为第二意见）和许可证门禁，因此安全与 合规判断的是同一份组件清单。
• 你所交付的内容：Dockerfile 和 IaC，以及构建出的容器 镜像（Trivy）。

它的独特之处

• 一个结论。 扫描器只负责收集；由一个作业对它们的 发现去重、应用策略并做出决定。
• 没有盲区。 没有留下报告的扫描器会像发现项一样阻断： 流水线变绿意味着一切都已检查过。
• 策略即代码。 阈值、例外、许可证清单、SAST 和 密钥规则都存放在仓库中，像代码一样接受评审；项目只需 写出与组织默认值的差异。
• 例外会过期。 每个例外都有原因、审批人和到期 日期，到期后该发现项会重新阻断。
• 认真对待许可证。 允许 / 复核 / 拒绝清单和 SPDX 表达式按 SPDX 的定义解析（OR、AND、WITH）。
• 渐进式采用。 审计模式，或只阻断合并请求 新增的内容，让有积压问题的项目今天就能开始。
• 处处同一引擎。 GitLab 组件、GitHub workflow，或 针对文件夹或收到的归档运行的本地脚本。
• 无需托管，可复现。 没有服务器、没有 SaaS、代码不外发； 每个工具镜像都固定版本，因此同一版本的分析方式始终一致。

对比

截至 2026 年 10 月的快照，依据各项目的文档。

工具	它是什么	与 oss-analyzer 的对比
MegaLinter（安全版本）	在 CI 中运行多种 linter 和扫描器（Semgrep、Grype、Syft、Trivy、密钥扫描器等）	在运行这些工具方面最为接近；每个工具按各自的设置独立阻断，没有共享策略、带日期的例外或许可证门禁
SecObserve	漏洞与许可证管理服务器，带有 CI 模板和安全门禁	在分类处置和门禁方面最为接近；需要服务器和数据库
DefectDojo、Dependency-Track	聚合发现结果或随时间监控 SBOM 的平台	互补：它们负责跟踪，oss-analyzer 在 CI 中执行门禁。oss-analyzer 会将其 SBOM 上传到 Dependency-Track
OSS Review Toolkit	以策略即代码方式实现深度许可证合规，并带有漏洞顾问	在许可证方面更深入，但没有 SAST 或密钥扫描，运行更重
OWASP dep-scan	依赖漏洞与许可证，带可达性分析	仅 SCA；没有 SAST 或密钥扫描
单独使用 Trivy	在一个二进制文件中提供漏洞、密钥、IaC、许可证扫描	是 oss-analyzer 的扫描器之一；没有 SAST，也没有跨工具的共享策略
GitLab Ultimate 安全扫描	GitLab 内置的 SAST、依赖、密钥和许可证扫描	付费层级；oss-analyzer 可在所有 GitLab 版本和 GitHub 上运行，并且在可用时仍会填充 Ultimate 的合并请求小组件