D5.1: Trust Orchestrator (first version)

D5.1: Trust Orchestrator (first version) PROJECT Project Number 101120962 Project Acronym RESCALE Project Title Revolutionised Enhanced Supply Chain Automation with Limited Threats Exposure Start Date 01.10.2023 Programme HORIZON-CL3-2022-CS-01-02 DELIVERABLE Deliverable Type Report Workpackage WP5 Deliverable Lead INT Editors Gogos Anastasios Contributors ISI, UPRC, AEGIS, EISI, S5, CBRL, DIE, CC, VUA, UNSPMF, ICERT, BNR, STS Dissemination Level Public Abstract This deliverable presents the first integrated version of the Trust Orchestrator Framework. As part of WP5, it integrates key security assessment technologies from WP3 (Static & Dynamic Analysis) and trust enforcement mechanisms from WP4 into a coherent solution, the ”RESCALE Platform”. The document outlines the architecture, functionalities, and initial deployment of the framework, focusing on the interaction between its core domains: Assessment, Security & Trust, and Management. Key integration components such as the State Manager, Trust Orchestrator (TrustOR), along with the security validation data flows are described in detail. Additionally, this deliverable discusses the continuous integration and deployment (CI/CD) approach, the use of containerized environments, the challenges encountered and the technical infrastructure supporting the platform. By establishing a foundational, trusted supply-chain prototype, this version of the Trust Orchestrator Framework sets the stage for further refinements, validation, and deployments in subsequent project phases. Disclaimer The information in this document is provided “as is”, and no guarantee or warranty is given that the information is fit for any particular purpose. The content of this document reflects only the author’s view – the European Commission is not responsible for any use that may be made of the information it contains. The users use the information at their sole risk and liability. This project has received funding from the European Union’s Horizon Europe research and innovation programme under grant agreement No 101120962 D5.1: Trust Orchestrator (first version) Document Revision & Quality Assurance Internal Reviewers 1. UPRC — UNIVERSITY OF PIRAEUS RESEARCH CENTER 2. ICERT — INFOCERT SPA Revisions Version Date Partner Overview 1.0 28/02/2025 ISI, AEGIS, INT Final version 0.19 27/02/2025 UPRC, ICERT Internal review, content polishing 0.18 26/02/2025 INT, UPRC Internal review, document curation 0.17 25/02/2025 AEGIS, UPRC Internal review, document curation 0.16 24/02/2025 INT Document curation, Supported Flows, images, RESTful 0.15 21/02/2025 INT, EISI Chapter 2, 3, Abbreviations, Sec. & Trust Domain 0.14 20/02/2025 STS Security Assurance curation 0.13 19/02/2025 AEGIS State Manager curation, image additions 0.12 17/02/2025 INT TrustOR functionalities 0.11 14/02/2025 INT Ifrastructure View, Platform Deployment, Conclusions 0.10 13/02/2025 INT Integration Technologies (use within RESCALE) 0.9 12/02/2025 UNSPMF, INT Assessment domain, TrustOR functionalities 0.8 11/02/2025 STS, INT Security Assurance, D5.1 introduction 0.7 29/01/2025 INT Integration Technologies introduction 0.6 08/01/2025 AEGIS State Manager 0.5 29/12/2024 AEGIS Management Domain, Dashboard, State Manager 0.4 17/12/2024 CBRL KrakenD 0.3 04/12/2024 INT ToC minor changes & enhancements 0.2 03/12/2024 INT Preparation of doc structure & ToC 0.2 07/11/2024 BNR First draft 0.1 22/10/2024 ISI Initialization of Overleaf Document RESCALE – Public – Page 2 / 80 Table of Contents 1 Introduction 8 1.1 Scope&Contribution............................... 8 1.2 Relation to Work Packages, Deliverables, and Activities . . . . . . . . . . . . . 9 1.2.1 Connections to Other Deliverables . . . . . . . . . . . . . . . . . . . . 10 1.3 Contribution to WP5 and Project Objectives . . . . . . . . . . . . . . . . . . . 10 1.4 Structure of the Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2 Trust Orchestrator Framework 13 2.1 AssessmentDomain................................ 14 2.2 Security&TrustDomain............................. 15 2.3 ManagementDomain............................... 16 3 Trust Orchestrator Framework Functionalities 18 3.1 ManagementDomain............................... 18 3.1.1 Dashboard................................. 18 3.1.2 StateManager............................... 22 3.1.3 TrustORcomponent ........................... 28 3.2 Security&TrustDomain............................. 32 3.2.1 LedgerAdapter.............................. 32 3.2.2 SecurityAssurance ............................ 35 3.3 SupportedFlows ................................. 37 3.3.1 Register software/hardware component . . . . . . . . . . . . . . . . . 37 3.3.2 SSCG Generation & Submission . . . . . . . . . . . . . . . . . . . . . 38 3.3.3 DSCG Generation & Submission . . . . . . . . . . . . . . . . . . . . . 40 3.3.4 TBOMCreation.............................. 42 4 Integration Activities 45 4.1 Technologies ................................... 45 4.1.1 Git&GitLab ............................... 46 4.1.2 Docker .................................. 47 4.1.3 Harbor................................... 48 4.1.4 Keycloak/IAM.............................. 49 4.1.5 Jenkins .................................. 51 4.1.6 Portainer ................................. 53 4.1.7 RESTfulAPIs............................... 54 4.1.8 KrakenD ................................. 56 4.2 Testing....................................... 57 4.2.1 TrustOR Pipeline Example . . . . . . . . . . . . . . . . . . . . . . . . 57 4.2.2 Expanding Testing to Other RESCALE Components . . . . . . . . . . 58 4.3 Deployment.................................... 58 4.3.1 InfrastructureView............................ 58 4.3.2 RESCALE Platform Deployment . . . . . . . . . . . . . . . . . . . . . 61 5 Conclusions & Future Steps 64 5.1 Challenges & Lessons Learned . . . . . . . . . . . . . . . . . . . . . . . . . . 64 5.2 Conclusions.................................... 65 5.3 FutureSteps.................................... 65 3 D5.1: Trust Orchestrator (first version) 6 Appendix 69 6.1 RESCALE Development Platform - Docker compose file . . . . . . . . . . . . 69 6.2 TBOM creation: end-to-end flow . . . . . . . . . . . . . . . . . . . . . . . . . 71 RESCALE – Public – Page 4 / 80 List of Figures 1 RESCALE High-level Architecture depicting the 3 domains . . . . . . . . . . . . 14 2 Producer View of the RESCALE Dashboard . . . . . . . . . . . . . . . . . . . . . 19 3 Component Registration Demonstration . . . . . . . . . . . . . . . . . . . . . . . 20 4 Consumer View of the RESCALE Dashboard . . . . . . . . . . . . . . . . . . . . 21 5 VulnerabilitiesReport................................. 22 6 StateManagerAPIs.................................. 24 7 Keycloakloginvalidation............................... 25 8 TrustOR API endpoints displayed by Swagger [22]................. 29 9 TokenAPI....................................... 36 10 ProjectAPI ...................................... 36 11 SBOMAPI ...................................... 37 12 Producer registers new component and gets access token . . . . . . . . . . . . . . 38 13 Producer runs the Static Analysis and submits SBOM+SSCG . . . . . . . . . . . . 39 14 Consumer runs the Dynamic Testing and submits DSCG . . . . . . . . . . . . . . 41 15 TBOMcreationprocess................................ 43 16 GitLab - list of some RESCALE code repositories . . . . . . . . . . . . . . . . . . 47 17 Harbor-Projectsview ................................ 49 18 Harbor - Image with multi-platform artifacts . . . . . . . . . . . . . . . . . . . . . 50 19 Harbor-UserGroupsview.............................. 51 20 Keycloak - User Groups view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 21 Jenkins - Example of a TrustOR pipeline . . . . . . . . . . . . . . . . . . . . . . . 53 22 Portainer - list of containers running the CI/CD services . . . . . . . . . . . . . . . 55 23 Portainer - The 3 environments currently provided through 3 independent VMs . . 56 24 Failing Jenkins pipeline followed by a successful one . . . . . . . . . . . . . . . . 57 25 InfrastructureView .................................. 59 26 Jenkins: Pipeline for deploying the ”dev-platform” . . . . . . . . . . . . . . . . . 63 27 Portainer: Containers running the “dev-platform” services . . . . . . . . . . . . . . 63 5 D5.1: Trust Orchestrator (first version) List of Abbreviations ABI Application Binary Interface. 33 API Application Programming Interface. 5, 11, 16, 17, 22, 24, 26, 29, 30, 36, 37, 41, 45, 54–56 BOM Bill of Materials. 10 BOV Bill Of Vulnerabilities. 42–44, 65 CI/CD Continuous Integration / Continuous Deployment. 5, 9, 45, 46, 48, 50–55, 57–59, 61, 62, 65, 66 CVE Common Vulnerabilities and Exposures. 15, 28, 32 CWE Common Weakness Enumeration. 15 DevOps Development Operations. 51, 53 DL Deep Learning. 15 DLT Distributed Ledger Technology. 32 DSCG Dynamic Supply Chain component Guarantee. 9, 15–18, 21, 23, 24, 27, 29–31, 37, 40, 42, 43, 60, 65 HTTPS Hypertext Transfer Protocol Secure. 62 IAM Identity & Access Management. 17, 25, 49, 50, 60 JSON JavaScript Object Notation. 36, 43, 55 JWT JSON Web Token. 23, 25 LDAP Lightweight Directory Access Protocol. 48, 49 MFA Multi-Factor Authentication. 50 ML Machine Learning. 15 OIDC OpenID Connect. 48, 50, 59 RBAC Role-Based Access Control. 48–50, 53 REST Representational State Transfer. 11, 16 SAML Security Assertion Markup Language. 49 SBOM Software Bill of Materials. 5, 9, 14–16, 23, 27–31, 35, 37–40, 42–44, 60, 65 RESCALE – Public – Page 6 / 80 D5.1: Trust Orchestrator (first version) SCM Source Code Management. 46 SSCG Static Supply Chain component Guarantee. 9, 15–18, 21, 23, 24, 27, 29–31, 37–43, 60, 65 SSL Secure Sockets Layer. 62 SSO Single Sign-On. 49, 50 TBOM Trusted Bill of Materials. 8, 9, 11, 15–18, 24, 27, 28, 30, 32–34, 42–44, 60, 65 TLS Transport Layer Security. 62 TrustOR Trust Orchestrator Component. 1, 5, 8, 9, 11, 13, 16, 22, 24, 28, 29, 31, 32, 38–40, 42–44, 52, 53, 57, 60 UUID Universally Unique Identifier. 28 VCS Version Control System. 46 VM Virtual Machine. 5, 47, 48, 54, 56, 58–62 WP Work Package. 9, 66 RESCALE – Public – Page 7 / 80 D5.1: Trust Orchestrator (first version) 1 Introduction This deliverable presents the first integrated version of the Trust Orchestrator Framework, which forms the foundation of the RESCALE project. The framework integrates multiple security and trust-related components with the goal of providing a platform that ensures trust in the software supply chain. The following sections outline its purpose, contributions, and alignment with the project’s objectives. This work is carried out as part of WP5, specifically under Task 5.1, which focuses on the integration and deployment of RESCALE solutions. 1.1 Scope & Contribution The Trust Orchestrator Framework is the overarching system within RESCALE that integrates all security and trust-related components developed by project partners. It integrates multiple tools and technologies that collectively ensure supply chain security, enable validation and enforce trust. The operations of the Static Analysis and Dynamic Testing tools were previously described in WP3 deliverables, submitted in November 2024, and cover with details how the 1st domain of the RESCALE architecture works, specifically the: •The Assessment Domain, responsible for combining multiple and different ways of testing software and hardware. With this deliverable, D5.1, our focus now shifts to the other two key domains of the RESCALE architecture : •The Management Domain, responsible for orchestrating and integrating security assessment components. •The Security & Trust Domain, which ensures the trustworthiness of security validation and assurance mechanisms. In particular, WP3 tools interact with the Trust Orchestrator Framework by generating security analysis results that are submitted to the Management Domain and specifically the State Manager component. State Manager acts as an intermediary, it’s the entry-point for receiving static and dynamic analysis results, which are then forwarded and processed by other components of the framework. This document focuses on two critical components: the State Manager and the TrustOR component (TrustOR). These components form the backbone of RESCALE’s security validation and trust establishment processes. The State Manager is a key component of the framework, serving as the central coordination point for user interactions and security data management. The Dashboard relies on the State Manager as its backend service, providing end-users with visibility into security assessments. Tools from the Assessment Domain submit their results to the State Manager. The State Manager, however, depends on TrustOR for handling all Trusted Bill of Materials (TBOM)-related processes. RESCALE – Public – Page 8 / 80 D5.1: Trust Orchestrator (first version) The Trust Orchestrator (TrustOR) component is responsible for validating, consolidating, and structuring the SBOMs, SSCGs, and DSCGs that flow through the State Manager from the WP3 tools. It ensures that all security assessment outputs are properly validated before they are integrated into the TBOM. TrustOR also plays a critical role in combining multiple security inputs to generate trusted artifacts, making it a key enabler of the RESCALE security model. Deliverable D5.1 - Trust Orchestrator (first version), describes the first integrated version of the Trust Orchestrator Framework and outlines: • The architecture of the Trust Orchestrator Framework, covering its three domains (Assessment, Security & Trust, and Management) and the interplay between their respective components. • The role of the State Manager as a central hub for user interactions and security data management and its dependency on TrustOR for TBOM-related processes. • The function of TrustOR as the TBOM validation and generation engine, responsible for consolidating and structuring security assessment results. • The integration of partner-developed components, including assessment tools, security repositories, state management, and the dashboard. • The deployment and validation activities, detailing the CI/CD approach, containerized infrastructure, and automated workflows used for platform integration. • The challenges and next steps, including ongoing efforts to enhance security, refine trust models, and optimize platform deployment for future iterations. This version of the framework establishes the fundamental integration mechanisms and serves as a foundation for future refinements, ensuring that RESCALE’s security and trust mechanisms continue to evolve. 1.2 Relation to Work Packages, Deliverables, and Activities This deliverable is part of Work Package 5 (WP5) - Integration, Deployment, and Validation, which is responsible for: • Integrating technologies from WP3 (Static and Dynamic Analysis) and WP4 (Trusted Supply Chain Establishment) into a unified framework. • Deploying the Trust Orchestrator Framework in pilot environments. • Validating and evaluating the effectiveness of the integrated solution. This deliverable primarily takes input from WP3 and WP4 and consolidates their outcomes into a single integrated framework. Specifically: RESCALE – Public – Page 9 / 80 D5.1: Trust Orchestrator (first version) platform and entails placing event captors throughout the platform to detect malicious ongoings. The second element is the continuous vulnerability detection which informs of when new vulnerabilities are found for a target present software or dependency present in a TBOM on the RESCALE platform. 2.3 Management Domain The Management Domain is responsible for orchestrating and coordinating all components within the Trust Orchestrator Framework. It ensures that the various security and assessment mechanisms are integrated efficiently, enabling seamless communication between the security analysis tools, the validation mechanisms, and the trust enforcement processes. To achieve this, it encompasses several key functions, including: • Lifecycle management of security assessments and trust models • Interoperability between RESCALE components • User interaction, visualization, and control mechanisms The core components of this domain are the State Manager, the Trust Orchestrator component (TrustOR), the Dashboard, and the Authentication / Identity Access Management mechanism. These components are explained in more detail below. •State Manager: acts as a central data and coordination hub for the platform. It provides a first-level data management and collaborates with TrustOR to handle all TBOM-related processes, including validation and trust enforcement. It is responsible for: –Storing and managing security assessment results, including outputs from static and dynamic analysis tools. –Handling user interactions through the Dashboard, which relies on the State Manager as its backend. –Providing structured access to security artifacts, such as SBOMs, SSCGs, and DSCGs, and ensuring that they are available for further processing. •Trust Orchestrator (TrustOR): is a component that exposes a REST API-based integration layer responsible for: –Validating security assessment outputs before they are incorporated into the TBOM. –Ensuring consistency and compliance by checking the correctness of SSCGs, DSCGs, and SBOMs. –Generating and updating TBOMs by consolidating validated security data from the Security Assurance. –Facilitating interoperability between different security validation mechanisms within RESCALE. RESCALE – Public – Page 16 / 80 D5.1: Trust Orchestrator (first version) •Dashboard: Is the primary user-facing component of the RESCALE platform, providing a visual interface for interacting with security validation workflows. It acts as a frontend to the State Manager, ensuring that all interactions are traceable, intuitive, and accessible for stakeholders. Through the Dashboard, users can: –Monitor and review security assessments, such as SSCGs and DSCGs. –Track the lifecycle of TBOMs, including updates based on newly identified vulnerabilities. –Access historical data and reports for security compliance verification. •Authentication & IAM: Given the sensitive nature of the security validation processes in RESCALE, robust access control mechanisms are enforced via authentication and authorization. The integration with an Identity and Access Management (IAM) system in this first version of the RESCALE Platform ensures that: –Only authorized users can interact with the security data and workflows through the Dashboard. –The State Manager API follows strict authentication protocols, ensuring secure communication between the assessment tools and the platform. The Management Domain is the backbone of the Trust Orchestrator Framework, providing the coordination, validation and governance mechanisms required to establish a trusted security assurance pipeline. The following two chapters will delve into: 1. The technical implementation and deployment of the framework. 2. The integration of these components and how they interact within the platform. RESCALE – Public – Page 17 / 80 D5.1: Trust Orchestrator (first version) 3 Trust Orchestrator Framework Functionalities This chapter details the internal structure of the Trust Orchestrator Framework, focusing on its key operational domains and their role in integrating security assurance mechanisms. It is organized as follows: Section 3.1 introduces the Management Domain, responsible for coordinating interactions between the various components. Section 3.2 describes the Security & Trust Domain, which handles validation, risk assessment, and enforcement of security policies. Finally, Section 3.3 presents the supported flows, illustrating how different processes operate within the framework to enable seamless security assurance and trust management. 3.1 Management Domain 3.1.1 Dashboard The RESCALE dashboard is a centralized platform designed to increase trust in the software supply chain by facilitating assessments. It provides a user-friendly interface that streamlines access to testing functionalities and consolidates all relevant information in a structured manner. By offering intuitive navigation and real-time insights, the dashboard enhances the assessment process, allowing users to evaluate software and hardware components efficiently and make informed decisions. To ensure a tailored user experience, the dashboard dynamically adapts to different user roles, providing customized features based on access levels. Users are categorized into roles such as producers and consumers, each with distinct functionalities. Producers can register software components, initiate SSCG generation, and monitor DSCG and TBOM statuses. Consumers can browse all registered components, perform dynamic analyses, and generate DSCG reports. The dashboard adjusts available options and interface elements according to the user’s role, ensuring a streamlined and relevant experience for each type of user. It includes the following key sub-components: 1. Producer Functionality: This component provides a dedicated interface for producers to register software components. The platform offers the necessary means to enable the producer to initiate the procedures required for SSCG generation. Producers can also monitor the statuses of the DSCG and TBOM, accessing their respective segments for detailed and actionable information. 2. Consumer Functionality: This component offers consumers a designated page displaying all registered software components on the platform. Consumers can select specific components to perform dynamic analyses, enabling them to assess and evaluate the components’ functionality, compliance, and security posture effectively. In the following Figure: 2, there is an overview of the Producer View in the RESCALE dashboard. The Producer View provides an overview of all functionalities available to producers within the RESCALE dashboard. This interface is designed to streamline the producer’s workflow, enhance user experience, and ensure all relevant information is easily accessible. RESCALE – Public – Page 18 / 80 D5.1: Trust Orchestrator (first version) Figure 2: Producer View of the RESCALE Dashboard Following is a demonstration of how a component is registered using the RESCALE dashboard’s producer functionality, as shown in Figure 3. The Component Registration interface allows producers to register new software components. The clean, intuitive layout ensures that producers can complete the registration process efficiently and accurately. The registration process involves the following key steps: •Input Component Details: Producers enter essential metadata such as component name, programming language, and description. •Validation and Compliance Check: The system performs an initial validation to ensure all necessary fields are filled and comply with predefined requirements. •Submit for Registration: Upon successful validation, the producer submits the component for registration, making it available for further analysis. RESCALE – Public – Page 19 / 80 D5.1: Trust Orchestrator (first version) Figure 3: Component Registration Demonstration RESCALE – Public – Page 20 / 80 D5.1: Trust Orchestrator (first version) Figure 4 shows an overview of the Consumer View in the RESCALE dashboard. The Consumer View provides consumers with a comprehensive interface to access and analyze all registered software components. To enhance ease of use, consumers can utilize the search bar and available filters to quickly locate specific components. If an SSCG is active, consumers can browse through selected versions and view the corresponding SSCG JSON. Additionally, consumers can initiate the process of generating the DSCG report, enabling a thorough assessment of component functionality, compliance, and security posture. This interface is designed to streamline the consumer’s workflow, enhance user experience, and ensure all necessary information is readily accessible. Figure 4: Consumer View of the RESCALE Dashboard RESCALE – Public – Page 21 / 80 D5.1: Trust Orchestrator (first version) Both producers and consumers have access to view vulnerabilities within the RESCALE dashboard. The vulnerability display is structured to ensure that key information is easily accessible and categorized effectively. Vulnerabilities are classified based on severity levels, such as critical, high, medium, and low, allowing users to prioritize risks accordingly. The container presenting vulnerabilities includes a designated area that highlights critical fields, providing users with a general overview of the vulnerability report. Additionally, newly detected vulnerabilities are automatically linked to the corresponding software components, ensuring traceability. This structured presentation enables users to quickly assess potential security risks, track affected components, and make informed decisions regarding mitigation strategies. Figure 5: Vulnerabilities Report 3.1.2 State Manager 3.1.2.1 Overview The State Manager acts as the central orchestrator for the RESCALE platform’s backend, handling API requests from all components outside the management layer, providing API endpoints for the rest of the RESCALE components to enable their functionalities, such as the Dashboard, the Static and Dynamic Analysis Modules, the TrustOR, and the Security Assurance pipeline, allowing for interconnectivity, and enabling the data flow inside the RESCALE platform. The State Manager is tasked with: 1. Data Management: RESCALE – Public – Page 22 / 80 D5.1: Trust Orchestrator (first version) • Storing and updating persistent data, such as user profiles and their associated components. • Processing incoming requests and directing them to the appropriate modules within the RESCALE platform. 2. Action Validation: • Ensuring the validity and integrity of actions performed within the platform. • Utilizing multiple methods and technologies for validation, including Keycloak for authentication, JWT tokens for secure session management, cryptographic hashes for data verification, with plans to incorporate digital certificates for enhanced security in future updates. 3. Orchestration: • Coordinating workflows between RESCALE components, such as Static and Dynamic Analysis, TrustOR, and the Security Assurance pipeline. • Managing interdependencies and consistency, such as ensuring SSCG and DSCG serialNumbers align correctly with SBOM versions. • Ensuring seamless data flow and processing to maintain platform consistency and enable real-time collaboration among components. This approach enables the State Manager to act as an orchestrator, maintaining trust, security, and functionality across the entire RESCALE ecosystem. 3.1.2.2 Endpoints The following section outlines the endpoints that facilitate interaction between users, as well as Static and Dynamic analysis components, with the RESCALE Platform in its first integrated version. Each endpoint includes a description of its functionality and is shown in Figure: 6 All the State Manager endpoints which are deemed mandatory for the End-to-End flow are keycloak protected and presented below: •GET /dashboard/getUserInfo - Returns information about the authenticated user from the Keycloak token •POST /repo/ComponentSet - Saves the uploaded component to MongoDB •GET /dashboard/getAllUserComponents - Returns all the components of the user •GET /token/<ComponentHash> - Creates and returns an Access Token to be used by SSCG and DSCG Generators •POST /sscg - Receives the SSCG and SBOM reports from SSCG Generator, updates the component under test and forwards the report to TrustOR •GET /sscgGetSN/<name>/<version> - Returns the serialNumber of the SSCG report for the requested version for the component <name> RESCALE – Public – Page 23 / 80 D5.1: Trust Orchestrator (first version) Figure 6: State Manager APIs •GET /sscgGet/<serialNumber> - Return the SSCG Report with the requested serialNumber •POST /dscg - Receives the DSCG report from the DSCG Generator, updates the component under test and forwards the report to TrustOR •GET /dscgGetSN/<name>/<version> - Returns the serialNumber of the DSCG report for the requested version for the component <name> •GET /dscgGet/<serialNumber> - Return the DSCG Report with the requested serialNumber •POST /tbom - Receives the TBOM report from the TrustOR and updates the component under test. •GET /tbom/<serialNumber> - Returns the TBOM report with the requested serialNumber •POST /SecAssurance - Receives Vulnerability Reports for a specific TBOM and updates its list of vulnerabilities RESCALE – Public – Page 24 / 80 D5.1: Trust Orchestrator (first version) 3.1.2.3 Persistent Storage User information and its components require persistent storage for retrieval and update operations. This necessity creates the requirement for an internal database within the management module to handle users and components. The database must support structured storage, quick access, and update operations to ensure the desired functionality of the module. To meet these needs, MongoDB has been selected as the current database solution. Its document-oriented model provides flexibility in managing diverse data structures, making it well-suited for the prototype integration, as shown in figure 7. However, while MongoDB effectively serves the present requirements, its use remains subject to change. As the system grows in complexity, factors such as performance optimization, scalability, and integration with other components may give rise to a shift to a different database solution if required. 3.1.2.4 User Interaction The State Manager handles RESCALE Users and their assets by primarily interacting with the Dashboard and the IAM Mechanism (Keycloak). Once a RESCALE user logs into the RESCALE platform through the dashboard, the State Manager authenticates their identity via Keycloak. Keycloak verifies the credentials of the user and then provides them with a JWT Token. This token is used for any further HTTP requests from this user to the State Manager, validating their identity. The State Manager extracts the token from the headers of requests and validates it with Keycloak. If the token is valid, the request is accepted and forwarded to the appropriate module within the RESCALE Platform. The State Manager ensures that access to the RESCALE platform is appropriately restricted to authorized users. Figure: 7 depicts the procedure of user authentication via Keycloak. Figure 7: Keycloak login validation RESCALE – Public – Page 25 / 80 D5.1: Trust Orchestrator (first version) • Accepting security alerts related to existing TBOMs. • Storing alerts along with metadata such as affected component, vulnerability ID (CVE), severity, and timestamp • Triggering updates / revalidation workflows for impacted artifacts and proper notifications that will reach the relevant stakeholders of the vulnerability exposure, by passing through the State Manager and the Dashboard components. Endpoint: •POST /api/security alerts/ – Submit a new security alert By integrating real-time security notifications, TrustOR ensures that previously validated TBOMs remain accurate and up-to-date, enhancing supply chain security over time. 3.2 Security & Trust Domain Herein we describe the functionalities provided to the first integrated version of the RESCALE platform by the RESCALE security and trust components developed on WP4. The following subsections describe the functionalities provided by the Ledger Adapter (3.2.1) which, in short, provides blockchain and immutable trust storage to the RESCALE platform using the Hyperledger Besu blockchain, as discussed in D4.4. The TrustOR connects to the ledger adapter via the management module, forming the link between the trusted orchestrator and the immutable ledger. The Security Assurance mechanism (3.2.2) which is focused on the potential of vulnerabilities, attacks or intrusions into the RESCALE platform. 3.2.1 Ledger Adapter The Ledger Adapter component serves as an abstraction layer designed to simplify blockchain write operations by encapsulating the underlying technical complexity. Without this intermediary layer, end users would need to manually execute multiple sequential tasks—including transaction creation, cryptographic signing, and network submission—to achieve ledger updates. By exposing a streamlined Python-based API, the Ledger Adapter enables developers to interact with the Distributed Ledger Technology (DLT) through a unified interface, significantly reducing operational overhead. The Ledger Adapter library provides four principal operations to facilitate blockchain interactions: • it verifies ledger connectivity to ensure network availability before executing critical tasks; • it supports the addition of Trusted Bill of Materials (TBOM) hashes to the ledger, enabling immutable record-keeping for supply chain or software bill of materials use cases; RESCALE – Public – Page 32 / 80 D5.1: Trust Orchestrator (first version) • it validates the integrity and authenticity of TBOM entries; • it allows for the deprecation of obsolete TBOM records, ensuring data relevance while maintaining audit trails. To operationalize the Ledger Adapter, developers must configure the following environment variables: • BESU ENDPOINT: Specifies the HTTP/HTTPS URL of the Hyperledger Besu node for blockchain connectivity. • CONTRACT ADDR PATH: Defines the filesystem path to the smart contract address, which governs ledger interaction logic. • CONTRACT JSON PATH: Points to the JSON file containing the Application Binary Interface schema for the deployed smart contract. • CLIENT PRVKEY PATH: Contains the elliptic curve private key for transaction signing, stored in a secure file. • CLIENT PUBKEY PATH: Provides the corresponding public key for identity verification during transaction validation. After successful configuration, developers can execute four primary operations through the Ledger Adapter’s API, each handling specific aspects of blockchain interaction. The following sections describe each function in detail, explaining their role in blockchain interactions. 3.2.1.1 Check Besu connectivity The adapter provides a health check mechanism to confirm node accessibility before executing critical operations. The following implementation tests connection to the Hyperledger Besu network by retrieving the chain identifier. This function requires no input parameters and returns a string representing the blockchain network identifier in hexadecimal format: get_chainid() -> str Listing 6 provides an example of usage. from trust_storage_client . besu_client import get_chainid print (" Check connectivity with BESU node :") chain_id = get_chainid () print (f" Chain ID : { chain_id }") Listing 6: Checking Connectivity RESCALE – Public – Page 33 / 80 D5.1: Trust Orchestrator (first version) 3.2.1.2 Adding a Document To permanently store document hashes on the ledger, developers utilize the document addition workflow. The process includes file ingestion, content hashing, and transaction submission. The function accepts a document string as input and returns a dictionary containing the computed TBOM hash and transaction logs: add_besu(document: str) -> dict Listing 7 provides the typical structure of the output of add besu: { ’hash ’: <Keccak -256 hash of TBOM >, ’logs ’: [ // Array of emitted events { ’address ’: <20byte contract address >, ’topics ’: [ // Array of indexed event parameters <Keccak -256 hash of event signature >, <32bytes indexed parameter 1>, <32bytes indexed parameter 2>, < ... > ], ’data ’: <ABI - encoded non - indexed parameters >, ’blockNumber ’: <hex string >, ’blockHash ’: <32byte hex string >, ’ transactionHash ’: <32 - byte hex string >, ’transactionIndex ’: <hex string >, ’logIndex ’: <hex string >, ’removed ’: <boolean > } ] } Listing 7: add besu output dictionary structure All hexadecimal values are represented as strings with ’0x’ prefix. Block and transaction positions are encoded as hex strings (e.g., ’0xc’ for block 12). The transaction hash uniquely identifies the transaction on the blockchain, while each log entry captures a specific event emitted during execution, with indexed parameters stored in topics and non-indexed parameters in the data field. Listing 8 provides an example of usage. from trust_storage_client . besu_client import add_besu with open ("/ path/to/ your/document . json ") as f: document_content = f. read () print (" Adding document to blockchain :") result = add_besu ( document_content ) document_hash = result [’ hash ’] print (f" Document hash : { document_hash }") Listing 8: Document addition RESCALE – Public – Page 34 / 80 D5.1: Trust Orchestrator (first version) 3.2.1.3 Retrieving a Document The retrieval mechanism enables cryptographic proof of existence checks through hash-based lookup. This function accepts a Keccak256 hash string (with 0xprefix) of the TBOM as input and returns a boolean value confirming existence. Users can obtain this hash directly from the hash key in the output of the add besu function (see paragraph 3.2.1.2). get_besu(ahash: str) -> bool Listing 9 provides an example of usage. from trust_storage_client . besu_client import get_besu print (" Checking if document exists :") try : exists = get_besu ( document_hash ) print (f" Document exists : { exists }") except RuntimeError as e: print (f" Error : {e }") Listing 9: Check document hash existence 3.2.1.4 Deprecating a Document To mark records as obsolete while maintaining audit trails, the deprecation function updates document status flags. This function accepts a Keccak256 hash string (with 0xprefix) of the TBOM as input and returns a boolean success indicator. This hash value can be directly obtained from the output of the add besu function under the key ’hash’ (see paragraph 3.2.1.2). deprecate_besu(ahash: str) -> bool Listing 10 provides an example of usage. from trust_storage_client . besu_client import deprecate_besu print (" Deprecating document :") try : success = deprecate_besu(document_hash) print (f" Document deprecated successfully : { success }") except RuntimeError as e: print (f" Error : {e }") Listing 10: Document deprecation 3.2.2 Security Assurance The Continuous Security Assurance platform will provide the vulnerabilities related to the modeled cyber system. To support that, the SBOM of the cyber system, will be sent for processing over an authenticated channel. RESCALE – Public – Page 35 / 80 D5.1: Trust Orchestrator (first version) 3.2.2.1 Authentication To get access to the Continuous Security Assurance platform, the first step is to request a token from the authentication system (see Figure 9): Figure 9: Token API Request: { " client_id ": "{ clientId }" , " grant_type ": " password ", " username ": "{ username }" , " password ": "{ password }" } Response: { " access_token ": "{ token }" , " expires_in ": 30 , " refresh_expires_in ": 180 , "refresh_token": "{refreshToken}", " token_type ": " Bearer ", "not - before - policy ": 0, " session_state ": "{ stateUUID }", " scope ": " profile email " } 3.2.2.2 Project creation To map the identified systems’ vulnerabilities, a new project will be created. Using the JSON Web Token retrieved from the aforementioned system, the following endpoint will be called: Figure 10: Project API Request: { "name ":"{ projectName }", "description":"{description}", "organisationId":"{organisationId}", " status ":" DEFINED ", " activeFrom ":"{ currentTimestamp }" , " visible ": true , " isClientProject ": false } RESCALE – Public – Page 36 / 80 D5.1: Trust Orchestrator (first version) Response: { projectId } 3.2.2.3 Sending the SBOM Finally, the last step is to process the SBOM. If the SBOM is valid and vulnerabilities are identified, they will be sent to the TrustOR system. Figure 11: SBOM API Request: { "file ": "{ SBOM.json }" } Response: { " message ": "The provided SBOM is being processed " } 3.3 Supported Flows This section provides a detailed breakdown of the key operational flows within the RESCALE platform. Through a series of sequence diagrams, we illustrate the step-by-step interactions between users and the various system components, highlighting how internal processes are executed. The goal of these diagrams is to offer a clear and structured view of how a RESCALE user (producer or consumer) can submit security assessment results (SBOMs, SSCGs, and DSCGs) and then the process of generating a Trusted Bill of Materials (TBOM) is automatically triggered inside TrustOR. Each diagram presents the exact sequence of interactions between system components such as the Dashboard, State Manager, TrustOR, and security assessment tools, ensuring that all steps necessary to achieve a secure and trusted software supply chain are fully documented. 3.3.1 Register software/hardware component The sequence of registering a software or a hardware component includes the following actions: • Authenticate user by providing necessary credentials to through the Dashboard UI RESCALE – Public – Page 37 / 80 D5.1: Trust Orchestrator (first version) • Register a new component by providing the prerequisites (fields like Name,Programming language) • Validate user information and tokens provided through the Authentication component • Request access token for using it at the next step, the Static Analysis At the initial stage of the TBOM creation process, the producer interacts with the Dashboard to register a new software or hardware component. The registration request is forwarded to the State Manager, which validates the user’s authentication token, extracts the user’s ID, and computes a Component Hash to uniquely identify the component. Once the registration is complete, the user requests an Access Token to continue further interactions with the platform. The State Manager validates the request and generates an Access Token that encapsulates the Component Hash and authentication details, to ensure a secure interaction for the next step of the flow. Figure 12: Producer registers new component and gets access token 3.3.2 SSCG Generation & Submission The sequence of creating and submitting the SSCG includes the following actions: • Validate the access token. • Parse the component’s hash from the token and verify its existence. • Extract the SBOM version and SSCG serialNumber. • Forward the SBOM and SSCG to TrustOR to store it. • Once successfully stored, update the component’s record and notify the user. RESCALE – Public – Page 38 / 80 D5.1: Trust Orchestrator (first version) Figure 13: Producer runs the Static Analysis and submits SBOM+SSCG It can be easily observed by looking at the sequence diagram of Figure 13 that the State Manager and the TrustOR component are two key components in the Static Analysis workflow, responsible for validating, processing, and integrating SBOM and SSCG results into the RESCALE platform. From the previous step, it was the State Manager’s first responsibility to generate a token that will now be provided to the Static Analysis Module and will be used for validation afterwards. The Producer who has already received this token from the State Manager via RESCALE DashRESCALE – Public – Page 39 / 80 D5.1: Trust Orchestrator (first version) board, is now required to provide it to the Static Analysis Module container as input. When the Static Analysis results are received from the SSCG module, the State Manager begins by performing a series of pre-checks: It validates the access token provided in the request to ensure proper authorization and parses the token to extract the component’s hash. This hash is the Universal-Unique-Identifier for the component, which is then cross-referenced to verify that the component exists in the platform’s records. If the component is not found, the process is aborted immediately. Once the initial validations are complete, the State Manager retrieves essential data from the analysis results. It extracts the software version from the provided SBOM and retrieves the SSCG serialNumber for further validation and processing. The SBOM and SSCG are then forwarded to the TrustOR component, where a comprehensive set of checks are performed to ensure the integrity and validity of the data. TrustOR begins by verifying that the component name and version specified in the SBOM exist in the system. It then ensures that the SSCG references the SBOM’s correct serialNumber, confirming the consistency of the results. TrustOR further checks the uniqueness of both the SBOM’s serialNumber and the SSCG’s serialNumber by interacting with the RESCALE Repository. These steps are essential to prevent duplication and maintain the integrity of the platform’s data. Additional checks include validating the format and compliance of the SBOM and SSCG with the CycloneDX [19] specification. If any of these validations fail at any stage, the State Manager terminates the process and notifies the SSCG of the failure, forwarding the corresponding error received from the TrustOR. Once the results pass all checks, the State Manager coordinates with TrustOR to store the data. TrustOR hashes the SBOM for secure identification and saves both the SBOM and SSCG in the RESCALE Repository. The SSCG must include the SBOM’s serialNumber and its hash to ensure traceability and integrity. Finally, the State Manager updates the component’s record with the SBOM’s version and the SSCG serialNumber. It then sends a success response back to SSCG, and communicates this success to the user. 3.3.3 DSCG Generation & Submission The sequence of creating and submitting the DSCG includes the following actions: • Consumer retrieve SSCG and access token via Dashboard. • Run Dynamic Analysis, submit DSCG report. • Validate token, hash, and SSCG serialNumber. • Extraxt DSSG serialNumber • Forward DSCG to TrustOR to store it • Once successfully stored, update component version with DSCG serialNumber and notify the user. The DSCG Generation flow within the RESCALE platform involves a multi-stage process where the State Manager validates, processes, and integrates Dynamic Analysis results to ensure platform consistency and data integrity. As displayed in Figure 14, the process begins RESCALE – Public – Page 40 / 80 D5.1: Trust Orchestrator (first version) Figure 14: Consumer runs the Dynamic Testing and submits DSCG when the user logs into the platform via the Dashboard. The user’s credentials are validated by the authentication service (Keycloak), and upon successful verification, the user is granted access to the platform. The user can then either browse the Dashboard to manually select a component by filtering its name and version or use the API to request the public part of the SSCG associated with the component from the State Manager. Once the SSCG is obtained, the user requests an access token from the Dashboard, which is used for subsequent operations. After retrieving the access token, the user downloads the Dynamic Analysis container from RESCALE – Public – Page 41 / 80 D5.1: Trust Orchestrator (first version) ment, and deployment. By leveraging Docker, RESCALE partners have been able to ensure consistency across different environments, from local development machines to virtual machines (VMs) hosting critical CI/CD services. By taking advantage of its “multi-platform” capabilities, Docker can provide a standardized runtime environment, allowing developers to work with the same application stacks regardless of their operating system or hardware configuration. It runs seamlessly on developer laptops, ensuring that components and services behave identically across different teams. At the same time, it powers the CI/CD infrastructure, where our continuous integration and testing workflows are executed on VM-based environments. Furthermore, the Static Code Analysis Module and the Dynamic Testing Module which are the testing tools provided by RESCALE, leverage a Docker-based deployment/testing environment to ensure modularity and reproducibility. By standardizing on Docker, RESCALE has created a highly flexible and efficient ecosystem, enabling partners to collaborate seamlessly while ensuring that all services remain portable, scalable, and easy to maintain. 4.1.3 Harbor Harbor [7] is an open-source, cloud-native container registry that provides a secure and scalable way to store, manage, and distribute container images. It extends the functionality of the default Docker Registry by offering advanced features such as vulnerability scanning, role-based access control (RBAC), and content signing. These features help organizations enforce security policies, ensuring that only trusted and verified images are used in production environments. Harbor also supports multi-tenancy, allowing teams to manage multiple projects with isolated access controls. One of the key advantages of Harbor is its ability to replicate container images across multiple registries, facilitating multi-region deployments and disaster recovery strategies. It integrates seamlessly with identity providers like LDAP and OIDC, enabling centralized authentication and access management. By using Harbor, organizations can enhance container security, maintain compliance with industry standards, and improve the overall reliability of their software supply chain. Use within RESCALE: Harbor serves as our centralized private container registry where partners continuously push and manage their container images. It has been instrumental in streamlining development workflows, allowing each partner to work independently by utilizing separate projects, while also facilitating collaboration through shared repositories (see Figure: 17). By organizing container images into project-based workspaces, partners could maintain isolated environments when needed while still benefiting from shared resources for joint efforts. Harbor also helped the consortium solve the challenge of having multiple developers working on different CPU architectures. For example, developers using MacBooks with arm64-based machines could build and push “multi-platform” container images that were later pulled and executed by other developers who worked on amd64-based systems and vice versa. This capability ensured that all RESCALE components could be tested and deployed across different hardware architectures without compatibility issues. A small example of a “multi-platform” RESCALE – Public – Page 48 / 80 D5.1: Trust Orchestrator (first version) Figure 17: Harbor - Projects view image is shown at Figure 18. Additionally, Harbor’s integration with Keycloak allowed user management based on rolebased access control (RBAC). By grouping users into “teams” and later assigning teams to “projects”, it provided both isolation when needed and shared access when collaboration was required. This approach significantly improved the security and organization of RESCALE’s development process, ensuring that partners could work efficiently without interfering with each other’s environments while still having the ability to collaborate on shared deployments. An indicative screenshot is provided by Figure 19. 4.1.4 Keycloak / IAM Keycloak [24] is an open-source Identity and Access Management (IAM) solution designed to provide secure authentication and authorization services. It supports Single Sign-On (SSO), allowing users to log in once and gain access to multiple applications without needing to reenter credentials. Keycloak integrates with various authentication protocols, including OAuth2 [6], OpenID Connect [17], and SAML [16], making it a versatile choice for managing user identities across different platforms. It also provides multi-factor authentication (MFA) [23], social login integration, and federation with external identity providers such as LDAP [8] and Active Directory [12]. By centralizing identity management, Keycloak simplifies user administration and enhances security in distributed environments. Organizations can define fine-grained access control policies, ensuring that users and applications have appropriate permissions. Additionally, Keycloak provides session management, user self-service options, and audit logging, helping organizations maintain compliance and improve security posture. Its integration capabilities make it an essential tool for modern cloud-native applications requiring robust authentication mechaRESCALE – Public – Page 49 / 80 D5.1: Trust Orchestrator (first version) Figure 18: Harbor - Image with multi-platform artifacts nisms. Use within RESCALE: Within the RESCALE project, Keycloak plays a crucial role in identity and access management (IAM), ensuring secure authentication and authorization across different tools and platform components. RESCALE utilizes two separate Keycloak instances, each serving a distinct purpose. The first Keycloak instance (accessible at: https://keycloak.rescale-project.eu) is dedicated to managing access to the CI/CD tools, including Jenkins, Harbor, and Portainer. All users requesting access to the CI/CD infrastructure are registered in this Keycloak instance and assigned to specific groups based on their roles. The group functionality is leveraged for authorization, ensuring that users have the appropriate level of access to each service. The integration of Jenkins, Harbor, and Portainer with Keycloak via OpenID Connect (OIDC) enables single sign-on (SSO), centralized user management, and streamlined role-based access control (RBAC). In Figure 20 the Keycloak Groups created can be seen and by taking a closer look, they are identical to the ones displayed to the Harbor relative screenshot (see Figure: 19. The second Keycloak instance (accessible at: https://iam.rescale-project.eu) is used for RESCALE platform users, ensuring secure access to core platform components. Key RESCALE services, such as the Dashboard and State Manager, authenticate and authorize users through this instance. By implementing Keycloak in this way, RESCALE ensures a clear separation of concerns between infrastructure access (CI/CD tools) and platform-level authentication (RESCALE services). This setup provides secure, flexible, and scalable identity management, enabling both independent workflows and controlled collaboration within the project. While Keycloak supports advanced identity management features, such as Active Directory integration, multi-factor authentication (MFA), and fine-grained access control mechanisms, RESCALE – Public – Page 50 / 80 D5.1: Trust Orchestrator (first version) Figure 19: Harbor - User Groups view these capabilities are not currently planned for implementation in the RESCALE Platform. The current authentication strategy focuses on streamlined user access to RESCALE services without the complexity of external directory synchronization or additional authentication layers. Future iterations of the platform may revisit these enhancements based on project needs and security requirements. 4.1.5 Jenkins Jenkins [3] is an open-source automation server that enables CI/CD by automating various stages of the software development life-cycle. It allows developers to build, test, and deploy applications more efficiently, reducing manual errors and accelerating development cycles. With Jenkins, teams can define automated workflows using pipeline scripts, ensuring a consistent and repeatable deployment process. The platform supports a vast ecosystem of plugins, making it highly customizable and adaptable to different development environments. Jenkins integrates seamlessly with popular tools such as Git, Docker, Kubernetes, and cloud platforms, allowing organizations to streamline DevOps practices. It supports distributed builds, enabling parallel execution of tasks to speed up the development process. Additionally, Jenkins provides real-time monitoring, logging, and notification capabilities, helping teams identify and resolve issues quickly. By automating CI/CD workflows, Jenkins enhances software quality, improves deployment efficiency, and supports agile development methodologies. RESCALE – Public – Page 51 / 80 D5.1: Trust Orchestrator (first version) Figure 20: Keycloak - User Groups view Use within RESCALE: Within the RESCALE project, Jenkins has been integrated as the central CI/CD automation tool, providing a structured and scalable approach to continuous integration and continuous deployment (CI/CD). While the technology is fully set up and operational, widespread adoption by all partners is still in progress. The Trust Orchestrator (TrustOR) component has already established the first working Jenkins pipeline, setting the paradigm for future CI/CD workflows within RESCALE. The TrustOR pipeline is automatically triggered by a GitLab push to the master branch, executing the following steps: 1. Unit Testing – Running automated tests to ensure code correctness. 2. Docker Image Build – Creating a multi-platform container image. 3. Image Push to Harbor – Storing the containerized component in the Harbor registry for easy access and deployment. 4. Deployment to a Development Server (optionally) – If all previous steps succeed, the latest version can automatically be deployed to a development environment. Figure: 21 shows a series of successful builds that took place for the Trust Orchestrator component. This initial setup demonstrates the benefits of Jenkins within RESCALE, showcasing how automation can improve development efficiency, ensure consistency, and streamline deployments. Over the coming months, the remaining RESCALE components will be on-boarded to Jenkins, with partners expected to adopt similar pipelines for: RESCALE – Public – Page 52 / 80 D5.1: Trust Orchestrator (first version) Figure 21: Jenkins - Example of a TrustOR pipeline • Automated unit and functional testing. • Docker image builds and deployments. • Future integration testing across multiple components. By gradually expanding its usage, Jenkins will become a key enabler of quality assurance and DevOps practices in RESCALE, ensuring that all components follow a structured, automated, and reliable development life-cycle. 4.1.6 Portainer Portainer [18] is an open-source container management platform that provides an intuitive web-based interface for managing Docker environments. It simplifies container deployment, monitoring, and lifecycle management, making it accessible to both beginners and experienced DevOps teams. Portainer allows users to oversee all aspects of their containerized applications, including containers, images, volumes, networks, and access controls. With support for Docker Swarm, Kubernetes, and standalone Docker instances, it provides a centralized platform for container orchestration. One of Portainer’s key advantages is its lightweight architecture, as it runs as a single container that can be easily deployed in any Docker environment. It enhances operational efficiency by offering role-based access control (RBAC), real-time container insights, and resource management capabilities. Portainer also integrates with CI/CD pipelines and third-party tools, enabling RESCALE – Public – Page 53 / 80 D5.1: Trust Orchestrator (first version) automated deployments and streamlined container operations. By providing a user-friendly interface, Portainer reduces the complexity of container management, making it an essential tool for teams adopting containerized workflows. Use within RESCALE: Within the RESCALE project, Portainer has been deployed as the primary container management tool, offering a centralized interface for monitoring and managing containerized services. It is integrated alongside CI/CD services, providing visibility and control over the execution environments used for development, testing, and deployment. The main Portainer instance runs alongside the other CI/CD services and is configured to manage multiple environments. At present, three distinct environments are available within Portainer: 1. CI/CD Environment – This environment represents the VM hosting RESCALE’s actual CI/CD services. As seen in Figure: 22 it displays the containers for Jenkins, Harbor, Keycloak, Portainer, plus some other services supporting the whole setup. Access to this environment is restricted to the admin group, ensuring that only authorized users can view and manage these critical infrastructure services. 2. Testing Environment – This environment corresponds to the VM used by Jenkins for building, testing, and running containers. It provides insight into the containerized execution of unit tests, functional tests, and build pipelines, allowing developers to monitor and troubleshoot their CI/CD workflows. 3. TrustOR Environment – This environment represents the VM where Jenkins deploys and runs a development version of the entire RESCALE Platform. It enables developers to test the whole Trust Orchestrator Framework in an isolated development setting, ensuring that new changes can be validated before further deployment. By centralizing container management, Portainer provides better visibility, streamlined monitoring, and controlled access to different RESCALE environments. Similarly to Harbor, which was described previously in this chapter, integrating with Keycloak and utilizing OpenID Connect flows, multiple RESCALE developers can use their CI/CD accounts to access Portainer and control the life-cycle of their containerized applications via a simple user interface, without the need to be granted direct SSH access to the project’s infrastructure. (more at: 4.3.1 Infrastructure View). As development progresses, it will continue to play a key role deployment management, ensuring that partners can effectively oversee and maintain their containerized services. 4.1.7 RESTful APIs Representational State Transfer (REST) [5] is an architectural style used for building scalable and interoperable web services. RESTful APIs follow a client-server model, where clients send HTTP requests [4] to interact with resources exposed by the server. These APIs use standard HTTP methods such as: RESCALE – Public – Page 54 / 80 D5.1: Trust Orchestrator (first version) Figure 22: Portainer - list of containers running the CI/CD services •GET - Retrieve data from the server •POST - Submit new data to be processed •PUT/PATCH - Update existing resources •DELETE - Remove a resource RESTful APIs rely on a stateless communication model, meaning each request is independent and contains all necessary information to be processed. This approach enhances scalability and flexibility, making RESTful services well-suited for distributed systems like RESCALE. Additionally, RESTful APIs commonly use JSON as the data exchange format, ensuring lightweight and human-readable communication between services. Authentication and authorization mechanisms, such as OAuth 2.0 or API tokens, are typically enforced to protect sensitive data and prevent unauthorized access. Use within RESCALE: In RESCALE, RESTful APIs serve as the primary communication mechanism between components. They provide a simple and widely adopted approach for exchanging data, making integration between services straightforward and maintainable. For now, RESTful APIs act as the “glue” of the system, facilitating interactions between key components such as the State Manager, TrustOR, and security assessment tools. This approach allows for rapid development and flexibility, ensuring that security validation workflows function smoothly. However, as RESCALE evolves, we remain open to exploring more advanced communication mechanisms if needed. Future iterations may incorporate event-driven architectures or message queuing systems to enhance scalability and performance. RESCALE – Public – Page 55 / 80 D5.1: Trust Orchestrator (first version) Figure 23: Portainer - The 3 environments currently provided through 3 independent VMs 4.1.8 KrakenD KrakenD [10] is a high performance API gateway that provides organizations with the ability to efficiently manage, secure, and consolidate their backend services. By acting as a single entry point between clients and multiple underlying APIs, KrakenD streamlines request routing, protocol translation, and response aggregation while minimizing latency and complexity. Its flexible, configuration-driven approach eliminates the need for custom coding, making it simpler and faster to define endpoints, apply authentication and authorization rules, implement caching, and perform load balancing. Use within RESCALE: In the RESCALE project, KrakenD will serve as the principal exposed service, functioning as the interface between the frontend and the backend components. All client requests originating from the frontend will be directed to KrakenD, which will handle the authentication and authorization processes through the use of a Keycloak service, thereby ensuring secure access. Upon successful authentication, KrakenD will then forward the requests to the State Manager component. The State Manager will be responsible for performing all routing and coordinating the necessary backend services to fulfill the client’s requests. By using KrakenD for this purpose, the system ensures a streamlined, secure, and efficient communication flow, while the State Manager handles the underlying logic and service orchestration. Additionally, KrakenD is capable of integrating bot detection mechanisms, providing protection against malicious or unwanted traffic, and enhancing the overall security of the system. Furthermore, the support for rate limiting, caching, and circuit breaking serves to reinforce the reliability and resilience of the system by mitigating the effects of overload scenarios and reducing latency. RESCALE – Public – Page 56 / 80 D5.1: Trust Orchestrator (first version) 4.2 Testing Testing plays a critical role in the CI/CD pipeline, ensuring that each change introduced into the system is functional, stable, and does not break existing workflows. By integrating automated testing into the development process, teams can detect errors early, reduce manual effort, and maintain a high-quality codebase. In RESCALE, testing practices are being progressively introduced across all components to improve the reliability and maintainability of the platform. The goal is to establish a structured approach, where each component follows a consistent testing strategy before being deployed. 4.2.1 TrustOR Pipeline Example Figure 24: Failing Jenkins pipeline followed by a successful one To illustrate the importance of automated testing, we present an example from the TrustOR component, which has adopted unit testing within its CI/CD pipeline. The following sequence demonstrates how testing helps prevent faulty code from being deployed: 1. A developer pushes a faulty change to the TrustOR repository. 2. The Jenkins pipeline runs automatically, triggering unit tests for TrustOR. 3. The pipeline fails, highlighting issues in the code that need to be fixed (notice the “red” boxes in Figure 24). The faulty container image was never built and pushed to our registry. 4. The developer corrects the issue and pushes the fix. RESCALE – Public – Page 57 / 80 D5.1: Trust Orchestrator (first version) 5 Conclusions & Future Steps This chapter summarizes the challenges encountered during the initial implementation of the Trust Orchestrator Framework, presents key lessons learned, and outlines the next steps toward a production-ready RESCALE platform. The experience gained from the design, integration, and early deployment phases will serve as the foundation for further refinement and enhancement of the system. 5.1 Challenges & Lessons Learned Throughout the development of the Trust Orchestrator Framework, we encountered several technical and organizational challenges that shaped our approach. The following key challenges and lessons learned highlight the critical areas that required iterative improvements and collaborative problem-solving. Defining an End-to-End Flow for Implementation One of the initial challenges was translating the Logical View of RESCALE’s architecture and the sequence diagrams from D2.5 – High-Level Architecture (first version) into a concrete, end-to-end implementation flow. While the conceptual models provided an excellent starting point, we realized that a specific level of technical detail was required before development could begin. The solution was to organize a series of online workshops where we meticulously broke down each step of the process. These sessions not only helped refine the specifications but also facilitated detailed discussions on the internal workflows of some components, ensuring that all development teams had a clear and actionable road-map for implementation. Handling Multi-Platform Docker Image Compatibility A common misconception in containerized environments is that Docker solves all compatibility issues, but in reality, containers must be built for the specific CPU architecture of the deployment environment. This became a challenge in RESCALE, as partners were developing on different system architectures (x86, ARM, etc.), leading to issues where incompatible images were being deployed, causing failures during execution. For example, during early integration tests, a Dashboard container built on an ARM-based development machine (Apple MacBook with M4 chip [9]) was deployed to an x86-based test environment, resulting in a runtime failure where the container would not start, displaying an Exec format error. This issue delayed testing and required debugging efforts to trace back the root cause, as some partners were unaware that Docker images are architecture-dependent by default. This challenge was quickly identified and addressed through the implementation of multiplatform builds and proper container registry management using Harbor. By ensuring that all Docker images were built with architecture-specific tags, we prevented compatibility issues and ensured that any deployment could seamlessly pull the correct version of each service. Navigating the Dynamic Nature of CycloneDX format RESCALE – Public – Page 64 / 80 D5.1: Trust Orchestrator (first version) CycloneDX, the SBOM, SSCG, DSCG, BOV and TBOM specification used in RESCALE, is highly dynamic and evolving, providing a wide range of capabilities for supply chain security management. However, since the project team was both developing the system and simultaneously learning best practices for using CycloneDX, it required effort to define consistent conventions that would allow tools to exchange these files effectively. We focused on progressive learning and iterative adjustments, refining how we structured CycloneDX data models and ensuring that components could interoperate smoothly within the RESCALE platform. This remains an ongoing effort as we gain further experience and standardize best practices. 5.2 Conclusions The first version of the Trust Orchestrator Framework marks a significant milestone in the RESCALE project. The integration of key components, the deployment of a development platform, and the establishment of a CI/CD workflow have laid a solid foundation for further advancements. Key takeaways from this phase include: • Successful integration of multiple partner-developed components into a unified system. • Implementation of CI/CD pipelines, enabling streamlined deployments and automated testing. • Refinement of deployment strategies, ensuring multi-platform compatibility and secure access control. • Deepened understanding of how CycloneDX can be effectively leveraged in the project. These achievements demonstrate that the RESCALE platform is progressing towards a fully operational state, but also highlight areas that require further refinement and optimization. 5.3 Future Steps The next phase of the project will focus on scaling up development efforts, enhancing automation, and moving towards a production-ready deployment. This work aligns with the project’s final integration milestone (Number 12, with due date: month 32), which marks the completion of the RESCALE Trust Orchestrator framework, including all primitives and services. As part of this milestone, Deliverable D5.2 – Trust Orchestrator (final version) will be produced, presenting the fully integrated version of the framework. This final iteration will incorporate refinements based on insights gained during the initial implementation, testing, and validation phases, ensuring the framework meets the functional, security, and scalability requirements for real-world deployment. The following key areas will be prioritized in this phase: RESCALE – Public – Page 65 / 80 D5.1: Trust Orchestrator (first version) Expanding CI/CD Adoption & Best Practices • Onboard more partners into the CI/CD system, ensuring all teams use automated workflows for building and testing their components. • Encourage best practices in CI/CD pipelines, including automated unit and functional testing for all RESCALE services. Advancing automated End-to-End Testing & Integration • Implement pipelines for automated end-to-end testing, allowing us to validate the entire platform’s functionality with minimal manual intervention. • Ensure seamless integration testing between interconnected services, identifying and resolving issues early in the development cycle. Optimizing Deployment & Moving Toward a Production-Ready Platform • Refine the deployment process, improving scalability, security, and reliability. • Transition towards a fully automated deployment system, ensuring that a productionready RESCALE platform can be deployed with minimal effort. • Improve monitoring and observability tools, providing deeper insights into system health, security, and performance. Towards the Final Version: Cross-Work-Package Collaboration This deliverable represents the first integrated version of the Trust Orchestrator Framework. As we work towards the final version in the upcoming months, a cross-work-package collaboration will be essential. The focus will be on strengthening security and making further progress in trust establishment, closely following the specifications emerging from WP4. • WP4 is defining the trust models and security requirements, which will serve as the foundation for the next integration phase. • WP3, responsible for testing tools, will need to ensure that their outputs align with these specifications. • WP5, which focuses on integration and orchestration, will adapt to these evolving requirements, ensuring that components are integrated in a more secure and trusted manner. This second iteration of integration will not only enhance the security and trust mechanisms but may also lead to changes in the way components interact within the Trust Orchestrator Framework. As the platform matures, adhering to the refined specifications will ensure that RESCALE delivers a robust, secure, and fully operational solution. RESCALE – Public – Page 66 / 80 D5.1: Trust Orchestrator (first version) References [1] Docker:. Accelerated container application development. https://www.docker.com/, 2025. [2] Docker:. What is a container? https://www.docker.com/resources/ what-container/, 2025. [3] Jenkins Documentation. Jenkins pipeline and ci/cd automation. https://www.jenkins. io/, 2024. [4] Roy Fielding, Jim Gettys, Jeffrey C. Mogul, Henrik Frystyk, Larry Masinter, Paul Leach, and Tim Berners-Lee. Hypertext Transfer Protocol – HTTP/1.1 (RFC 2616). https: //datatracker.ietf.org/doc/html/rfc2616, 1999. Accessed: 2024-02-25. [5] Roy Thomas Fielding. Architectural Styles and the Design of Network-based Software Architectures. PhD thesis, University of California, Irvine, 2000. Available at https: //www.ics.uci.edu/~fielding/pubs/dissertation/top.htm. [6] OAuth Working Group. The OAuth 2.0 Authorization Framework. https:// datatracker.ietf.org/doc/html/rfc6749, 2012. Accessed: 2024-02-21. [7] Harbor:. an open source registry that secures artifacts with policies and role-based access control, ensures images are scanned and free from vulnerabilities, and signs images as trusted. https://goharbor.io/, 2025. [8] The Internet Engineering Task Force (IETF). Lightweight Directory Access Protocol (LDAP): The Protocol (RFC 4511). https://datatracker.ietf.org/doc/html/ rfc4511, 2006. Accessed: 2024-02-21. [9] Apple Inc. Apple m4 chip, 2024. Accessed: 2025-02-26. [10] KrakenD API Gateway. KrakenD: Ultra-High Performance API Gateway. https:// www.krakend.io/, 2024. Accessed: 2024-02-25. [11] Let’s Encrypt. Let’s Encrypt: Free SSL/TLS Certificates. https://letsencrypt.org/, 2024. Accessed: 2024-02-25. [12] Microsoft. Active Directory Domain Services Overview. https://learn.microsoft. com/en-us/windows-server/identity/ad-ds/get-started/virtual-dc/ active-directory-domain-services-overview, 2025. Accessed: 2025-02-25. [13] Mongo Express. Mongo Express: Web-Based MongoDB Admin Interface. https:// github.com/mongo-express/mongo-express, 2024. Accessed: 2024-02-25. [14] MongoDB, Inc. MongoDB: The Developer Data Platform. https://www.mongodb. com/, 2024. Accessed: 2024-02-25. [15] NGINX, Inc. NGINX: High-Performance Load Balancer, Web Server, and Reverse Proxy. https://www.nginx.com/, 2024. Accessed: 2024-02-25. RESCALE – Public – Page 67 / 80 D5.1: Trust Orchestrator (first version) [16] OASIS Security Services Technical Committee. SAML V2.0 Technical Overview. https://docs.oasis-open.org/security/saml/Post2.0/ sstc-saml-tech-overview-2.0.html, 2020. Accessed: 2024-02-21. [17] OpenID Foundation. OpenID Connect Core 1.0. https://openid.net/specs/ openid-connect-core-1_0.html, 2014. Accessed: 2024-02-21. [18] Portainer.io. Portainer: The Universal Container Management Tool. https://www. portainer.io/, 2024. Accessed: 2024-02-25. [19] CycloneDX Project. Cyclonedx: The international standard for bill of materials (ecma424). https://cyclonedx.org, 2024. [20] CycloneDX Project. CycloneDX v1.6 JSON Specification. https://cyclonedx.org/ docs/1.6/json/, 2024. [21] SequenceDiagram.org. SequenceDiagram.org: Online UML Sequence Diagram Tool. https://www.sequencediagram.org/, 2024. Accessed: 2024-02-25. [22] SmartBear Software. Swagger: Openapi specification, 2025. Accessed: Feb. 28, 2025. [23] Wikipedia contributors. Multi-Factor Authentication. https://en.wikipedia.org/ wiki/Multi-factor_authentication, 2024. Accessed: 2024-02-21. [24] © Keycloak Authors 2024. © 2024 The Linux Foundation. Keycloak: Open Source Identity and Access Management. https://www.keycloak.org/, 2024. RESCALE – Public – Page 68 / 80 D5.1: Trust Orchestrator (first version) 6 Appendix 6.1 RESCALE Development Platform - Docker compose file services: mongodb: image: mongodb / mongodb -community - server :7.0.12 - ubi8 container_name: mongodb environment: MONGO_INITDB_ROOT_USERNAME: root MONGO_INITDB_ROOT_PASSWORD: pass ports : - "127.0.0.1:27017:27017" restart : always networks: - rescale -net labels: io . portainer . accesscontrol . teams : rescale - all mongo - express : image : mongo - express container_name : mongo - express environment: ME_CONFIG_MONGODB_SERVER: mongodb ME_CONFIG_MONGODB_URL : mongodb :// mongodb :27017 ME_CONFIG_BASICAUTH_USERNAME: root ME_CONFIG_BASICAUTH_PASSWORD: pass ME_CONFIG_MONGODB_ADMINUSERNAME: root ME_CONFIG_MONGODB_ADMINPASSWORD: pass ports : - "127.0.0.1:8081:8081" restart : always depends_on : - mongodb networks: - rescale -net labels: io . portainer . accesscontrol . teams : rescale - all trustor: image : harbor . rescale - project . eu /rescale - all / trustor : latest container_name: trustor environment: MONGO_HOST : mongodb STATE_MANAGER_URL : http :// state - manager :3000 ports : - "127.0.0.1:8000:8000" restart : always depends_on : - mongodb networks: - rescale -net labels: io . portainer . accesscontrol . teams : rescale - all RESCALE – Public – Page 69 / 80 D5.1: Trust Orchestrator (first version) state - manager : image : harbor . rescale - project . eu/ rescale - all / state_manager : latest container_name : state - manager pull_policy : always restart : always environment: NODE_ENV : development TRUSTOR_API_SSCG_URL : http :// trustor :8000/ api/sscg TRUSTOR_API : http :// trustor :8000/ api/ sbom_sscg TRUSTOR_API_SBOM_URL : http :// trustor :8000/ api/sbom TRUSTOR_API_DSCG_URL : http :// trustor :8000/ api/dscg MONGO_URL : ’mongodb :// root :******** @mongodb :27017/ admin ’ MONGO_USERNAME: root MONGO_PASSWORD: ******** KEYCLOAK_URL : https :// iam .rescale - project . eu KEYCLOAK_REALM: avt KEYCLOAK_CLIENT_ID : state_manager KEYCLOAK_CLIENT_SECRET: ************************* ports : - ’127.0.0.1:3000:3000’ networks: - rescale -net depends_on : - mongodb labels: io . portainer . accesscontrol . teams : rescale - all avt : image : ’harbor . rescale - project .eu / rescale - all / dashboard : latest ’ container_name: dashboard restart : always ports : - ’127.0.0.1:4200:80’ networks: - rescale -net depends_on : - state - manager labels: io . portainer . accesscontrol . teams : rescale - all krakend: image : ’harbor . rescale - project .eu / rescale - all / krakend : latest ’ container_name: krakend ports : - ’127.0.0.1:3005:8080’ networks: - rescale -net labels: io . portainer . accesscontrol . teams : rescale - all networks: rescale - net : name : rescale - net Listing 11: Docker Compose configuration for RESCALE development deployment. RESCALE – Public – Page 70 / 80 D5.1: Trust Orchestrator (first version) 6.2 TBOM creation: end-to-end flow This appendix provides a complete representation of the TBOM creation flow, covering all interactions between the involved components. This flow is a direct reference to the processes described in Section 3.3 Supported Flows, where each step has been detailed in terms of its functional and technical role within the Trust Orchestrator Framework. Below, we provide both: 1. A textual representation of the sequence diagram. 2. The generated sequence diagram itself for better visualization. If the reader wishes to recreate or modify the diagram, the textual description can be copied and pasted into sequencediagram.org [21]. The tool will automatically generate the visual representation, making it easier to analyze and refine the flow. Guidelines for Using sequencediagram.org To generate the diagram: 1. Copy the provided text below. 2. Go to sequencediagram.org. 3. Paste the text into the editor. 4. Download or export the diagram (optional) This approach ensures that the TBOM creation process remains traceable, editable, and reproducible, allowing easy updates and refinements as needed. RESCALE – Public – Page 71 / 80 title TBOM creation flow database "Code Repositories" as code actor "producer" as user actor "consumer" as user2 participant "Dashboard" as dash participant "Auth" as auth participant "Harbor" as harbor participant "SSCG Generator" as sscg participant "DSCG Generator" as dscg participant "State Manager" as SM participant "TrustOR" as trustor database "Repositories" as repos participant "Security Assurance" as seca participant "Block-chain" as bc # login part user->dash:login dash->auth:check credentials dash<-auth: OK user<-dash: success # register component / receive UUID user->dash:register SW or HW component dash->SM:setComponent( Name, Programming Language\netc...) SM->auth:Validate Auth Token auth->SM: Success note over SM:Extract userID from Auth Token\nCalculate Component Hash ( Name + userID)\nAdd userID to Component\nAdd Hash to Component SM->dash: Success note over dash: Name\nProgramming Language\netc... user<-dash:success user->dash:get access token dash->SM: get access token SM->auth:Validate Auth Token auth->SM: Success note over SM:Generate Access Token \n(Hash + Auth Token) SM->dash:return access token user<-dash:return access token # ----------------- Static Analysis ----------------- # download Static Analysis container ==Static Analysis==#fff7b9 user->harbor: request the Static Analysis container user<-harbor: download the Docker image file note over user:Execute Docker container\nwith the configuration\nparameters needed:\n access token\n dry-run false\n SBOM:\n - name\n - version code->user:pull component\n(vesrion ) note over user: run the Static Analysis # run Static Analysis / submit result user->sscg: Static Analysis results are all gathered note over sscg:Result:\n SBOM:\n - name\n - version\n SSCG:\n - SBOM serialNumber\n - SBOM hash sscg->SM: send result