D4.1 – Ready-to-Use Installation of the OCCTET Toolkit #

Reference installation of the OCCTET toolkit as a containerised cloud service, with its documentation

1. Document information #

Version history

Legal notice. This deliverable has been produced within the OCCTET project (Grant Agreement No. 101190474) funded under the Digital Europe Programme. Co-funded by the European Union. Views and opinions expressed are however those of the author(s) only and do not necessarily reflect those of the European Union or the European Cybersecurity Industrial, Technology and Research Competence Centre. Neither the European Union nor the granting authority can be held responsible for them.

2. Executive summary #

Deliverable D4.1 describes the reference implementation of the OCCTET toolkit and provides deployment and operational documentation written in English and maintained in Markdown. Built entirely from components released under open-source licences, the reference implementation is publicly available on GitLab for anyone to deploy.

The reference instance runs as a containerised service on cloud infrastructure, in line with Task T4.3. Ongoing work focuses on assessing operational scalability and establishing a path towards a fully operational software-as-a-service offering.

Scope of the reference instance.

Four services run on OVHcloud Managed Kubernetes in Strasbourg, France:

• ORT Server: automated dependency, licence and vulnerability analysis: https://ort-server.occtet.eu
• Occtet Curator: SBOM curation and assessment: https://curator.occtet.eu
• VulnerableCode: vulnerability database: https://vulnerablecode.occtet.eu
• Keycloak: single sign-on shared by ort-server and the curator: https://keycloack.occtet.eu

For vulnerability data, ORT Server and the Curator query 2 external services: OSV and the public VulnerableCode service, https://public.vulnerablecode.io or the OCCTET instance: https://vulnerablecode.occtet.eu, part of the federated software metadata platform developed in WP3 (D3.1, D3.4).

Installation

Every component is installed with Helm. Upstream, these are the Eclipse Apoapsis chart for ORT Server, the Bitsea chart for the Curator and the CloudPirates chart for Keycloak. VulnerableCode is installed with an OCCTET specific helm chart. The OCCTET-specific deployment material is kept in 8 repositories of the Eclipse Foundation GitLab group occtet-eu/reference-installation. One of them, occtet-helm-chart, installs the whole platform, one Helm release per component. GitLab CI also deploys the ORT Server stack, the Curator and Keycloak on every merge.

Validation evidence

Operations and continuity

Following the project’s closure on 31 October 2026, the Eclipse Foundation will continue hosting the platform until early 2027.

The software will remain available beyond the lifetime of the hosted reference instance. ORT Server is developed within Eclipse Apoapsis, an Eclipse Foundation project. The other components are also publicly available on GitHub under open-source licences, allowing continued use, community contributions and independent deployments (Section 15.1, Hosting and continuity).

3. Table of contents #

• 1. Document information
• 2. Executive summary
• 3. Table of contents
• 4. Introduction
  • 4.1. Purpose and scope
  • 4.2. Grant Agreement reference
  • 4.3. Relationship to WP3 deliverables and to D4.2
  • 4.4. Expected results of task T4.3
  • 4.5. Delivered artefacts
  • 4.6. Components and scope
• 5. Reference instance and access
  • 5.1. Public endpoints
  • 5.2. Component versions
  • 5.3. Access modalities for partners
  • 5.4. Programmatic access: API, CLI and CI
• 6. Architecture
  • 6.1. Overview
  • 6.2. Hosting platform
  • 6.3. Namespace layout
  • 6.4. Entry point and reverse-proxy layer
  • 6.5. Identity service: Keycloak
  • 6.6. Analysis service: ORT Server
  • 6.7. Curation service: Occtet Curator
  • 6.8. Vulnerability database: VulnerableCode
  • 6.9. Integration chain
• 7. Customisation and branding
  • 7.1. Keycloak theme keycloak-occtet-theme
  • 7.2. ORT Server branding (footer)
  • 7.3. VulnerableCode branding
  • 7.4. EU visibility
• 8. Security architecture
  • 8.1. Network and transport
  • 8.2. Identity and authentication
  • 8.3. Authorisation model
    • 8.3.1. Granting permissions
  • 8.4. Secrets management
  • 8.5. Workload separation and supply chain
  • 8.6. Administrative access
• 9. Monitoring and observability
  • 9.1. Logs
  • 9.2. Resource metrics and health checks
  • 9.3. Job supervision, housekeeping and retention
  • 9.4. Statistics dashboards
  • 9.5. Current limits
• 10. Prerequisites
• 11. Installation
  • 11.1. Getting the deployment material
  • 11.2. Installation order
  • 11.3. Step 1 – Cluster
  • 11.4. Step 2 – Ingress controller and DNS
  • 11.5. Step 3 – Certificate management
  • 11.6. Step 4 – Keycloak
  • 11.7. Step 5 – ORT Server
  • 11.8. Step 6 – Occtet Curator
  • 11.9. Step 7 – VulnerableCode
  • 11.10. Step 8 – Entry point and verification
• 12. Local installation on minikube
• 13. Onboarding and usage
  • 13.1. Onboarding process and checklist
  • 13.2. Using ORT Server
  • 13.3. Using Occtet Curator
  • 13.4. Automation for large portfolios
• 14. Demonstration and validation
  • 14.1. Scenario A – Integration test between the Curator and ORT Server
  • 14.2. Scenario B – Analysis campaign on the Eclipse Foundation portfolio
  • 14.3. SME use cases and feedback
  • 14.4. Iconic open source projects
  • 14.5. General open source ecosystem benchmark
  • 14.6. Consolidated results of the instance
  • 14.7. Limits observed
  • 14.8. Assessment against the Grant Agreement commitments
• 15. Operations, continuity and costs
  • 15.1. Hosting and continuity
  • 15.2. Maintenance and upgrades
  • 15.3. Infrastructure cost estimate (one year)
  • 15.4. Scalability
  • 15.5. Operational readiness matrix
• 16. Conclusion
• 17. References
• 18. Annex A: Glossary
• 19. Annex B: Statistics – detailed results and definitions
• 20. Annex C: Reference images
• 21. Annex D: Configuration reference
  • 21.1. ORT Server
  • 21.2. Occtet Curator
  • 21.3. VulnerableCode
    • 21.3.1. Public service
    • 21.3.2. Local instance
  • 21.4. Recommended proxy configuration
  • 21.5. Kubernetes Secrets
  • 21.6. Resource requests and persistent volumes

4. Introduction #

4.1. Purpose and scope #

This document describes the reference installation delivered by task T4.3. It is written for three audiences:

• Project reviewers find what was delivered and how it was validated in sections 2 (Executive summary) and 4 (Introduction) to 9 (Monitoring and observability), then 14 (Demonstration and validation) to 16 (Conclusion).
• Organisations that reproduce the installation follow the installation procedure of sections 10 (Prerequisites), 11 (Installation) and 12 (Local installation on minikube), with the configuration reference of Annex D.
• Partners who use or operate the toolkit find access, onboarding and usage in sections 5 (Reference instance and access) and 13 (Onboarding and usage).

Annexes A to C hold the glossary, the detailed results and definitions of the statistics, and the container images; Annex D holds the configuration reference.

The document describes the installation as configured in its deployment repositories and measurements on the instance (statistics, storage use, costs) date from 30 October 2026. Section 14 states the sources of the validation figures, and Annex B gives the definitions of the statistics of the instance and the script that extracts them.

4.2. Grant Agreement reference #

D4.1 corresponds to a deliverable card of Work Package 4 in Annex 1 of the Grant Agreement. Its official description is: “Reference implementation available to partners with a documented process in English using markdown”. It is a public demonstrator, due at month 24 (31 October 2026) and led by Double Open. It evidences the following commitments:

• WP4, objective 2. Set up a production-ready reference implementation that easily onboards external SMEs and iconic open source projects.
• Task T4.3. Exploit the tools defined in WP3 to create a reference, ready-to-use, software-as-a-service solution. The solution is deployed on cloud infrastructure using container technology and is included in a whole toolchain. It must prove the feasibility of offering the service at scale and show the path to a fully operational SaaS (section 4.4, Expected results of task T4.3).
• Milestone 8 – SME validation, month 24. Written actionable feedback from SMEs that have tested the framework and tools on at least 15 of their projects or solutions (section 14.3).
• Milestone 9 – FOSS validation, month 24. Well-established open source foundations, Eclipse and Apache, run the tool on iconic projects to initiate a federated database (section 14.4).
• Open source and EU visibility. Part B of the Grant Agreement commits the toolkit to an open source licence. The installation and its documentation carry the funding acknowledgement required of all public deliverables (section 7.4).

4.3. Relationship to WP3 deliverables and to D4.2 #

D4.1 builds on the toolkit deliverables of Work Package 3:

• D3.1 – FedDB Beta (month 6, lead AboutCode) established the first demonstrator of the federated and shared software metadata platform.
• D3.2 – BasicChain (month 12, lead Bitsea) released a beta of all WP3 tools in downloadable and installable form. It was the first point at which the tools could be called one after another.
• D3.3 – Toolkit Demo (month 17, extended to version 1.1 in May 2026, lead Bitsea) demonstrated the toolkit on WP4 use cases. It is the source of the SME, iconic-project and open source testing summarised in section 14.
• D3.4 – Federated Database Final (month 17, lead AboutCode) delivered the final release of the federated platform: VulnerableCode and the wider AboutCode/FederatedCode ecosystem. It extends the platform from vulnerability data to package origin, licence metadata and complete CycloneDX SBOMs, identified by package URL. The public VulnerableCode service is, with OSV, a data source of the ORT Server advisor, and the data source of the Curator’s vulnerability service (section 21.3).

D4.2 – Tools Comparison Report describes the testing framework used to validate the tools and compares the OCCTET tools with other solutions. It contains the full analysis of the SME feedback summarised in section 14.3.

4.4. Expected results of task T4.3 #

Section 14.8 (Assessment against the Grant Agreement commitments) assesses each of these results.

4.5. Delivered artefacts #

The deployment repositories belong to the group occtet-eu/reference-installation of the Eclipse Foundation GitLab, abbreviated `` below.

All these repositories are public. The OCCTET deployment material is licensed under the Eclipse Public License 2.0, except the Keycloak theme, which keeps the MIT licence of the Keycloakify starter it derives from, and the ORT Server configuration, which keeps the Apache 2.0 licence of the ORT Server example configuration. Annex C lists the container images of the installation and their versions.

4.6. Components and scope #

5. Reference instance and access #

5.1. Public endpoints #

5.2. Component versions #

Versions of the reference state, as configured in the deployment repositories on 15 October 2026:

5.3. Access modalities #

Requesting access. Organisations request access by e-mail to [email protected], as described in the toolkit’s getting-started guide (https://occtet.eu/toolkit/getting-started/). The request gives the organisation, the tools to try, the technologies of the project and whether the repository is public or private. It never contains credentials.

ORT Server and the Curator share the Keycloak realm occtet, so one account gives access to both. Access is granted in three steps.

1. First sign-in. The user opens either tool and is redirected to the OCCTET login page. There they either create an account, using their e-mail address as user name and choosing a password, or select Sign in with GitHub.
2. Automatic access. Every hour, a scheduled job gives every account of the realm read access to the public organisations of ORT Server, and the realm role curator, which opens the Curator (section 8.3.1, Granting permissions). A new user therefore reads the results of the public organisations within the hour after the first sign-in, without waiting for an administrator.
3. Permissions by profile. An administrator grants the other permissions according to the user’s profile.

The public organisations of ORT Server hold the results of open source projects only:

The organisations of SMEs and partners are not public: only the users an administrator adds to them can see them. Permissions by profile:

The OCCTET VulnerableCode instance, https://vulnerablecode.occtet.eu, is not connected to the realm: anyone can query it without an account (section 6.8, Vulnerability database: VulnerableCode). Partners can also query the public VulnerableCode service, with an API key of their own (section 5.1, Public endpoints).

5.4. Programmatic access: API, CLI and CI #

Interactive token. The page https://ort-server.occtet.eu/profile/token uses the public client ort-server-cli to issue an offline refresh token for the osc CLI and for scripts. Exchange it for an access token, then call the API:

REFRESH_TOKEN='<token copied from /profile/token>'

ACCESS_TOKEN=$(curl -s -X POST \
  https://keycloack.occtet.eu/realms/occtet/protocol/openid-connect/token \
  -d grant_type=refresh_token \
  -d client_id=ort-server-cli \
  -d refresh_token="$REFRESH_TOKEN" | jq -r .access_token)

curl -H "Authorization: Bearer $ACCESS_TOKEN" \
  https://ort-server.occtet.eu/api/v1/organizations

The API answers 401 when the token lacks the ort-server audience or has the wrong issuer. It answers 403 when the token is valid but the user has no permission on the resource.

CI pipelines. The confidential client ort-ci generates a user token. Projects store that token in their CI and use it to trigger analyses through the API.

CLI discovery. GET https://ort-server.occtet.eu/api/v1/auth/oidc-config/cli returns the token endpoint and the client ID the CLI must use.

6. Architecture #

6.1. Overview #

flowchart TB
    users(["Users, partners and SMEs<br/>browsers, osc CLI, CI pipelines"])
    lb["OVHcloud Public Cloud Load Balancer, size S<br/>with Floating IP and Gateway"]
    ext["External services<br/>public VulnerableCode, OSV, advisory sources,<br/>Git hosting, container registries, Let's Encrypt"]

    users -->|"HTTPS"| lb

    subgraph mks["OVHcloud Managed Kubernetes Service - SBG5 Strasbourg - 6 nodes"]
        subgraph nsing["namespace ingress-nginx"]
            ic["ingress-nginx controller<br/>TLS termination"]
        end
        subgraph nscm["namespace cert-manager"]
            cm["cert-manager<br/>Let's Encrypt ClusterIssuer"]
        end
        subgraph nsdef["namespace default - entry point"]
            ing["Ingress per host name"]
            pxo["nginx proxy<br/>ORT Server"]
            pxc["nginx proxy<br/>Curator"]
            pxk["nginx proxy<br/>Keycloak"]
            pxv["nginx proxy<br/>VulnerableCode"]
        end
        subgraph nsort["namespace ort-server"]
            oui["ORT Server UI"]
            ocore["ORT Server core<br/>REST API"]
            oorch["Orchestrator"]
            owk["Workers as Kubernetes Jobs<br/>config, analyzer, advisor,<br/>scanner with ScanCode, evaluator, reporter"]
            omq[["RabbitMQ"]]
            odb[("PostgreSQL")]
            oobs["Loki, Promtail, Grafana"]
        end
        subgraph nscur["namespace curator"]
            cfe["Curator frontend /boc"]
            cms["13 microservices"]
            cnats[["NATS JetStream"]]
            cdb[("PostgreSQL + pgvector")]
            cai["Ollama LLM"]
            cnfs["NFS provisioner<br/>shared project data"]
        end
        subgraph nskc["namespace keycloak"]
            kc["Keycloak<br/>realm occtet, OCCTET theme"]
            kdb[("PostgreSQL")]
        end
        subgraph nsvc["namespace vulnerablecode"]
            vweb["VulnerableCode web<br/>UI and REST API"]
            vwk["RQ scheduler and workers<br/>importer and improver pipelines"]
            vredis[["Redis"]]
            vdb[("PostgreSQL")]
        end
    end

    lb --> ic --> ing
    cm -.->|"certificates"| ing
    ing --> pxo & pxc & pxk & pxv
    pxo -->|"/"| oui
    pxo -->|"/api"| ocore
    pxc --> cfe
    pxk --> kc
    pxv --> vweb
    ocore --> omq
    oorch --> omq
    oorch --> owk
    ocore --> odb
    owk --> odb
    ocore -.->|"run logs"| oobs
    cfe --> cnats
    cms --> cnats
    cfe --> cdb
    cms --> cdb
    cms --> cai
    cfe --> cnfs
    kc --> kdb
    vweb --> vdb
    vweb --> vredis
    vwk --> vredis
    vwk --> vdb
    cms -->|"ORT Server API, public URL"| ocore
    owk --> ext
    cms --> ext
    vwk -->|"advisory imports"| ext

Figure 1 – Reference architecture of the installation.

Four principles shape the architecture:

• One entry point. A single load balancer and ingress controller serve all four host names. TLS is terminated at the ingress, then a dedicated reverse proxy per service, in namespace default, forwards requests to the service’s namespace.
• One namespace per service. Keycloak, ORT Server, the Occtet Curator and VulnerableCode each run in their own namespace. Each has its own database and is managed as its own Helm release, with its own lifecycle.
• Helm everywhere. Every component is installed and upgraded with a Helm chart, as its own release. The entry point has its own chart, occtet-entrypoint, and the repository occtet-helm-chart orchestrates all the releases (section 11).
• Shared identity. ORT Server and the Curator trust the realm occtet through its public issuer URL.

6.2. Hosting platform #

6.3. Namespace layout #

6.4. Entry point and reverse-proxy layer #

A request travels as follows:

C4Deployment
    title Path of a request to a public host name

    Person(client, "Client", "Browser, osc CLI, script or CI pipeline")

    Deployment_Node(ovh, "OVHcloud Public Cloud", "Region SBG5, Strasbourg") {
        Container(lb, "Load Balancer", "OVHcloud Public Cloud Load Balancer", "Floating IP of the four host names")
        Deployment_Node(mks, "Managed Kubernetes cluster", "OVHcloud MKS") {
            Deployment_Node(ns_ingress, "ingress-nginx", "Namespace") {
                Container(controller, "ingress-nginx controller", "nginx", "TLS termination; certificates from cert-manager")
            }
            Deployment_Node(ns_default, "default", "Namespace") {
                Container(ingress, "Ingress of the host name", "Ingress", "One per host name, read by the controller")
                Container(proxy, "Reverse proxy of the service", "nginx", "Path filtering, forwarded headers")
            }
            Deployment_Node(ns_service, "Namespace of the service", "ort-server, curator, keycloak or vulnerablecode") {
                Container(service, "Service", "Kubernetes Service", "Reached by its cluster DNS name")
            }
        }
    }

    Rel(client, lb, "1. Request", "HTTPS")
    Rel(lb, controller, "2. Forwards", "TCP")
    Rel(controller, ingress, "3. Applies the host rule")
    Rel(ingress, proxy, "4. Routes", "HTTP")
    Rel(proxy, service, "5. Forwards", "HTTP")

    UpdateRelStyle(client, lb, $offsetX="10", $offsetY="-40")
    UpdateRelStyle(lb, controller, $offsetX="-90", $offsetY="-60")
    UpdateRelStyle(controller, ingress, $offsetX="-55", $offsetY="-30")
    UpdateLayoutConfig($c4ShapeInRow="2", $c4BoundaryInRow="3")

Figure 2 – Path of a request through the entry point (C4 deployment view). TLS ends at the ingress controller; inside the cluster, the request travels in plain HTTP.

The reverse proxy reaches the service by its cluster DNS name, <service>.<namespace>.svc.cluster.local, given for each host name in the column Upstream of the table below.

The Ingresses, proxies and ClusterIssuers are defined by the chart occtet-entrypoint of occtet-helm-chart, whose values hold the ACME contact address; the Makefile gives it the domain of the host names (DOMAIN). All four proxies use the nginx:stable image, read their configuration from a ConfigMap, and expose a local /alive endpoint. The chart uses /alive for the readiness and liveness probes of the proxies and for its Helm test.

6.5. Identity service: Keycloak #

• Chart. Wrapper chart occtet-keycloak 1.0.0, in the repository occtet-keycloak. It depends on the CloudPirates keycloak chart 0.21.46, published as OCI artefact oci://registry-1.docker.io/cloudpirates and pinned in Chart.yaml. It deploys Keycloak 26.8.0, with the image pinned by digest, and a bundled PostgreSQL 18 database. The Keycloak version follows the CloudPirates chart version.
• Deployment. GitLab CI deploys the chart on every merge to the default branch, through the GitLab Agent of namespace keycloak, and Renovate proposes the chart updates. Keycloak migrates its database schema at start-up (section 15.2, Maintenance and upgrades).
• Mode. Production mode, with proxyHeaders: xforwarded. The Service is of type ClusterIP and the chart’s own Ingress is disabled; Keycloak is published through the entry point instead. Its resource requests and limits are in section 21.6.
• Credentials. The password of the bootstrap administrator comes from the Secret keycloak-admin-secret, created before installation and read only at the first start. The chart generates the database password at the first installation, in the Secret occtet-keycloak-postgres (section 21.5).
• Theme. The theme is installed at start-up by an initContainer (section 7.1).

6.6. Analysis service: ORT Server #

ORT Server is installed with the umbrella chart prod-stack (0.1.1) of the repository occtet-ort-server-helm-chart. The repository does not keep a Chart.lock; the exact dependency versions below are pinned in Chart.yaml. GitLab CI deploys the chart on every merge to the default branch, through the GitLab Agent of namespace ort-server.

Runtime components

• The core serves the REST API and enforces authentication and authorisation.
• The UI is the web front end.
• The orchestrator drives each run through its pipeline.
• The workers are the six pipeline stages: config, analyzer, advisor, scanner (ScanCode), evaluator and reporter. Each one runs as a short-lived Kubernetes Job.

The core, the orchestrator and the workers exchange messages through RabbitMQ. Worker executions are started as Kubernetes Jobs, with CPU and memory requests and limits set per worker (section 21.6).

Configuration and data

• Configuration files. A Git-based configuration provider reads the parameter validation script, policy rules and licence classifications from the repository occtet-ort-server-config (section 21.1).
• User secrets. Secrets users create in ORT Server are stored encrypted in the ORT Server database.
• Worker logs. The log file service fetches worker logs from Loki.

6.7. Curation service: Occtet Curator #

The Curator is installed with the umbrella chart occtet-curator-stack (0.1.0) of the repository occtet-curator-helm-chart (section 4.5), the same layout as the ORT Server repository (section 6.6). Its only dependency is the Bitsea chart occtet-curator, pinned in Chart.yaml, whose package carries its own PostgreSQL and NFS provisioner dependencies. The repository holds no chart templates: its values.yaml only sets what the OCCTET instance changes in the defaults of the Bitsea chart, under the key occtet-curator (section 21.2), and its values-dev.yaml the overrides of the local installation (section 12). GitLab CI deploys the repository root with values.yaml on every merge to the default branch, through the GitLab Agent of namespace curator.

The Curator images are pulled from ghcr.io/bitsea with the latest tag and pull policy Always. Annex C lists them.

6.8. Vulnerability database: VulnerableCode #

Besides the public VulnerableCode service (section 21.3, VulnerableCode), the platform runs its own VulnerableCode instance, in namespace vulnerablecode, published through the entry point at https://vulnerablecode.occtet.eu.

Chart. The instance is installed from the repository occtet-vulnerablecode-helm-chart (section 4.5), with the OCCTET chart vulnerablecode 0.0.1. The chart mirrors the upstream docker-compose.yml: same image, same commands, and nginx in front of gunicorn. It deploys VulnerableCode 40.1.0 (image ghcr.io/aboutcode-org/vulnerablecode), with the CloudPirates postgres chart 0.21.1 (PostgreSQL 18.6) and redis chart 0.36.0 (Redis 8.10.2), both locked by Chart.lock. The chart’s own Ingress is disabled.

With the values of the repository, the instance requests 2.75 vCPU and about 8.4 GiB of memory in total, on the node pool it shares with the other services (section 21.6).

Data. The importer pipelines collect advisories from public sources such as NVD, GitHub, OSV and Linux distributions.

Access. The instance is open on the Internet at https://vulnerablecode.occtet.eu. The web UI and the REST API need no account, because config.requireAuthentication is false, and anonymous API calls are throttled to 10 per minute.

Use by the toolchain. ORT Server can use either instance: the advisor configuration of a run selects the public service, which is the default, or the OCCTET instance, with its serverUrl. The vulnerability service of the Curator queries the public service, whose address is fixed in its code (section 21.3, VulnerableCode).

6.9. Integration chain #

ORT Server and the Curator work together in two ways. Both end the same way: the Curator imports the results of the finished ORT run, and they are curated there. Both rely on the shared realm occtet and on the technical ORT account of the Curator, an ORT Server superuser (section 8.3.1, Granting permissions).

A – ORT Server as entry point. An ORT Server user, a script or a CI pipeline creates the organisation, the product and the repository in ORT Server, then starts the runs (section 13.2, Using ORT Server). Nothing has to be configured in the Curator: every two minutes, it looks for the runs that have finished, creates an organisation and a project named after the ORT organisation and product if they do not exist, and imports the results. The data is then curated in the Curator. A Curator user sees the imported project once a Curator admin has added them to its organisation (section 8.3.1, Granting permissions). This is how the runs of the analysis campaigns reach the Curator.

sequenceDiagram
    autonumber
    actor U as ORT Server user, script or CI
    participant KC as Keycloak realm occtet
    participant ORT as ORT Server API and orchestrator
    participant W as ORT workers
    participant VC as VulnerableCode and OSV
    participant FE as Curator frontend
    participant PR as Process Run service
    participant VS as Vulnerability service
    actor C as Curator user
    U->>KC: Sign in, or exchange the offline token of /profile/token
    KC-->>U: Access token with audience ort-server
    U->>ORT: Create organisation, product and repository (UI, API, osc or portfolio scripts)
    U->>ORT: Start a run
    ORT->>W: Jobs config, analyzer, advisor, scanner, evaluator, reporter
    W->>VC: Advisor queries to OSV and VulnerableCode
    W-->>ORT: Results, SBOMs and reports stored
    loop Every 2 minutes
        FE->>ORT: Latest runs finished or finished with issues (technical ORT account)
        FE->>PR: NATS subject work.ortProcessRun, for each run not processed yet
        PR->>ORT: Read the SPDX or CycloneDX report, ORT issues and rule violations
    end
    PR-->>FE: Organisation and project created if missing, named after the ORT organisation and product, then results imported
    FE->>VS: Vulnerability lookup request over NATS
    VS->>VC: VulnerableCode bulk package query
    C->>FE: Curate inventory items, write VEX, export SPDX or CycloneDX

Figure 3 – A: ORT Server as entry point. Steps 12 to 14, the Curator’s vulnerability lookup and the curation, VEX and export, have not been validated on the instance (section 14.1, Scenario A – Integration test between the Curator and ORT Server).

B – Curator as entry point. A Curator user creates a project, with the URL and the version of the repository, and starts an analysis with ORT Starter (section 13.3, Using Occtet Curator). With the technical ORT account, the Curator’s ORT Run Start service creates in ORT Server the organisation, the product and the repository, if they are missing, named after the Curator organisation and project. It then starts the run on the version of the project. For a private GitHub repository, it also stores the GitHub token of the project as secrets of the ORT product. The finished run is imported as in A.

sequenceDiagram
    autonumber
    actor U as Curator user
    participant FE as Curator frontend
    participant KC as Keycloak realm occtet
    participant RS as ORT Run Start service
    participant ORT as ORT Server API and orchestrator
    participant W as ORT workers
    participant PR as Process Run service
    participant VS as Vulnerability service
    participant VC as VulnerableCode and OSV
    U->>FE: Open curator.occtet.eu
    FE->>KC: OpenID Connect authorization code flow
    KC-->>FE: Tokens including realm roles
    U->>FE: Create project and start an ORT run (repository type, URL, version)
    FE->>RS: NATS subject work.ortRunStarter
    RS->>KC: Token request for the technical ORT account
    KC-->>RS: Access token with audience ort-server
    RS->>ORT: Create organisation, product and repository if missing, then start the run
    ORT->>W: Jobs config, analyzer, advisor, scanner, evaluator, reporter
    W->>VC: Advisor queries to OSV and VulnerableCode
    W-->>ORT: Results, SBOMs and reports stored
    loop Every 2 minutes
        FE->>PR: NATS subject work.ortProcessRun
        PR->>ORT: Read run status and results
    end
    PR-->>FE: Components, licences, copyrights, ORT issues and rule violations imported
    FE->>VS: Vulnerability lookup request over NATS
    VS->>VC: VulnerableCode bulk package query
    U->>FE: Curate inventory items, write VEX, export SPDX or CycloneDX

Figure 4 – B: the Curator as entry point. Steps 1 to 14 have been validated on the instance, up to the import of results; steps 15 to 17, the Curator’s vulnerability lookup and the curation, VEX and export, have not been validated (section 14.1, Scenario A – Integration test between the Curator and ORT Server).

In both chains, the advisor of ORT Server queries the public VulnerableCode service or the OCCTET instance, depending on the serverUrl of the run (section 6.8, Vulnerability database: VulnerableCode).

Import of finished runs, in A and B. Every two minutes (setting PROCESS_RUN_CRON), the Curator frontend reads from ORT Server, with the technical ORT account, the most recent run with status finished and the most recent run with status finished with issues. It hands each run it has not processed yet to the Process Run service. That service creates the Curator organisation and project named after the run’s ORT organisation and product, if they do not exist, then imports the SPDX report of the run, or its CycloneDX report when no SPDX report is available, with the ORT issues and rule violations. Runs started outside the Curator, such as the campaign runs of section 13.4, Automation for large portfolios, are therefore imported too. Only the latest run of each status is read at each poll, and the list of processed runs is kept in memory, so some runs can be missed when many finish between two polls.

7. Customisation and branding #

7.1. Keycloak theme keycloak-occtet-theme #

• Origin. The theme is a clone of the Eclipse Foundation’s Keycloak theme “Solstice” (https://gitlab.eclipse.org/eclipsefdn/software-dev/frameworks-and-tools/keycloak-solstice-theme), itself built on the Keycloakify starter. It was created in November 2025 as the login theme of ORT Server, then generalised in March 2026 into a single theme for the toolkit.
• Visual identity. The theme carries the OCCTET logo and background, a footer with the funding statement, and the “Co-funded by the European Union” and European Cybersecurity Competence Centre logos.
• Technology. Keycloakify 11 with React 18, PatternFly 5 and i18next. It overrides the login pages (login, OTP, TOTP set-up, WebAuthn, recovery codes, authenticator selection, credential deletion, error and expired-page screens) and provides a single-page account console.
• Repository. The sources are in the repository occtet-keycloak-theme (GitLab project 11564). Storybook is the development environment; the pipeline also publishes it to GitLab Pages.
• Build and distribution. On every merge to the default branch, the GitLab CI pipeline runs yarn build-keycloak-theme, packages the theme as a JAR and publishes it to the Maven package registry of the theme repository. The coordinates are group eclipsefdn.open-source-services.occtet-eu.reference-installation, artifact occtet-keycloak-theme and version 0.0.1; each publication replaces the previous JAR.
• Installation in Keycloak. No custom Keycloak image is needed. An initContainer, using a Maven image pinned by digest, fetches the theme JAR with mvn dependency:get from that public registry. It then extracts it into the shared keycloak-themes volume before Keycloak starts. To put a new theme build live, restart Keycloak: kubectl -n keycloak rollout restart statefulset occtet-keycloak.
• Activation. In the realm occtet, under Realm settings → Themes, the login and account themes are set to keycloak-occtet-theme, the name of the theme in Keycloak.

7.2. ORT Server branding (footer) #

ORT Server has a content-management feature for its user interface. The footer is a Markdown document in which the layout markers ::: align-left and ::: align-right position the blocks.

The OCCTET footer contains:

• the project name and mission;
• the European Cybersecurity Competence Centre and “Co-funded by the European Union” logos;
• the funding statement;
• links to the OCCTET website, the ORT Server instance, the ORT Server source code and its issue tracker.

The Markdown source is ort-footer.md, in the repository occtet-ort-server-helm-chart. An ORT Server administrator applies it as follows:

1. Open Administration → Content Management → Branding.
2. Paste the Markdown into the footer form.
3. Enable the footer and save.

7.3. VulnerableCode branding #

VulnerableCode has no setting for its header or footer. The chart therefore replaces two of its page templates and serves extra static files, without rebuilding the image:

• navbar.html puts the OCCTET logo in the header;
• footer.html adds the funding statement and the “Co-funded by the European Union” and European Cybersecurity Competence Centre logos, above the upstream VulnerableCode credits, which are kept unchanged.

The templates and logos are in the branding/ directory of the repository occtet-vulnerablecode-helm-chart. make deploy-vulnerablecode in occtet-helm-chart passes the templates to the chart (web.customization.templates) and loads the logos into the ConfigMap vulnerablecode-branding; the nginx sidecar serves them under /static/custom/. An overridden template no longer follows upstream changes, so both templates must be compared with the upstream ones whenever VulnerableCode is upgraded.

7.4. EU visibility #

The installation and its documentation carry the funding acknowledgement that the Grant Agreement requires (section 4.2):

• the Keycloak login pages (7.1), the ORT Server footer (7.2) and the VulnerableCode footer (7.3) show the funding statement and the “Co-funded by the European Union” and European Cybersecurity Competence Centre logos;
• the README of every deployment repository of section 4.5 ends with a Funding section: the funding statement and the same logos;
• this document starts with the legal notice and the same logos.

8. Security architecture #

This section describes the controls in place and states their limits. The actions planned before the platform opens as a production service are listed in section 15.5, Operational readiness matrix.

8.1. Network and transport #

• Public endpoints. The four host names are served over HTTPS only. One load balancer and one ingress controller publish them, and plain HTTP requests are redirected to HTTPS. cert-manager obtains and renews the certificates from Let’s Encrypt (ACME, HTTP-01 challenge).- TLS terminated at the ingress. Traffic inside the cluster is not encrypted. This covers ingress → reverse proxy → service, and services → their databases and message brokers (sslMode: disable for ORT Server). Its confidentiality therefore relies on the cluster network.
• Security headers. Keycloak sends HTTP Strict Transport Security for one year including sub-domains, a Content Security Policy restricting framing to the same origin, X-Frame-Options: SAMEORIGIN, X-Content-Type-Options: nosniff, Referrer-Policy: no-referrer and X-Robots-Tag: none.
• Path filtering. The Keycloak proxy publishes only the endpoints that clients and administrators need, and blocks Keycloak’s metrics and health endpoints.
• Internal back-ends. Databases, message brokers and the observability back-ends are not published through the ingress; administrators reach them with kubectl port-forward. Kubernetes NetworkPolicies are applied only in namespace vulnerablecode, where they allow only the VulnerableCode pods to reach its PostgreSQL and Redis. Elsewhere, the cluster network does not restrict traffic between namespaces (section 15.5, Operational readiness matrix).
• DDoS protection. The standard OVHcloud anti-DDoS protection covers the Public Cloud resources.

Data location. The platform stores all its data (databases, volumes, logs) in the OVHcloud Strasbourg region, in France. Some data is nonetheless sent to external services when analyses run:

• Git repositories and package registries, which the analyzer and scanner contact to fetch sources and metadata;
• OSV and the public VulnerableCode service, which receive package identifiers (package URLs) for vulnerability lookups;
• GitHub, when a user signs in with a GitHub account.

The AI-assisted services of the Curator use the local LLM runtime Ollama, inside the cluster (section 6.7), so no data is sent to external AI services. The OCCTET VulnerableCode instance downloads advisory data from public sources. A run that uses it keeps its package identifiers on the platform, instead of sending them to the public VulnerableCode service (section 6.8, Vulnerability database: VulnerableCode).

8.2. Identity and authentication #

The realm occtet provides single sign-on for ORT Server (UI, API, CLI) and the Occtet Curator. It uses OpenID Connect with RS256-signed tokens. VulnerableCode is not connected to it (section 6.8).

• Login methods. Users sign in with a local account, whose user name is their e-mail address, or through the GitHub identity provider. E-mail addresses received from GitHub are not trusted automatically.
• Multi-factor authentication. One-time passwords, WebAuthn security keys and recovery codes are available to users, but not enforced.

The api-access client is shared. Its service account holds the client roles manage-realm, manage-users and manage-clients of realm-management, which ORT Server uses to administer users, groups and roles. The same client is also the Curator’s OpenID Connect client, and the Curator obtains ORT Server tokens through it. The hourly access job also uses its service account, to assign the realm role curator (section 8.3.1, Granting permissions). As a result, the Curator deployment holds the secret of a client that has realm-management rights. Giving the Curator its own client is the first identity hardening action (section 15.5).

ORT Server validates every API token in three ways:

• the signature, against the realm keys;
• the issuer, which must be https://keycloack.occtet.eu/realms/occtet;
• the audience, which must include ort-server.

8.3. Authorisation model #

ORT Server. Permissions follow the hierarchy organisation → product → repository. At each level a user can be assigned the reader, writer or admin role. ORT Server stores the assignments, including the superuser status, in its own database. An existing superuser makes other users superusers under Administration → User Management → Users. The Keycloak group SUPERUSERS only seeds the first superusers: ORT Server reads it when it starts with no role assignment (section 11.6, Step 4 – Keycloak).

Occtet Curator. Two application roles exist:

• admin gives full access, including configuration and organisation management.
• curator gives access to the curation views.

A row-level policy restricts curator users to the data of their own organisation. The roles come from the Keycloak token and are matched against the roles defined in the application.

Kubernetes. Only platform operators administer the cluster. Partners who operate a service receive a ServiceAccount whose Role covers only their namespace, plus read-only listing of namespaces. Housekeeping jobs run under dedicated ServiceAccounts with minimal rights.

8.3.1. Granting permissions #

Keycloak only signs users in; each tool keeps its own permissions. Every hour, the access job described below gives every account read access to the public organisations of ORT Server and the realm role curator. Any other permission is granted by hand, separately in each tool:

The two sets are independent: the realm roles admin and curator give no permission in ORT Server, and an ORT Server superuser has no access to the Curator. Adding a user to the Keycloak group SUPERUSERS after the first start of ORT Server changes nothing. The technical account of the Curator must be an ORT Server superuser.

Automatic access. A scheduled pipeline of the repository occtet-eclipse-projects runs the job grant-users-access every hour. The job runs the script grant-users-access.sh (section 13.4, Automation for large portfolios), which reads the users of the realm occtet and, for every enabled account, service accounts excluded:

• grants the role READER on each public organisation of ORT Server (section 5.3, Access modalities for partners), with PUT /api/v1/organizations/{id}/roles/READER. A user who already has a role on the organisation keeps it: ORT Server holds one role per user and organisation, so assigning READER would demote a writer or an admin;
• assigns the realm role curator in Keycloak, unless the user has the role admin: the role curator also carries the row-level policy of the Curator, which would restrict an administrator to the data of one organisation.

A new account therefore reads the public organisations of ORT Server within the hour after its creation, and opens the Curator at its next sign-in after that. The job only adds missing permissions and never removes one, so it can run again at any time. It does not add users to a Curator organisation: a curator sees no Curator data until a Curator admin adds them to one. The job authenticates with an offline token of an ORT Server superuser (section 5.4, Programmatic access: API, CLI and CI), which it exchanges for access tokens, and with the secret of the client api-access (section 8.2, Identity and authentication). A request that gets no answer, for example while ORT Server is overloaded, is attempted again up to five times, one minute apart.

8.4. Secrets management #

• Out-of-band Secrets. Credentials are created as Kubernetes Secrets before installation, and the charts reference them with existingSecret (section 21.5). make vulnerablecode-secrets-create in occtet-helm-chart generates every VulnerableCode value with openssl, and make secrets-create in occtet-keycloak generates random Keycloak passwords. The Keycloak database password is the exception: its chart generates it.
• ORT Server user secrets. VCS credentials and API keys are stored in the ORT Server database, encrypted with a master password and a salt held in a Kubernetes Secret. The API returns only their names and descriptions.
• CI/CD variables. The hourly access job (section 8.3.1, Granting permissions) reads its credentials from masked and protected CI/CD variables of the GitLab project occtet-eclipse-projects: an offline token of an ORT Server superuser and the secret of the client api-access.
• Curator secrets. The VulnerableCode API token is stored as an encrypted configuration value.

8.5. Workload separation and supply chain #

These controls are applied:

8.6. Administrative access #

• Kubernetes. The cluster is administered with kubectl, k9s, headlamp and Helm through the Kubernetes API.
• Grafana. It is not published on the Internet; administrators open it through kubectl port-forward. Anonymous access is read-only: without an account, Grafana shows the dashboards but neither Explore nor the editing of dashboards, which need the Grafana admin account. Since a Viewer can still query every datasource through the Grafana API, Loki included, anonymous access must be disabled before Grafana is published.
• CI deployment. GitLab CI deploys the ORT Server stack, the Curator and Keycloak through the GitLab Agent for Kubernetes, with one agent per namespace: gitlab-agent-ort-server, gitlab-agent-curator and gitlab-agent-keycloak. Each agent opens the connection to GitLab from the cluster, so no cluster credentials are stored in CI variables. Merge request pipelines never deploy.
• Manual deployment. Administrators deploy the dashboards of occtet-stats with its Makefile (section 9.4). They deploy the entry point and VulnerableCode, and any component outside the CI, with occtet-helm-chart (section 11). Its targets that change the cluster refuse to run on another kubectl context than the expected one.
• Keycloak. The administration console is reachable through the public Keycloak host name.
• VulnerableCode. No administration console is published. Administrative tasks, such as creating API users, run manage.py in the web pod through make targets of occtet-helm-chart or of the VulnerableCode repository.

9. Monitoring and observability #

9.1. Logs #

• Collection. Promtail runs as a DaemonSet and ships container logs to Loki. Its pipeline strips query= fields from log lines and extracts a component label from ORT Server log lines.
• Exploration. Grafana is used to explore logs, and holds the statistics dashboards of ORT Server (section 9.4); it is reached through kubectl port-forward.
• Run logs. ORT Server’s log file service queries Loki, so users can download each run’s worker logs from the UI or the API.

9.2. Resource metrics and health checks #

• Usage metrics. metrics-server, managed by OVHcloud, provides kubectl top nodes and kubectl top pods.
• Health checks. Each reverse proxy answers /alive; make test-entrypoint in occtet-helm-chart checks every proxy.
• VulnerableCode pipelines. The dashboard https://vulnerablecode.occtet.eu/pipelines/dashboard/ of the OCCTET instance shows the state of every importer and improver run and the load factor of the workers. make test-vulnerablecode runs the chart’s Helm test, which checks that Django, behind the nginx sidecar, and the static files answer.

9.3. Job supervision, housekeeping and retention #

The ORT Server maintenance CronJobs (all but pod-cleanup and occtet-stats-refresh) run with the resources and JVM settings given in section 21.6.

Retention. delete-old-ort-runs deletes every run that finished more than DATA_RETENTION_ORT_RUN_DAYS days ago, except the latest run of each repository, the one with the highest identifier. The ORT Server chart keeps 90 days; the values of this installation keep 365 days (section 21.1), so that the runs of a campaign remain for a year after their repositories are analysed again, and with them the history of the statistics dashboards (section 9.4).

A run’s results, reports and SBOMs are deleted 365 days after the run finished, unless it is still the latest run of its repository. Users who need them longer must download them. Worker logs held in Loki are already lost whenever the Loki pod restarts (section 9.5).

VulnerableCode deletes its pipeline run records after 60 days.

9.4. Statistics dashboards #

The repository occtet-stats adds three dashboards to the Grafana of ORT Server, in the folder ORT Server:

• Data. The dashboards query the PostgreSQL database of ORT Server with the read-only role occtet_stats, which reads only the tables they need: not the secrets, infrastructure services, environment variables or user names stored by ORT Server. Its statements stop after 60 seconds. The CronJob occtet-stats-refresh computes the vulnerabilities of each run once, when its advisor job completes, into the schema occtet_stats of the same database, with the role occtet_stats_refresh. Computing them from the results of the advisor at each display took longer than the statement timeout on eclipse-projects. The schema holds tables only, without views or foreign keys on the tables of ORT Server, so the migrations of ORT Server do not depend on it.
• Definitions. They follow those of ORT Server and of Annex B. By default, a vulnerability affecting a package counts once in the selected scope, however many repositories use the package. The dashboards can also count vulnerability identifiers only, or each repository separately. The evolution charts count, at each point in time, the vulnerabilities of the latest runs of that time. They grow with every campaign that analyses new repositories; a filter keeps only the repositories already analysed at the start of the time range.
• Freshness and history. A run counts once the CronJob has processed it, within 15 minutes of the end of its advisor job. The history goes back to the oldest runs that ORT Server keeps (section 9.3).
• Deployment. The values of occtet-ort-server-helm-chart enable the dashboard sidecar of Grafana, and limit its datasource sidecar to the ConfigMaps and Secrets labelled grafana_datasource=1. Without that label, the sidecar copied every ConfigMap and Secret of the namespace, the secrets of ORT Server included, into the provisioning directory of Grafana. The administrators deploy the dashboards by hand with the Makefile of occtet-stats: make db-roles creates the roles and the schema, make datasource applies the datasource Secret, make deploy installs the Helm release occtet-stats, and make refresh runs the first precomputation. make test runs every query of the dashboards on Docker, against the database schema of an ORT Server release and synthetic data: run it before upgrading ORT Server.

9.5. Current limits #

• No alerting. There is no metrics stack with alerting, and no external availability probe.
• Ephemeral logs. Loki keeps logs on ephemeral storage.
• Promtail end of life. Promtail reached end of life on 2 March 2026 and receives no further updates. It must be replaced by a maintained collector such as Grafana Alloy (section 15.5, Operational readiness matrix).

10. Prerequisites #

11. Installation #

11.1. Getting the deployment material #

BASE=https://gitlab.eclipse.org/eclipsefdn/open-source-services/occtet-eu/reference-installation
git clone --recurse-submodules "$BASE/occtet-helm-chart.git"   # installation; chart repositories as git submodules under repos/
git clone "$BASE/occtet-keycloak.git"                           # Keycloak
git clone "$BASE/occtet-eclipse-projects.git"                   # optional: portfolio campaigns (section 13.4)
git clone "$BASE/occtet-stats.git"                              # optional: statistics and dashboards (section 9.4)

cd occtet-helm-chart
helm repo add grafana https://grafana.github.io/helm-charts
make deps                    # downloads the dependencies of the ORT Server, Curator and VulnerableCode charts

In an existing clone of occtet-helm-chart, make init checks out the chart repositories at the commits it references. The variables ORT_SERVER_REPO, CURATOR_REPO, VULNERABLECODE_REPO and KEYCLOAK_REPO point the Makefile to other checkouts, for example a branch under review. The local installation of section 12 uses the clones of the chart repositories next to occtet-helm-chart instead of the submodules.

Two repositories are not cloned. ORT Server reads occtet-ort-server-config from Git at every run (section 21.1): fork it to change the parameters or the policy rules, and set its URL in the ORT Server values. Keycloak downloads the theme package built by occtet-keycloak-theme (section 7.1): clone that repository only to change the theme.

The make commands below run in the root of occtet-helm-chart, except those of section 11.6, Step 4 – Keycloak. The placeholders that remain in the commands (<…>) are passwords, client secrets and contact addresses. Choose them for each installation. Annex D gives the configuration reference of ORT Server, the Curator and VulnerableCode, the recommended proxy configuration, the Kubernetes Secrets, and the resource requests and persistent volumes; read the warnings of section 21.5 before deleting or recreating a Secret.

11.2. Installation order #

1. Create the cluster (section 11.3).
2. Install the ingress controller and create the DNS records (11.4).
3. Install cert-manager (11.5).
4. Install Keycloak and configure the realm (11.6).
5. Install ORT Server (11.7).
6. Install the Curator (11.8).
7. Install VulnerableCode (11.9).
8. Publish the services through the entry point, then verify the installation (11.10).

The entry point comes last: an nginx proxy refuses to start when the host name of its upstream service does not resolve. At the first installation, however, it first publishes Keycloak alone, right after step 4 (make deploy-entrypoint-bootstrap): ORT Server and the Curator call Keycloak by its public URL, and the Curator does not start without it. To publish only some of the services, set services.<service>.enabled: false for the others in values/occtet-entrypoint.yaml, or pass PUBLISH=<service keys> to make deploy-entrypoint.

Once the secrets exist, make deploy runs steps 2 and 3, publishes Keycloak if the entry point is not installed yet, runs steps 5, 6 and 7, then publishes the entry point, in that order; Keycloak is installed from its own repository. Each component is a Helm release in its own namespace (section 6.3). Makefile variables such as CURATOR_NAMESPACE change the namespaces, DOMAIN (default occtet.eu) the domain of every host name, and make help lists every target.

11.3. Step 1 – Cluster #

1. In the OVHcloud Control Panel, create a Managed Kubernetes cluster and a node pool sized as in section 10.
2. Download the kubeconfig and select its context.

The targets of occtet-helm-chart that change the cluster refuse to run unless the current kubectl context is OCCTET. On another cluster, pass KUBE_CONTEXT=<your context> to make. The Makefile of the Keycloak repository uses the current context without checking it. To try the procedure on a workstation first, see section 12.

11.4. Step 2 – Ingress controller and DNS #

make deploy-ingress-nginx                                   # upstream chart ingress-nginx 4.13.2, values/ingress-nginx.yaml
kubectl get svc -n ingress-nginx ingress-nginx-controller   # note the EXTERNAL-IP

Create a DNS A record for each of the four host names, pointing to the EXTERNAL-IP shown.

Further reading: https://docs.ovhcloud.com/en/guides/public-cloud/containers-orchestration/managed-kubernetes/secure-nginx-ingress-cert-manager and https://docs.ovhcloud.com/en/guides/public-cloud/containers-orchestration/managed-kubernetes/expose-applications-using-load-balancer.

11.5. Step 3 – Certificate management #

make deploy-cert-manager      # upstream chart jetstack/cert-manager v1.18.2 with its CRDs, values/cert-manager.yaml

values/cert-manager.yaml installs the CRDs with the release (installCRDs: true). Never set it to false on an existing installation: Helm would delete the CRDs, and every Certificate and ClusterIssuer with them. The ClusterIssuers letsencrypt-prod and letsencrypt-staging are created with the entry point (section 11.10). Let’s Encrypt needs host names reachable from the Internet; otherwise, clusterIssuers.enabled: false removes these ClusterIssuers and selfSignedCA.enabled: true creates a self-signed certificate authority for the Ingresses (ingress.clusterIssuer: occtet-ca), as on the local installation of section 12.

Further reading: https://cert-manager.io/docs/.

11.6. Step 4 – Keycloak #

Install, in the repository occtet-keycloak:

cd ../occtet-keycloak
make secrets-create          # creates keycloak-admin-secret and keycloak-postgresql-secret with random passwords
make install                 # helm dependency update, then helm install occtet-keycloak . -n keycloak

Only keycloak-admin-secret is used: it seeds the admin account at the first start. The chart generates the database password itself (section 21.5, Kubernetes Secrets). On the OCCTET instance, GitLab CI then deploys every merge of this repository (section 15.2, Maintenance and upgrades).

The theme initContainer in values.yaml downloads the theme from the public Maven package registry of occtet-keycloak-theme (section 7.1). A reproduction that changes the theme publishes it from its own copy of the theme repository and updates the Maven coordinates of the initContainer.

Reach the administration console. Publish Keycloak alone through the entry point, which needs ingress-nginx and cert-manager (sections 11.4 and 11.5), then open https://keycloack.<domain>/admin; or use a port-forward. Sign in as admin; the README of occtet-keycloak explains how to recover this access if the password is lost.

make secrets-get                                                 # prints the generated passwords, including the admin one
cd ../occtet-helm-chart && make deploy-entrypoint-bootstrap      # publishes Keycloak alone, at the first installation
kubectl port-forward -n keycloak svc/occtet-keycloak 8080:8080   # or: http://localhost:8080/admin

Configure the realm. The realm occtet is configured from scratch in the administration console, in the order below. ORT Server and the Curator share it (see Shared authentication below). When reproducing on another domain, replace the occtet.eu host names. The steps give the configuration to apply; the OCCTET instance still differs from it on the points listed in the Identity row of section 15.5. The file realm/occtet-dev.json of occtet-keycloak holds the result of steps 1 and 3 to 6, without GitHub sign-in, for the local installation of section 12, which imports it at startup.

1. Realm. Create the realm occtet (realm selector → Create realm), then set in Realm settings:

Keep the default role default-roles-occtet: it includes offline_access, which the CLI tokens need.

2. GitHub sign-in. Create a GitHub OAuth App whose authorization callback URL is https://keycloack.occtet.eu/realms/occtet/broker/github/endpoint, the Redirect URI that Keycloak shows for the provider. Then, in Identity providers → GitHub, keep the alias github and enter the Client ID and the Client Secret of the app, with Display name Or Sign in with GitHub, Trust email off and Sync mode Import.

3. Client scopes. In Client scopes:

• Create ort-server-api, with type None, protocol OpenID Connect and Include in token scope off. In its Mappers tab, choose Configure a new mapper → Audience: name ort-server-api, Included Client Audience ort-server, Add to access token on, Add to ID token off. The access tokens of the clients that use this scope then carry the audience that the ORT Server API requires (section 8.2).
• Create ort-server-api-access, with type None and protocol OpenID Connect, without mapper. The Curator requests this scope when it signs users in, so it must be available to the Curator’s client.
• Open the built-in scope roles, mapper realm roles, and set Add to ID token on. The Curator reads the roles admin and curator from the ID token.

4. Clients. In Clients → Create client, with client type OpenID Connect:

Leave the implicit flow off on the three clients. On ort-server-cli, PKCE Method S256 makes PKCE mandatory; the token page already uses it. On api-access, then:

• in Service accounts roles → Assign role, filter by clients and assign manage-realm, manage-users and manage-clients of realm-management;
• in Credentials, copy the client secret (step 7).

5. Roles and groups.

• In Realm roles → Create role, create admin and curator, the application roles of the Curator (section 8.3).
• In Groups → Create group, create SUPERUSERS. When ORT Server starts with no role assignment in its database, that is at its first start, it makes the members of this group superusers. Add the first platform administrators to it now, before ORT Server is installed. Afterwards, superusers are managed in ORT Server, under Administration → User Management → Users (section 8.3.1).

6. Accounts.

• Technical account of the Curator. In Users → Add user, create a user with an e-mail address as user name and Email verified on, then set its password in Credentials → Set password, with Temporary off. Add it to the group SUPERUSERS, because the Curator creates organisations in ORT Server and only superusers may do so; if ORT Server already runs, make it a superuser under Administration → User Management → Users instead. Its user name and password go into the Curator secret (ort-username, ort-password, section 11.8).
• Users. People create their account themselves, with their e-mail address or with GitHub (section 5.3). Administrators then grant their permissions, separately in each tool (section 8.3.1).

7. Client secret. The client secret of api-access goes into the ORT Server secret ort-server-keycloak-credentials (key keycloak-api-secret, section 11.7) and into the Curator secret (key keycloak-client-secret, section 11.8).

Shared authentication. ORT Server (client ort-server) and the Curator (client api-access) are two clients of the same realm. A person has one account and one login page, with the same password or GitHub sign-in for both tools. Keycloak keeps one session per browser, so after signing in to one tool, the other opens without asking for credentials again. Each tool keeps its own permissions (section 8.3.1). Between the tools, the Curator calls ORT Server with its technical account, not with the session of the user (section 6.9).

Check. Once the entry point is published (section 11.10), sign in to ORT Server, then open the Curator: it should not ask for credentials again. The token test of section 5.4 checks the client ort-server-cli.

The OCCTET instance also has a confidential client ort-ci, for the CI pipelines of section 5.4.

Further reading:

• the README of occtet-keycloak;
• the ORT Server administration guide on Keycloak, https://eclipse-apoapsis.github.io/ort-server/docs/admin-guide/guides/keycloak-config; https://github.com/CloudPirates-io/helm-charts/tree/main/charts/keycloak; https://www.keycloak.org/docs/latest/server_admin/; https://www.keycloak.org/server/reverseproxy; https://docs.keycloakify.dev/.

11.7. Step 5 – ORT Server #

Secrets.

cd ../occtet-helm-chart
kubectl create namespace ort-server
kubectl create secret generic ort-server-db-credentials -n ort-server \
  --from-literal=database-password='<database password>'
kubectl create secret generic ort-server-rabbitmq-credentials -n ort-server \
  --from-literal=rabbitmq-user='ortserver' --from-literal=rabbitmq-password='<RabbitMQ password>'
kubectl create secret generic ort-server-keycloak-credentials -n ort-server \
  --from-literal=keycloak-api-secret='<client secret of api-access>'
kubectl create secret generic ort-server-user-secrets-encryption -n ort-server \
  --from-literal=master-password='<at least 16 characters>' --from-literal=salt='<at least 32 hexadecimal characters>'
kubectl create secret generic ort-server-grafana -n ort-server \
  --from-literal=admin-user='<Grafana user>' --from-literal=admin-password='<Grafana password>'
make secrets-check-ort-server

Instead of these commands, make -C repos/occtet-ort-server-helm-chart secrets-create creates the missing secrets with generated values, and prompts for the client secret of api-access. On a new installation, use it: it also stores the password hash of the RabbitMQ user (key rabbitmq-password-hash of ort-server-rabbitmq-credentials). RabbitMQ creates no default user when it imports its definitions at startup, and the CloudPirates chart does not give its own user a usable password; make deploy-ort-server therefore adds the user ortserver, with that hash, to the definitions. Without the hash, RabbitMQ refuses to start on an empty volume (no_such_user).

Install. In the values.yaml of the ORT Server repository, set ort-server.configFileProvider.gitConfig.repositoryUrl to the configuration repository, and check the Keycloak settings (section 21.1). Then:

make deploy-ort-server       # helm upgrade --install ort-server … --namespace ort-server --wait

The Makefile passes the namespace addresses of PostgreSQL, RabbitMQ and Loki, so the stack can also be installed in another namespace (ORT_SERVER_NAMESPACE).

On the OCCTET instance, the CI of the ORT Server repository also deploys the release on every merge, with the same chart and values. Run make diff-ort-server before deploying from occtet-helm-chart.

After installation:

1. Apply the footer (section 7.2).
2. Check under Administration → User Management → Users that the members of the group SUPERUSERS are superusers, and grant the superuser role to the other platform maintainers there.
3. Create organisations/products/repositories
4. Create the vulnerableCodeApiKey secret in each organisation (section 13.2).

Further reading: https://github.com/eclipse-apoapsis/helm-charts/tree/main/charts/ort-server and the ORT Server administration guide, https://eclipse-apoapsis.github.io/ort-server/docs/admin-guide/guides/keycloak-config.

11.8. Step 6 – Occtet Curator #

make -C repos/occtet-curator-helm-chart secrets-create   # namespace curator and secret occtet-curator-secrets
# Prompts for the database credentials, the technical ORT account and the api-access client; passwords are not echoed.
make secrets-check-curator
make deploy-curator          # checks the secret, then helm upgrade --install occtet-curator … --set global.namespace=curator

The repository’s values.yaml holds only the OCCTET overrides, under the key occtet-curator (section 21.2); the chart defaults are those of the Bitsea chart, at the version pinned in Chart.yaml, which make deps downloads (section 11.1). The chart places its resources in global.namespace, which stays under global and which the Makefile sets to the release namespace.

On the OCCTET instance, the CI of the Curator repository also deploys the release on every merge, with the same chart and values. Run make diff-curator before deploying from occtet-helm-chart.

Keycloak. The Curator relies on the realm configuration of section 11.6, which follows PR #250: the client api-access, the client scopes ort-server-api, ort-server-api-access and roles, the realm roles admin and curator, and the technical account, which must be an ORT Server superuser.

After installation, a Curator administrator sets the system path for project sources and the VulnerableCode API key. Section 21.2 lists the frontend values and the administrator settings.

11.9. Step 7 – VulnerableCode #

make vulnerablecode-secrets-create   # creates namespace vulnerablecode and secret vulnerablecode-secrets, with generated values
# The Makefile sets config.allowedHosts and config.csrfTrustedOrigins to vulnerablecode.<DOMAIN>
make deploy-vulnerablecode           # branding ConfigMap and templates, then helm upgrade --install … --wait
make test-vulnerablecode             # Helm test: Django and the static files answer

The repository’s values.yaml holds only the OCCTET overrides (section 21.3.2); the chart defaults are in vulnerablecode/values.yaml. Since the service is published through the entry point rather than by the chart’s Ingress, its public host name must be declared in config.allowedHosts and config.csrfTrustedOrigins. Otherwise Django rejects the requests (Bad Request (400)) and the form submissions (CSRF error). The Makefile of occtet-helm-chart sets both from DOMAIN; when the chart is installed another way, set them in values.yaml.

After installation, the scheduler starts the importer and improver pipelines by itself. The first full import takes a few days; follow it on /pipelines/dashboard/. To require an API key on the REST API, set config.requireAuthentication: true, then create API users with make vulnerablecode-create-api-user EMAIL=<address>.

Further reading: the README of occtet-vulnerablecode-helm-chart, and https://vulnerablecode.readthedocs.io/.

11.10. Step 8 – Entry point and verification #

Publish. In values/occtet-entrypoint.yaml, set the ACME contact address. The host names are ort-server., curator., keycloack. and vulnerablecode. followed by the domain, which the Makefile variable DOMAIN sets (default occtet.eu, for example make deploy DOMAIN=example.org): the Makefile passes it to the entry point and derives from it the URLs of the ORT Server, Curator, VulnerableCode and Keycloak values. Then:

make deploy-entrypoint       # ClusterIssuers, one TLS Ingress and one nginx proxy per service
make test-entrypoint         # each proxy answers /alive

cert-manager then obtains a Let’s Encrypt certificate for each host name. Section 21.4 gives a corrected configuration of the proxies, which keeps the forwarded protocol.

Verify.

make status
kubectl get pods -A
kubectl get certificate -n default
curl -sI https://ort-server.occtet.eu/
curl -s https://keycloack.occtet.eu/realms/occtet/.well-known/openid-configuration | jq .issuer
curl -s https://ort-server.occtet.eu/api/v1/auth/oidc-config/cli
curl -s -H 'User-Agent: VCIO_API_AGENT' https://vulnerablecode.occtet.eu/api/v3/ | jq .   # OCCTET instance

Then run the functional check of section 14.1, Scenario A – Integration test between the Curator and ORT Server, on a small public repository.

12. Local installation on minikube #

occtet-helm-chart also installs the whole platform on a local minikube cluster, with the Makefile variable ENV=dev. It serves two purposes: to test a change of a chart, of its values or of a secret script before it is merged and deployed by the CI, and to try the installation procedure of section 11 on a workstation before reproducing it on a cluster. It uses the same charts, values and secret scripts as production; only the overrides below differ.

Install. Clone the repositories side by side, then run make dev-up:

BASE=https://gitlab.eclipse.org/eclipsefdn/open-source-services/occtet-eu/reference-installation
for repo in occtet-helm-chart occtet-keycloak occtet-ort-server-helm-chart occtet-curator-helm-chart occtet-vulnerablecode-helm-chart; do
  git clone "$BASE/$repo.git"
done
cd occtet-helm-chart
make dev-up         # cluster, DNS, secrets, every release, CA certificate and /etc/hosts line
make dev-accounts   # passwords of the development accounts

make dev-up runs make dev-cluster, make deps, make dev-secrets and make deploy with ENV=dev, in the installation order of section 11.2, Keycloak included. It then saves the root certificate of the CA to occtet-ca.crt and prints the /etc/hosts line to add. Every step can be run alone and again.

Trusting the CA. Browsers keep their own trust store: make dev-ca-install imports the CA, without sudo, into those of Chrome, Chromium and Firefox, snaps included, which do not read the trust store of the system; restart them afterwards. Command-line tools such as curl use the trust store of the system: sudo cp occtet-ca.crt /usr/local/share/ca-certificates/ && sudo update-ca-certificates. Each new cluster has a new CA, to trust again. The CA can only sign names under occtet.local, so trusting it does not expose any other site.

inotify limits of the workstation. With the Docker driver, the minikube node shares the kernel of the workstation and its inotify limits. Every process of the cluster runs as root of the workstation, and the installation alone uses about 90 inotify instances, one per container plus the kubelet, the control plane and Promtail, against a default limit of 128 per user (fs.inotify.max_user_instances on Ubuntu). Once it is reached, following the logs of a pod (kubectl logs -f, k9s) fails with failed to create fsnotify watcher: too many open files, although the pods keep running. Raising the limits fixes it, without restarting anything:

sudo sysctl -w fs.inotify.max_user_instances=1024 fs.inotify.max_user_watches=524288
printf 'fs.inotify.max_user_instances = 1024\nfs.inotify.max_user_watches = 524288\n' | sudo tee /etc/sysctl.d/99-inotify.conf

Verify. Open https://ort-server.occtet.local and https://curator.occtet.local, register an account from the login page, then sign in to both tools with it. ORT Server shows no organisation until a superuser, such as [email protected], grants a role in the ORT Server UI; the Curator follows the realm roles admin and curator, assigned in the administration console https://keycloack.occtet.local/admin/ (section 8.3.1).

The README of occtet-helm-chart (section Development on minikube) details the targets, the development work on a chart repository and the troubleshooting; the README of each component repository describes its values-dev.yaml.

13. Onboarding and usage #

13.1. Onboarding process and checklist #

SMEs and open source projects are onboarded in the same way, on the OCCTET instance or on Double Open’s own hosted ORT Server instance, where most SMEs tested (section 14.3):

1. Initial contact, typically through OCCTET’s outreach, personal networks or partner referrals, or an access request by e-mail (section 5.3).
2. Intake conversation, to identify the software to analyse. The getting-started guide (https://occtet.eu/toolkit/getting-started/) lists what to prepare: repository URL and revision, languages, private registries and a technical contact. It advises discussing data handling before confidential code is analysed on a hosted instance.
3. Access, to run the participant’s own repositories through a hosted ORT Server instance, alongside the CRA self-assessment questionnaires developed in Work Package 2 (D2.1, D2.2).

For open source projects, task T4.4 applies the toolkit to the iconic projects of the Grant Agreement and to a wider benchmark of popular repositories (sections 14.4 and 14.5).

Checklist for a new user of the OCCTET instance:

1. First sign-in. The user signs in once with a local account or with GitHub (section 5.3).
2. Permissions. Within the hour after the first sign-in, the access job grants read access to the public organisations of ORT Server and the curator role (section 8.3.1, Granting permissions). An administrator grants the rest according to the profile, in each tool separately:
   • in ORT Server, a role on the user’s own organisation;
   • in the Curator, organisation membership;
   • for partners operating a service, a namespace-scoped ServiceAccount.
3. ORT Server workspace.
   • Create the organisation.
   • Create the vulnerableCodeApiKey secret, holding the API key of the public VulnerableCode service (section 13.2).
   • Register products and repositories.
   • For private repositories, store the credentials as ORT Server secrets.
4. Curator workspace. The user belongs to the right organisation, and the VulnerableCode key is configured once per Curator instance.
5. Automation (optional). Generate a token for the CLI, scripts or CI (section 5.4).

13.2. Using ORT Server #

1. Model the portfolio. Create organisations, products and repositories.
2. Declare the VulnerableCode API key. Request an API key for the public VulnerableCode service at https://public.vulnerablecode.io/account/request_api_key/. Then, in ORT Server, create a secret named exactly vulnerableCodeApiKey whose value is that key: open the organisation, the product or the repository, then Secrets → Add secret, and fill in Name, Value and Description. A secret created in the organisation serves all the runs of its products and repositories.
3. Start a run. Choose a revision and configure the jobs; section 21.1 gives a reference configuration.
4. Follow the run. Track the status of each job and download its logs.
5. Review the results. Browse packages, vulnerabilities, rule violations and issues, then download the SBOMs (CycloneDX, SPDX) and the web report.

Without the vulnerableCodeApiKey secret, the advisor job fails in every run that selects the VulnerableCode advisor with the public service, that is, without serverUrl or with https://public.vulnerablecode.io/api/. The configuration script then requests the secret for the run (section 21.3.1). Runs that select only the OSV advisor do not need it.

The secret can also be created through the API, with an access token obtained as in section 5.4:

curl -X POST -H "Authorization: Bearer $ACCESS_TOKEN" -H 'Content-Type: application/json' \
  https://ort-server.occtet.eu/api/v1/organizations/<organization ID>/secrets \
  -d '{"name": "vulnerableCodeApiKey", "value": "<VulnerableCode API key>", "description": "Public VulnerableCode service"}'

The same request on /api/v1/products/<product ID>/secrets or /api/v1/repositories/<repository ID>/secrets limits the key to a product or a repository. When the secret exists at several levels, the one closest to the repository is used.

13.3. Using Occtet Curator #

The Curator user guide is published at https://bitsea.github.io/Occtet-Curator/; the same guide is built into the application, in its Help view. It covers the administration (organisations, system path, API key), projects, SBOM import, ORT runs, the curation of inventory items, files and audit notes, vulnerabilities and VEX, export, and a complete audit process.

Administrators create the organisations, assign users to them and define the system path where source code is stored. A curator then works as follows:

1. Create a project (Projects).
2. Import an SBOM: Import → SPDX Import, or start an ORT analysis with ORT Starter.
3. Open SBOM Management (SBOMmgmt) and select the project: the file tree is on the left, the inventory items on the right.
4. Review the vulnerabilities, licences and copyrights on the Overview page.
5. Curate the inventory items. Each one holds the details of a software component: its vulnerabilities, licences, copyrights and files. Audit notes record the evidence and the decisions.
6. Assess vulnerabilities: create and download VEX reports from the inventory item.
7. Export: download the curated SBOM from the project page.

The aim is to turn an unverified SBOM into a validated, audit-ready software inventory.

13.4. Automation for large portfolios #

The scripts of the repository occtet-eclipse-projects use the ORT Server REST API, and for grant-users-access.sh, the Keycloak admin API:

14. Demonstration and validation #

The validation combines a technical integration test of the toolchain (14.1) with four validation tracks: an analysis campaign at scale (14.2), SME use cases (14.3), the iconic open source projects of the Grant Agreement (14.4) and a benchmark of widely used open source projects (14.5).

The figures of sections 14.1, 14.2, 14.6 (Consolidated results of the instance) and 14.7 (Limits observed) were extracted on 6 October 2026 with the script statistics.sh, through the APIs of ORT Server, the Curator and Keycloak (section 13.4, Automation for large portfolios), and cover runs created between 12 May and 4 October 2026. A campaign was running while the figures were extracted, so counts taken a few hours apart can differ by less than 1%. Annex B gives the definitions and describes the extraction. The figures of sections 14.3 to 14.5 come from the data pull of 11–12 October 2026 reported in the Double Open draft of this deliverable. That pull covers the OCCTET instance and Double Open’s own hosted ORT Server instance; Annex B does not apply to it.

14.1. Scenario A – Integration test between the Curator and ORT Server #

This scenario is a technical integration test, run by the project team. It is not SME feedback; that is covered in section 14.3.

Conclusion. The integration between the Curator, Keycloak and ORT Server is validated up to the import of results. Curation decisions, VEX authoring and the export of a curated SBOM are available in the Curator, but have not yet been validated on this instance. The 11 runs repeat the same test on the same commit, while the integration was being finalised.

Curator instance content, for context:

14.2. Scenario B – Analysis campaign on the Eclipse Foundation portfolio #

This campaign is an additional validation. It was not foreseen in this form in the Description of Action. It tests the service at the scale of a large open-source portfolio.

Steps.

1. sync-eclipse-projects.sh and sync-eclipse-research-projects.sh registered the Eclipse projects and the Eclipse Research Labs.
2. bulk-run.sh started one run per repository, with OSV and VulnerableCode advisors, scanning, and CycloneDX, SPDX and web-app reports.

Inventory, started and completed analyses:

The campaign therefore covers the portfolio as an inventory: 4,125 repositories. 72% of those repositories have at least one completed analysis.

The Double Open data pull adds that the runs were submitted in two waves, in June and in September–October 2026, nearly all of them in bulk by a single Eclipse Foundation account. It also reports aggregate findings of roughly 352,000 package findings and 94,000 vulnerabilities across the corpus. Their definitions are not documented in Annex B, so they cannot be compared directly with the counts of section 14.6, Consolidated results of the instance. The campaign thus shows that the toolkit processes thousands of repositories without per-project customisation.

Waiting time and execution time (completed runs, medians, with the 90th percentile in brackets):

Execution time is the sum of the durations of a run’s jobs. Waiting time is the total minus execution, i.e. time spent queued for cluster capacity. For the Research Labs, the 440 runs were submitted in one batch, so waiting accounts for almost all of their duration.

Concurrency and impact on interactive use.

• Parallelism. At most 31 analysis jobs ran in parallel (hourly sampling); 4.2 ran on average when the instance was busy.
• Effect on other users. The 71 completed runs of other organisations that started during a campaign had a median total duration of 2.4 minutes (90th percentile: 103 minutes). The 176 started outside campaigns had a median of 28 minutes (90th percentile: 18.7 hours).
• Interpretation. No degradation of interactive runs attributable to the campaigns was observed. The sample is small, though, and the long tail outside campaigns has not been analysed.

14.3. SME use cases and feedback #

Testing. According to the data pull of 11–12 October 2026, 10 SMEs engaged with the toolkit. Eight tested it on their own software: 19 distinct products and repositories, analysed in 115 runs as code, dependencies and advisories changed over time.

SMEs that declined. Two SMEs declined to proceed: TeraTron GmbH, because it does not want to share source code outside the company, and Mahlo GmbH, because its embedded C++ build tooling is not currently supported. Other SMEs, not recorded as OCCTET testers, declined for the same reason as TeraTron: they do not want to expose their source code to a SaaS service, even one hosted and controlled in the EU. TeraTron’s response is therefore representative of SMEs that would rather run the tools inside their own perimeter, which the reproducible installation of sections 10 and 11 allows.

Feedback. Three SMEs gave qualitative feedback. The table summarises the SME testing tracker; the entries are reformulated from the tracking notes, not direct quotations. The full analysis is in D4.2.

These cases provide qualitative evidence of successful ORT Server use and identify onboarding and workflow integration needs. Questionnaire feedback was documented separately where available. No SME feedback on the Curator workflow is recorded, and the SME testing tracker does not record completion of a Curator-based workflow covering import, curation, VEX authoring and export; therefore, these cases should not be presented as validation of that full workflow.

14.4. Iconic open source projects #

For Milestone 9 (section 4.2), the Grant Agreement names seven candidate projects: Adoptium, Eclipse IDE, Eclipse Mosquitto, Jetty, Tomcat, Kafka and Hadoop. The Double Open draft reports that the toolkit has been applied to all seven. Run data is confirmed for four of them on the instances surveyed:

These four are Eclipse Foundation projects, part of the portfolio registered in section 14.2. The runs of the three Apache Software Foundation projects, Tomcat, Kafka and Hadoop, remain to be completed or located; they may exist on an instance not yet surveyed.

14.5. General open source ecosystem benchmark #

Beyond the SME and iconic projects, the toolkit was run on the OCCTET ORT Server, together with task T4.4, on 96 widely used open source projects. They cover 10 language ecosystems: C/C++, C#, Swift, Rust, Ruby, Python, Go, PHP, JavaScript and JVM. About ten repositories were chosen per ecosystem, by download counts and community adoption.

The same instance also analyses the repositories of the AboutCode organisation behind the toolkit’s federated data source: VulnerableCode, FederatedCode and PurlDB.

14.6. Consolidated results of the instance #

Runs

What finished with issues means. A run gets this status when at least one job completed but reported issues. Of the 2,728 runs concerned, the evaluator reported policy rule violations in 2,685 and the analyzer reported dependency resolution problems in 906. Finished with issues therefore mixes compliance findings to review (rule violations) with technical problems that make the results incomplete (dependency resolution, provenance, advisory errors).

Vulnerabilities and packages

Reports. 26,098 report and SBOM files were generated.

Users. Between April and October 2026, 37 user accounts were created in the realm occtet. Ten are linked to a GitHub account and 28 have a local password. These categories overlap: one account can have both, and accounts created through GitHub may have no password.

Annex B details these figures: the issues of each job, the vulnerability identifiers by prefix, the vulnerability and package records, the advisor results and the packages by ecosystem.

14.7. Limits observed #

1. Failure analysis is incomplete. 1,118 jobs failed; 618 of them (55%) carry no error message, and 12 failed runs have no failed job recorded. Among the failures that can be classified, the identified causes are:

   • the requested branch does not exist, because the campaign used a fixed revision (69);
   • Git sub-modules could not be fetched (28);
   • inconsistent analyzer results with duplicate identifiers (40);
   • the scanner rejected checkout paths (57) or found duplicate stored scan results (34);
   • the reporter ran out of memory (57).

   These causes point to repository specifics and to sizing. The unclassified share is too large to attribute the failures to repositories in general. Since then, the memory limit of the reporter has been raised to 6 GiB, with 75% of it for the heap (section 21.6).

2. VulnerableCode reliability. Frequent server errors, unhandled redirects and timeouts make the VulnerableCode results incomplete. Moving to the endpoint’s final URL to avoid the redirects, plus retries, needs to be investigated. The local VulnerableCode instance (section 6.8) is another option once its first import is complete; ORT Server can be pointed to it through the advisor configuration (section 21.3.2).

3. Throughput for large batches. Analyses take minutes, but large batches wait for cluster capacity (section 14.2, Scenario B – Analysis campaign on the Eclipse Foundation portfolio).

4. Per-organisation configuration. The VulnerableCode key must be defined in each organisation.

5. History of the first campaigns lost. Until October 2026, a run was deleted 90 days after it finished once its repository had been analysed again. About 5,200 runs created between 19 May and 3 June 2026 were deleted, among them the June 2026 runs of eclipse-research-labs. The retention is now 365 days (section 9.3).

6. Curation workflow not validated. Curation, VEX and the curated export have not been exercised on the instance (section 14.1, Scenario A – Integration test between the Curator and ORT Server), and no SME feedback on the Curator workflow is recorded (section 14.3). So far, the Curator has had only limited external use.

7. Policy rules. The evaluator applies the example rules of the ORT project, with their placeholders, not a reviewed OCCTET policy (section 21.1). The rule violations counted in section 14.6 come from these rules.

8. Build ecosystems not covered. Some build ecosystems are not supported yet: vcpkg (C++) and some older, embedded-targeted C++ toolchains surfaced during SME testing, and Mahlo GmbH declined for that reason (section 14.3). Embedded targets and C++ are a known difficult area, for commercial services too. The Yocto analysis developed during the project, and run for DH Electronics, shows that such areas can be covered, with technology-specific work; vcpkg could be handled the same way. BENNING, a prospective contact outside the SME definition, raised the same need for its mixed environment: old and new Yocto-based builds alongside JavaScript and web components. It said it would try the toolkit, and asked for better embedded support and for CRA-ready report models.

9. Onboarding partly manual. Most SME runs so far were carried out by Double Open staff on the SMEs’ behalf, rather than through self-service use.

14.8. Assessment against the Grant Agreement commitments #

15. Operations, continuity and costs #

15.1. Hosting and continuity #

Sustainability of the software. The components of the toolkit do not depend on this instance. They are open source projects, developed in public repositories (section 4.2, Grant Agreement reference):

Anyone can use these projects, propose changes through pull or merge requests, and fork them. After the platform stops, organisations can still reproduce the installation (sections 10 and 11) or build on the upstream projects.

15.2. Maintenance and upgrades #

15.3. Infrastructure cost estimate (one year) #

The estimate covers infrastructure only. It uses OVHcloud list prices excluding VAT (https://www.ovhcloud.com/fr/public-cloud/prices/, consulted on 6 October 2026):

• Instances use monthly billing.
• Other resources are billed by the hour; a year counts 8,760 hours.
• Block storage is taken from the metered consumption of September 2026. The VulnerableCode volumes, created on 6 October 2026, are added at their provisioned size.

Storage reconciliation.

The VulnerableCode volumes are left out of this comparison, since they did not exist in September. The difference between the invoice and the volumes known to Kubernetes comes from volumes created outside Kubernetes, or changed during September. It has to be reconciled in the OVHcloud console. Removing the unattached volumes would save about €67 per year.

Not included:

• staff time for administration, upgrades and incident handling;
• user support and onboarding;
• backup storage, since backups are not yet in place;
• any paid external service, such as commercial support or a higher-tier VulnerableCode access.

Scaling unit costs (per year, excluding VAT): one more b2-15 node costs €576.60, one more b2-30 node €1,166.88, and the MKS Standard plan €788.40. The Standard plan has a 99.99% SLA but is not available in SBG5.

15.4. Scalability #

Demonstrated. 4,978 runs between 12 May and 4 October 2026, and up to 31 jobs in parallel on 32 vCPU and 120 GB RAM (sections 14.2 (Scenario B – Analysis campaign on the Eclipse Foundation portfolio) and 14.6 (Consolidated results of the instance)). The waiting times of section 14.2 also show the limit: large batches wait for capacity.

Horizontal scaling. Every analysis step runs as an independent Kubernetes Job, so throughput grows with the number of nodes. The node pool can be resized or autoscaled.

Workload separation. The local VulnerableCode instance shares the node pool with the analysis workers, and its requests (2.75 vCPU, 8.4 GiB) reduce the capacity left for analyses. A dedicated pool for analysis workers, and separating bulk campaigns from interactive runs, would keep interactive use responsive.

Availability. Databases and message brokers run as single instances. Higher availability requires a region offering the MKS Standard plan, and replicated or managed data services.

15.5. Operational readiness matrix #

Owners and target dates are to be agreed between the partners responsible for the platform after 31 October 2026.

16. Conclusion #

D4.1 delivers part of the OCCTET toolkit as a reference implementation run as a containerised cloud service: the Eclipse Apoapsis ORT Server and the Occtet Curator, with Keycloak for single sign-on and the VulnerableCode and OSV vulnerability data sources. Partners can reproduce it by following the installation procedure of sections 10 to 12.

The integration test, the analysis campaign on the Eclipse Foundation portfolio and the ecosystem benchmark ran on the OCCTET instance (sections 14.1, 14.2 and 14.5). Seven of the eight SMEs that tested ORT Server did so on Double Open’s own hosted instance; only Datasance tested on the OCCTET instance (section 14.3). Section 14.8 assesses these results: the reference installation is in place, analysis at scale is demonstrated and the product target of Milestone 8 is reached, while the collection of SME feedback and the runs of the three Apache projects of Milestone 9 remain open.

The path to a fully operational service is set out in section 15.5, Operational readiness matrix. The main open items are scheduled backups, the administration and support arrangements of the platform, which remains available until early 2027, identity hardening, alerting, and the validation of the complete Curator workflow with an SME. Beyond the platform, the software remains available as open source projects, open to contributions and forks by the community (section 15.1, Hosting and continuity).

17. References #

18. Annex A: Glossary #

19. Annex B: Statistics – detailed results and definitions #

Source. The figures are extracted with the script statistics.sh of the repository occtet-stats (section 13.4, Automation for large portfolios), through the APIs of the instance only, without database access:

• ORT Server REST API: every run with the summary of its jobs (GET /api/v1/runs, which needs a superuser token); the products of each organisation and their repositories; the statistics of the latest runs, per organisation (GET /api/v1/organizations/{id}/statistics/runs) and per product (GET /api/v1/products/{id}/statistics/runs); optionally, the vulnerabilities of the latest runs, to count distinct identifiers.
• Occtet Curator REST API: the counts of organisations, users, projects, SPDX documents, software components, inventory items (curated or not), ORT issues and rule violations (resolved or not) and VEX statements. The Curator deployment accepts Keycloak bearer tokens on this API only with the Java option -Djmix.resource-server.authenticated-url-patterns=/rest/**, and the token must carry the realm role admin.
• Keycloak admin API: the user accounts of the realm occtet, service accounts excluded, with their GitHub link and password credential.

The script first saves the API responses to a directory, then computes Markdown tables from these files. The figures can therefore be recomputed and checked later without a new extraction, and an interrupted extraction resumes where it stopped. Run the script when no analysis campaign is running: under load, ORT Server can answer slowly, and the load balancer closes a request left 50 seconds without an answer.

Definitions.

• Completed run: status FINISHED or FINISHED_WITH_ISSUES.
• Ended run: completed or FAILED.
• Repository analysed: at least one run created for it.
• Execution time: the sum of the durations (end minus start) of a run’s jobs.
• Waiting time: the run’s total duration, from its creation to its end, minus its execution time.
• Findings: packages, vulnerabilities, rule violations and issues are counted as ORT Server counts them in its statistics: in the latest run of each repository whose analyzer, advisor or evaluator job completed. Repeated runs of a repository are not counted again. A vulnerability is counted once per vulnerable package.
• Large organisations: the statistics of an organisation that take longer than the 50 seconds of the load balancer, such as eclipse-projects, are summed from those of its products; a package or a vulnerability shared by two products is then counted twice.
• Distinct vulnerability identifiers: counted as reported, without merging aliases: the same vulnerability can appear under a CVE and a GHSA identifier.

Detailed results (section 14.6, Consolidated results of the instance).

Jobs that reported issues in the 2,728 runs finished with issues:

Vulnerability and package records:

Package records by ecosystem:

20. Annex C: Reference images #

Container images deployed by the installation of section 11, with their versions. The tags latest, stable and pg17-trixie move: the image behind them changes over time.

ORT Server

Keycloak

Entry point

Occtet Curator

VulnerableCode

21. Annex D: Configuration reference #

The values, files and Kubernetes Secrets that a reproduction reads or adapts, component by component; the installation steps of section 11 point to them. The Keycloak realm is configured in section 11.6.

21.1. ORT Server #

Keycloak integration (keys under ort-server: in values.yaml):

Maintenance tasks (ort-server.tasks.configs in values.yaml). The values repeat the five tasks of the ORT Server chart, because Helm replaces a list instead of merging it, with one change: delete-old-ort-runs keeps the runs 365 days (dataRetention.ortRunDays: 365, DATA_RETENTION_ORT_RUN_DAYS of its CronJob) instead of 90 (section 9.3). Compare the list with the values of the chart when upgrading it.

Grafana (loki-stack.grafana.sidecar in values.yaml). The datasource sidecar provisions the ConfigMaps and Secrets labelled grafana_datasource=1: the Loki datasource and the database of ORT Server. The dashboard sidecar loads the ConfigMaps labelled grafana_dashboard=1 into the folder named by their annotation grafana_folder (section 9.4).

Configuration repository (occtet-ort-server-config, Apache-2.0). It started as a fork of mnonnenmacher/ort-server-config, the example configuration of the ORT Server authors, extended for OCCTET.

The chart enables the Git configuration provider (CONFIG_FILE_PROVIDER=git-config) for the core and the workers. At the start of a run, the config worker resolves the configuration once: the branch given in the run’s jobConfigContext, or the head of the default branch. It records the resulting commit, and every worker of the run reads the files at that commit. Nothing is deployed: a change applies to the runs started after it reaches the default branch. To test a change, push it to a branch and start a run on a test repository with that branch as jobConfigContext. An error in ort-server.params.kts makes every new run fail.

The repository has no ort-server.conf and no resolutions.yml: ORT Server uses its default rule set and reporter settings, which point to these files, and no resolution applies to all runs.

Reference run configuration (body of POST /api/v1/repositories/{repositoryId}/runs, excerpt):

{
  "revision": "main",
  "jobConfigs": {
    "analyzer": { "allowDynamicVersions": true, "skipExcluded": true },
    "advisor": {
      "advisors": ["OSV", "VulnerableCode"],
      "config": {
        "OSV": { "options": { "serverUrl": "https://api.osv.dev" }, "secrets": {} },
        "VulnerableCode": { "options": { "serverUrl": "https://public.vulnerablecode.io/api/" }, "secrets": {} }
      },
      "skipExcluded": true
    },
    "scanner": {
      "scanners": ["ScanCode"],
      "createMissingArchives": true, "skipConcluded": true, "skipExcluded": true
    },
    "evaluator": {},
    "reporter": {
      "formats": ["CycloneDX", "SpdxDocument", "WebApp"],
      "config": {
        "CycloneDX": { "options": { "outputFileFormats": "XML,JSON" }, "secrets": {} },
        "SpdxDocument": { "options": { "outputFileFormats": "YAML,JSON" }, "secrets": {} }
      }
    }
  }
}

21.2. Occtet Curator #

Frontend environment (occtet-curator.frontend.env in the values.yaml of occtet-curator-helm-chart):

Other OCCTET values (under occtet-curator): imageRegistry ghcr.io/bitsea, imageTag latest and imagePullPolicy Always (section 15.2); postgresql.persistence.size and nats.persistence.size 50Gi, the sizes of the existing volumes. global.namespace (curator) stays under global. The other settings, such as the JVM options of the frontend and the resource requests and limits (section 21.6), are the defaults of the Bitsea chart 0.1.0.

OpenID Connect. Scopes requested: openid, profile, email and ort-server-api-access. User name attribute: preferred_username.

Administrator settings:

21.3. VulnerableCode #

Two VulnerableCode instances are available:

21.3.1. Public service #

Its REST API is https://public.vulnerablecode.io/api/v3/, documented at https://public.vulnerablecode.io/api/docs/. To reproduce the toolchain configuration, request an API key at https://public.vulnerablecode.io/account/request_api_key/. Then configure the service in each tool of the chain, as described below.

ORT Server

1. URL. The run configuration enables the advisor VulnerableCode with serverUrl: https://public.vulnerablecode.io/api/.
2. API key. Create an ORT Server secret named vulnerableCodeApiKey, whose value is the API key requested above, in the organisation, or in a product or repository, that runs the analyses (section 13.2).
3. Injection. When the public instance is used, ort-server.params.kts injects the key into the advisor configuration:

it.takeUnless {
    it.options["serverUrl"] == null || it.options["serverUrl"] == "https://public.vulnerablecode.io/api/"
} ?: it.copy(secrets = it.secrets + mapOf(
    "apiKey" to ResolvableSecret(name = "vulnerableCodeApiKey", source = SecretSource.USER)))

If the secret is missing, the advisor job fails (section 13.2).

Occtet Curator. An administrator enters the API key in the Curator configuration. The vulnerability service then sends bulk queries by package URL to POST /api/v3/packages on https://public.vulnerablecode.io.

Observed reliability. Many calls from ORT Server to the public VulnerableCode service failed during the period (sections 14.6 (Consolidated results of the instance) and 14.7 (Limits observed)), so VulnerableCode results on this instance are incomplete.

21.3.2. Local instance #

Deployment settings (values.yaml of the VulnerableCode deployment repository; the chart defaults are in vulnerablecode/values.yaml):

Use by the toolchain:

• ORT Server. A run uses the OCCTET instance when its advisor configuration sets serverUrl to https://vulnerablecode.occtet.eu/api/, or to the in-cluster address http://vulnerablecode-web.vulnerablecode.svc.cluster.local/api/. ort-server.params.kts injects the API key only for the public URL, and the OCCTET instance requires none, so no vulnerableCodeApiKey secret is needed.
• Occtet Curator. The address https://public.vulnerablecode.io is fixed in the code of the vulnerability service (RestClientConfig). Using the OCCTET instance therefore requires a change in the Curator.

21.4. Recommended proxy configuration #

The ORT Server, Curator and VulnerableCode proxies of the chart occtet-entrypoint set X-Forwarded-Proto to $scheme, which is http behind the ingress. A reproduction should keep the protocol received from the ingress instead, as the Keycloak proxy already does. The proxy configurations are the templates charts/occtet-entrypoint/templates/_nginx-<service>.tpl; for ORT Server, the change is:

map $http_x_forwarded_proto $proxy_x_forwarded_proto {
  default $http_x_forwarded_proto;
  ''      $scheme;
}

server {
  listen 80;
  location /alive { access_log off; return 200 "OK\n"; }
  location /api {
    proxy_pass        http://ort_server;            # ort-server-core.ort-server.svc.cluster.local:8081
    proxy_set_header  Host $host;
    proxy_set_header  X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header  X-Forwarded-Proto $proxy_x_forwarded_proto;
    proxy_set_header  X-Forwarded-Host $host;
    proxy_set_header  Authorization $http_authorization;
  }
  location / {
    proxy_pass        http://ort_server_ui;         # ort-server-ui.ort-server.svc.cluster.local:8082
    proxy_set_header  Host $host;
    proxy_set_header  X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header  X-Forwarded-Proto $proxy_x_forwarded_proto;
  }
}

Applying the same change to the chart, for the three proxies, is part of section 15.5, Operational readiness matrix.

21.5. Kubernetes Secrets #

The encryption material in ort-server-user-secrets-encryption is required to read the ORT Server user secrets. Losing it makes those secrets unrecoverable.

Do not delete occtet-keycloak-postgres: the chart would generate a new password that no longer matches the one stored in the database, and Keycloak could no longer connect.

PostgreSQL reads the VulnerableCode database credentials only when its volume is first initialised. Recreating vulnerablecode-secrets with new values while keeping the volume therefore breaks the database connection.

21.6. Resource requests and persistent volumes #

Requests and limits of CPU and memory set by the values of the components, and the persistent volumes of the installation.

Keycloak. Requests of 0.5 CPU and 512 MiB; limits of 1 CPU and 1 GiB.

ORT Server. Worker executions are started as Kubernetes Jobs, sized per worker:

By default, the JVM in a container uses 25% of the memory limit for its heap. The orchestrator therefore passes -XX:MaxRAMPercentage=75 to the reporter jobs (variable REPORTER_JDK_JAVA_OPTIONS). The maintenance CronJobs of section 9.3 run with the same option, requests of 0.1 CPU and 512 MiB, and limits of 1 CPU and 2 GiB.

VulnerableCode (section 6.8):

In total, the instance requests 2.75 vCPU and about 8.4 GiB of memory on the node pool it shares with the other services.

Persistent volumes. Sizes are the Kubernetes volume requests (GiB), which OVHcloud provisions and bills as GB of block storage.

Section 15.3 reconciles these volumes with the billed storage.