Skip to main content

OCCTET toolkit

Toolkit Results

What the OCCTET toolchain found on every Eclipse Foundation project, on 96 popular open source projects across ten ecosystems and on real SME products, as reported in deliverable D3.3.

On this page

Every Eclipse Foundation project, analysed

All the projects of the Eclipse Foundation have been analysed with the OCCTET toolkit. The OCCTET ORT Server instance holds each project with its GitHub and GitLab repositories, and consolidates repository, package and vulnerability evidence into one operational view of the whole portfolio. The same free, open source toolchain that an SME can deploy scales to the portfolio of an open source foundation.

Eclipse projects
441
GitHub and GitLab repositories
3,600+
Packages detected
80,671
Unresolved vulnerability findings
46,211

A triage backlog to prioritise

46,211 vulnerability findings are still unresolved across the portfolio. Knowing which ones to handle first is what makes this volume manageable: that is the job of the OCCTET Curator and of VEX statements.

About ten of the most downloaded and most widely adopted repositories were selected in each of ten language ecosystems: C/C++, C#, Swift, Rust, Ruby, Python, Go, PHP, JavaScript and the JVM. ORT Server resolved the full transitive dependency graph of each project and checked every package against the OSV and VulnerableCode advisory databases.

Every analysis completed. 74 runs were clean; 22 reported issues, mostly sub-projects that could not be resolved, which often points to build practices worth improving in the project itself.

Projects analysed
96
Language ecosystems
10
Third-party packages identified
6,471
Vulnerability findings
1,195
Severity mix across all findings Advisory–package pairs found by the ORT advisor in the OSV and VulnerableCode databases.
  • Critical 120 10.0%
  • High 508 42.5%
  • Medium 459 38.4%
  • Low 87 7.3%
  • None 21 1.8%
Findings per ecosystem C/C++ and Swift projects carry the most findings. The Go libraries analysed have very few dependencies, none of them vulnerable.
  • C/C++ 488
  • Swift 295
  • Ruby 111
  • Rust 83
  • JavaScript 66
  • JVM 55
  • C# 45
  • Python 27
  • PHP 25
  • Go 0
Top 5 repositories by finding count Findings often sit outside the project's main language: 733 of PromiseKit's 745 dependencies are npm packages, and boost and OpenSSL, both C/C++, depend on Rust crates and Python packages.
  • Critical
  • High
  • Medium
  • Low
  • None
  • mxcl/PromiseKit Swift 253 Critical 60, High 119, Medium 52, Low 22, None 0
  • boostorg/boost C/C++ 157 Critical 18, High 61, Medium 67, Low 11, None 0
  • openssl/openssl C/C++ 129 Critical 0, High 49, Medium 69, Low 11, None 0
  • qt/qtbase C/C++ 100 Critical 4, High 55, Medium 37, Low 4, None 0
  • rails/rails Ruby 94 Critical 5, High 34, Medium 50, Low 5, None 0
Evidence to act on A sample of the package-level evidence ORT Server gives for these repositories (runs of 27 May 2026): every advisory ID, the severity score and the minimum fixed version, where available.
PackageFound inSeverityScoreAdvisory IDsFixed in
axios@1.12.2boostorg/boostCritical10.019≥ 1.13.5
bcprov-jdk18on@1.79qt/qtbaseCritical10.04≥ 1.84
minimist@0.0.8mxcl/PromiseKitCritical9.85≥ 1.2.6
flatted@3.3.1rails/railsCritical9.84≥ 3.4.0
openssl@0.10.71 (Rust crate)openssl/opensslHigh9.310≥ 0.10.78

How findings are counted

Each finding is one advisory matched against one package version of the dependency graph. If one advisory affects five packages, it counts five times: the totals measure the volume to triage, not the number of distinct advisories.

Compared with GitHub dependency insights

Five renowned projects hosted on GitHub were analysed with ORT Server and compared with GitHub’s dependency graph. ORT Server runs the project’s own package managers, so it sees the dependencies as the build resolves them, transitive ones included, without any change to the project.

Dependencies found, per project Runs of March 2026, some updated in May 2026. On GitHub, vulnerabilities would require GitHub Advanced Security, which these projects had not enabled.
ProjectORT ServerGitHubVulnerabilities (ORT Server)What explains the gap
Apache Kafka967451ORT Server finds the Python dependencies declared with ~= (64 vs 25) and the Maven dependencies of a non-standard scope (32 vs 10). GitHub also lists 39 GitHub Actions.
Apache Tomcat405145The same 40 Maven dependencies; the 11 extra entries on GitHub are GitHub Actions.
Eclipse Jetty7255,396104GitHub also counts Maven plugins and the project’s own modules as packages; ORT Server keeps what ships with the product.
Apache Hadoop1,6774,1421,103Maven dependencies are counted differently. GitHub misses the transitive Python dependencies (1 vs 21) and Bower (27); ORT Server could not analyse the NuGet projects.
Eclipse Mosquitto–340C/C++ without a package manager: neither tool can resolve the dependencies, and GitHub only lists GitHub Actions. ORT Server accepts dependencies declared by hand, for example in SPDX.
Key differences
GitHub dependency graphORT Server
Advisory sourceThe GitHub Advisory Database.OSV and VulnerableCode, through ORT advisor plugins; other sources can be plugged in.
Dependency resolutionMostly reads the supported manifest and lock files of the repository.Runs the build’s package managers and resolves the full transitive graph, without changing the project.
CoverageIncludes GitHub Actions workflows.A wider set of package managers; GitHub Actions are not analysed.
ScopeOne repository at a time.Organisations, products and repositories, with dashboards at each level.
Evidence for triageRepository security alerts.Advisory IDs, severity, affected versions, references and minimum fixed versions per package, plus SPDX and CycloneDX SBOMs.
Cost and hostingAdvanced Security features may require a paid plan for private repositories.Free and open source (Eclipse Apoapsis), self-hosted or on the OCCTET instance.

Apart from GitHub Actions, ORT Server generally draws a more complete picture of what ships with the product: transitive and non-standard dependencies are found, and build-time plugins are told apart from distributed components.

Proven on SME products

Broad technology coverage is not only theoretical. Five SME testers set up nine use cases with their real products and delivery models: software products, SaaS deliveries and IoT devices. Four more testers are being set up.

Technology support across SME use cases

8 supported 1 not supported 89%

The unsupported case relies on legacy build tools (Visual Studio Build Tools VC2017 and CMake 3.17.3). Supporting older versions of build systems is out of the project’s scope.

SME testers

  • DH electronics GmbH
  • Mahlo GmbH
  • ReductSoftware UG
  • A-SIT Plus GmbH
  • Obeo S.A.S.

Private dependencies are covered

Some open source testers depended on private repositories without knowing it. ORT Server supports private repositories, so these dependencies are analysed too.

Tester feedback improves the tools

Support for Yocto, used by one tester, was introduced in 2026 and keeps growing with that tester’s feedback.

Boundaries are explicit

Unsupported legacy build systems are identified upfront, which makes adoption planning easier.

Why continuous monitoring matters

On ReductStore, a first run found 116 vulnerability findings. A second run, with no code change at all, found 121: five new vulnerabilities had been published for its transitive dependencies in between. Scheduled runs catch them without waiting for the next release.

From findings to CRA evidence

Findings are only the start. The OCCTET Curator retrieves the ORT Server results through its API and adds review, enrichment and export, so that the outcome is auditable security documentation.

  1. ORT Server Scan results and SBOM
  2. OCCTET Curator Review and triage
  3. Local AI Classification and enrichment
  4. SBOM + VEX Curated outputs for the CRA documentation
  • Curates vulnerabilities, licences, copyrights and component metadata
  • Helps detect false positives and classify licences with local language models, so no data leaves your infrastructure
  • Enriches components with metadata from sources such as AboutCode, ClearlyDefined and deps.dev, keyed by Package URL (PURL)
  • Records exploitability decisions as VEX statements
  • Exports validated SBOMs (SPDX 2.3 and 3.0, CycloneDX) with annotated vulnerability information

The Curator was validated with SME testers, on ReductSoftware’s ReductStore and on Obeo’s Sirius Web, where it detected 1,148 components and 48 vulnerabilities and generated the SBOM. It was also run on open source projects in .NET, Python, Swift, Go, Ruby, the JVM and JavaScript, and on iconic projects such as Adoptium, the Eclipse IDE, Eclipse Mosquitto, Apache Tomcat and Apache Kafka.

Run the toolchain on your own code

The tools are open source. Use the hosted OCCTET instances as a tester, or deploy them yourself.

New to the toolchain?

The getting started guide takes you from your first project to reviewed evidence, step by step.

Get started

Back to the top