D5.3: Pilot Deployment, Test and Demonstration (first version)

D5.3: Pilot Deployment, Test and Demonstration (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 Demonstrator/Report Workpackage WP5 Deliverable Lead CC Editors Dani Asztalos (CC), Sascha Kattelmann (PST) Contributors Marton Sipos (CC) Dissemination Level Public Abstract This deliverable presents the initial deployment, testing, and demonstration of the RESCALE platform with pilot partners PST and CC. It details the integration process, challenges, and testing results in real-world environments. The findings will guide improvements and future iterations to ensure practical applicability and effectiveness in real-world use cases. 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.3: Pilot Deployment, Test and Demonstration (first version) Internal Reviewers 1. Danijela Boberic Krsticev, UNSPMF 2. Ioannis Morianos, DIE Revisions Version Date Partner Overview 0.1 10/01/2025 CC ToC 0.2 18/02/2025 CC, PST First Draft 0.3 21/02/2025 UNSPMF, DIE First internal review 0.4 26/02/2025 CC, PST Review comments addressed, KPI table, architecture added 0.5 06/03/2025 UNSPMF, DIE Second internal review 0.6 12/03/2025 ISI, AEGIS Final internal review 1.0 17/03/2025 CC, PST Final version, video demonstrations added RESCALE – Public – Page 2 / 41 Table of Contents 1 Introduction 7 1.1 Scope&Contribution............................... 7 1.2 Methodology and Contribution to Project Objectives . . . . . . . . . . . . . . . 7 1.3 Relation to Work Packages, Deliverables, and Activities . . . . . . . . . . . . . 8 1.4 IntendedAudience ................................ 9 1.5 DocumentStructure................................ 9 2 Architecture Overview 10 3 Deployment of the RESCALE platform for GRiSP.io 13 3.1 Description .................................... 13 3.2 Integrationsteps.................................. 13 3.3 Challenges and Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.4 User requirements covered . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.5 Componentscovered ............................... 20 3.6 Nextsteps..................................... 20 4 Deployment of the RESCALE platform for SkyFlok 23 4.1 Description .................................... 23 4.2 Static and dynamic testing of rlnclib . . . . . . . . . . . . . . . . . . . . . . . 23 4.2.1 Description ................................ 23 4.2.2 Integrationsteps.............................. 23 4.2.3 Challenges and Solutions . . . . . . . . . . . . . . . . . . . . . . . . . 26 4.2.4 Nextsteps................................. 26 4.3 Static and dynamic testing of a SkyFlok microservice . . . . . . . . . . . . . . 26 4.3.1 Description ................................ 26 4.3.2 Integrationsteps.............................. 26 4.3.3 Challenges and Solutions . . . . . . . . . . . . . . . . . . . . . . . . . 28 4.3.4 Nextsteps................................. 29 4.4 Componentscovered ............................... 29 4.5 User requirements covered . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 5 Testing and demonstration 31 5.1 Commontestingresults.............................. 31 5.2 Testing results for pilot partner PST . . . . . . . . . . . . . . . . . . . . . . . 33 5.3 Testing results for pilot partner CC . . . . . . . . . . . . . . . . . . . . . . . . 34 5.4 Key Performance Indicators . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 6 Roadmap to Final Version 38 6.1 Next Steps for Dynamic Testing Integration . . . . . . . . . . . . . . . . . . . 38 6.2 Expanding Testing Scope for More Components . . . . . . . . . . . . . . . . . 38 6.3 Enhancements in BOM Tooling . . . . . . . . . . . . . . . . . . . . . . . . . . 38 6.4 On-Premises Deployments . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 7 Conclusion 40 3 List of Figures 1 RESCALE High-Level Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 10 2 GitHubCIConceptualView ............................. 14 3 GitHubCIUIPipelineView ............................. 17 4 GitHubCIUIJobView................................ 18 5 GRiSP.io Component in the RESCALE Dashboard . . . . . . . . . . . . . . . . . 20 6 Conceptual Dynamic Analysis CI Integration . . . . . . . . . . . . . . . . . . . . 21 7 Running the static analyzer in Bitbucket Pipelines . . . . . . . . . . . . . . . . . . 25 8 Running the RESCALE Static Analysis Module in Bitbucket Pipelines . . . . . . . 28 9 Loggingintothedashboard.............................. 32 10 Registering a new component in the dashboard . . . . . . . . . . . . . . . . . . . . 32 11 Listing components in the dashboard . . . . . . . . . . . . . . . . . . . . . . . . . 33 12 Detailed View on the Job Execution for the Static Code Analysis Module . . . . . 34 13 Successfully running the Static Analyzer Module in Bitbucket Pipelines with uploadingtheSSCG.................................... 35 4 D5.3: Pilot Deployment, Test and Demonstration (first version) List of Abbreviations API Application Programming Interface. 21, 26, 29 BOM Bill of Materials. 23, 38 CD Continuous Development. 7, 23, 30, 40 CI Continuous Integration. 7, 10, 13–17, 20–23, 25, 30, 33, 40 CLI Command Line Interface. 23 DL Deep Learning. 11 DSCG Dynamic Supply Chain component Guarantee. 7, 13, 14, 20, 29, 31, 38 IoT Internet of Things. 13 JSON JavaScript Object Notation. 22 KPI Key Performance Indicator. 36 LLM Large Language Model. 17 ML Machine Learning. 11 REST Representational State Transfer. 21, 22, 26, 29 SaaS Software as a Service. 13 SBOM Software Bill of Materials. 7, 16, 17, 20, 23, 25–27, 38 SSCG Static Supply Chain component Guarantee. 4, 7, 14–16, 20, 24, 29, 33–35, 38 TBOM Trusted Bill of Materials. 13, 20, 29, 38 UI User Interface. 21 URL Uniform Resource Locator. 15, 21, 22, 33 YAML YAML Ain’t Markup Language. 14 RESCALE – Public – Page 5 / 41 D5.3: Pilot Deployment, Test and Demonstration (first version) Executive Summary This deliverable presents the initial results of the deployment and testing for the two pilot use cases. It summarizes the outcomes of the similarly titled Task 5.2. Both pilots have been deployed using the RESCALE platform and the first phase of validation has occurred. The deliverable aims to present two core directions in the implementations of the two pilot use cases. Firstly, it details how the deployment and integration of the pilot use cases and the RESCALE platform were conducted. The technical details of the integration steps are presented, including the connections that are made to platform components as part of the use cases’ workflows. An initial and brief evaluation of the coverage of user requirements is also conducted, based on the plans defined in Work Package 2. Secondly, the initial validation of the platform is performed through the two pilot use cases. Testing procedures have been established and a first round of outcomes is detailed. The emphasis is on covering as much of the platform as possible. Thus, the pilot use cases have selected a small, but highly representative part of their applications and frameworks as the Device Under Test. Finally, the deliverable includes a plan for the remainder of Task 5.2 and establishes a road map to the final version. Finally, efforts to create a deeper integration between the pilots and the platform, increasing the number of components utilized are described. The results of this second phase will be reported in M34. RESCALE – Public – Page 6 / 41 D5.3: Pilot Deployment, Test and Demonstration (first version) 1 Introduction 1.1 Scope & Contribution This deliverable presents the first outcomes of Task 5.2 - Pilots Use Cases Deployment, Testing, and Demonstration, roughly half a year after the task started (September 2024). It presents the initial results of the deployment and testing for the two pilot use cases, first described in Deliverable 2.1. The main contribution of the deliverable can be divided into two related parts. The first part describes the technical details related to the deployment of the two pilot use cases. This includes a short introduction, followed by a list of the integration points with the RESCALE platform and the concrete steps taken so far within Task 5.2. Completed user interfaces are presented alongside details of CI/CD pipeline steps and examples for text-based inputs and outputs for the various steps of the use case workflow. On the project management side, the deliverable includes the challenges that have so far been identified and presents a brief, initial look at which user requirements have so far been met. The list of components each pilot use case covers so far can be used as a high-level assessment of the integration work’s progress. A list of the next steps toward finishing the deployment of the use case applications is included. The second part relates to the initial validation of the platform that is conducted through the pilot use cases. The deliverable includes a common testing procedure for both pilots that is composed of a list of steps that aim to cover as much of the services of the RESCALE platform as possible at this stage in their implementation. The initial outcomes are presented through a selection of screenshots that illustrate the user-facing elements of the platform, while the data model is illustrated through example SBOMs and SSCGs. The dynamic testing results reported in the DSCG are planned to be included in the next iteration of this deliverable (D5.4). Finally, the deliverable includes a plan for the remainder of Task 5.3 and establishes a road map to the final version. It describes how the testing will be extended to cover more platform components and evaluate a more complex supply chain. 1.2 Methodology and Contribution to Project Objectives The project adopts a two-phase approach regarding Task 5.2. In the first phase, as presented in this deliverable, the pilot use cases have deployed, within their own infrastructure and development CI/CD pipelines, a well-defined, representative segment of their applications using the RESCALE platform. By limiting the scope in this manner, more emphasis and scrutiny could be placed on the important integration details. At the same time, this approach allowed for a very wide coverage of platform components. The project chose this somewhat unusual approach to achieve two goals which are crucial at this stage in the project’s lifecycle. The first goal was to provide feedback to component developers through a technological deepdive. This was then used as a first, mostly informal, validation method for the outcomes of Work Package 2, in particular the high level architecture specifications and the user-facing interfaces. This goal is directly related to Objective 5.2: Deploy integrated solutions into the actual use case environments as specified in Task 2.1 and implement the pilot applications. RESCALE – Public – Page 7 / 41 D5.3: Pilot Deployment, Test and Demonstration (first version) The extensive range of covered components not only ensured that feedback was accessible to all partners, but it also assessed the integration level of the entire platform. Considering the significant number of components in relation to the relatively few that the use case applications interact with directly, tests could only be successful if these components were well integrated with one another as part of the Task 5.1 efforts. When viewed from a broader, project-level perspective, this approach is well-founded. The second goal, established by the consortium at an early stage of the project, was for the two pilot use cases to take central roles in ensuring that relevant user requirements are defined and thus that the project’s outcomes are good candidates for future exploitation. Furthermore, the use case applications themselves provide the test cases needed to validate the correct functioning of RESCALE. This is inline with Objective 5.3: Test and demonstrate the real-world applications that use RESCALE solutions and Objective 5.4: Validate implemented solutions against requirements and evaluate results against ambitions and targets. Both goals serve the project-level Objective 4: Demonstrate and validate the effectiveness and accuracy of the proposed solutions in two complementary use cases with the active engagement of several stakeholders accomplishing at the end of the project a TRL4 for the entire platform. In the second phase, the use case applications will be extended, covering a wider part of PST’s and CC’s software and hardware offering. As the development of more individual components is finalized and their integration into the RESCALE platform completed, more complex testing procedures will be established. The plan for this phase is outlined in this deliverable, with results reported in the upcoming second and final version of this deliverable (D5.4). 1.3 Relation to Work Packages, Deliverables, and Activities The first phase of Task 5.2 - Pilots Use Cases Deployment, Testing, and Demonstration, as reported in this deliverable, was closely linked to the outcomes of Work Package 2. Efforts followed the plan described in Task 2.1: Pilots Use Cases Specifications which defined key user scenarios and validation objectives. Furthermore, testing sought to establish the correctness of the platform’s overall architecture, as specified in Task 2.3: High Level Architecture Specification which defined the high-level architectural interactions essential for ensuring correct integration. Both pilot use cases strive to utilize as many of the platform components as possible, particularly those from the Assessment and Management domains with a focus on the Static Code Analysis Module. This included the outcomes of WP3: Static and Dynamic Analysis Testing, which included components directly used to assess the security aspects of the applications, as well as the outcomes of WP4: Trusted Supply Chain Establishment, which included the components that manage the platform-wide workflows. The integration work was performed as part of T5.1: Trust Orchestrator and Integration of RESCALE Solutions. The following phase of Task 5.2 will be done in close cooperation with Task 5.3: Continuous Validation and Evaluation to ensure that testing procedures are sufficient in their completeness to validate the achievement of the previously established requirements. This will be achieved through joint integration meetings, regular feedback loops, and combined testing activities. These efforts will be reported in Deliverable 5.4 in M34. RESCALE – Public – Page 8 / 41 D5.3: Pilot Deployment, Test and Demonstration (first version) 1.4 Intended Audience This document is publicly available and should be of use to anyone interested in the detailed description of the deployment and testing of the two pilot use cases of the RESCALE project. 1.5 Document Structure Section 1 serves as an introduction to the document. It provides information about the document’s purpose, including its role in the RESCALE project, the methodology with which its contents were created, its structure and the audience to which it is mainly addressed. Section 2 is dedicated to providing a high-level overview of the RESCALE platform’s architecture, as defined in Task 2.3. Section 3 is dedicated to the first pilot use case: Auto-Placement Security Aware Augmented Data-Flow and Infrastructure. It describes how the use case applications interact and integrate with the platform components. Beyond the technical descriptions, a subsection is dedicated to providing an initial evaluation of progress in terms of meeting user requirements and assessing the coverage of platform components. The list of the following integration and development steps is also outlined. Section 4 is dedicated to RESCALE’s second pilot use case: Privacy-by-Design Distributed Cloud and Edge Storage and matches the structure of the previous section. Section 5 describes the test procedure steps that pilot partners took to evaluate and validate the effectiveness of the RESCALE solution. Section 6 provides a roadmap, from the perspective of the two pilot use cases, on the planned evolution of the RESCALE platform and the role the two use case partners have in this process. Finally, Section 7 summarizes the contents of the deliverable and provides a brief description of its role in the life-cycle of the project. RESCALE – Public – Page 9 / 41 D5.3: Pilot Deployment, Test and Demonstration (first version) setup for the RESCALE project. Since this is a private registry there is a need for authentication which is given through the username and password sections. The Docker container is started with a bash shell, which allows the execution of shell commands using the run section. The command /usr/local/bin/scam-engine.sh executes the SCAM engine (see D3.1), which orchestrates the execution of static code analysis tooling inside the container based on content in options. Using the -v option it is possible to map volumes (e.g. folders) from the Ubuntu virtual machine inside the Docker container such that the previously checked-out repository as well as the output folder, is available from within the container. Further, using the -e option it is possible to define environment variables to be honored inside the container (see D3.1). The USER_ACCESS_TOKEN allows for authenticated and authorized communication of the SSCG Generator with the RESCALE platform. The LANG_INFO defines the involved programming language technologies, which could also be a list of multiple different technologies. Further the SRC_PATH and SBOM_PATH point to the source code to be analyzed as well as the respective SBOM which is expected to be pre-generated and present in the repository. Finally the DRY_RUN variable allows to execute the module without publishing data (e.g. for test runs) to the RESCALE platform, if set to true. To augment the DRY_RUN functionality, there is a last step in the CI script: - name: Archive SSCG uses : actions / upload - artifact@v4 if: ${{ always () }} with: name: SSCG path : ./ out /sscg .json if -no - files - found : error compression - level : 9 In any case, the SSCG will be stored locally as a CI artifact for introspection and an error will be generated, leading the pipeline to fail if the SSCG can’t be found. This allows developers to inspect the final result of the pipeline, and also this adds a plausibility check if everything worked fine. Files used or generated by the PST GitHub CI system can be inspected at the RESCALE SharePoint [13]. GitHub CI UI View It is possible to control and introspect the CI jobs in GitHub CI using a web interface. Figure 3 showcases an overview of several executed pipeline runs for the static code analysis module which happened throughout the integration activities. On the top right, there is a button to manually trigger the execution of such a pipeline based on a branch. As mentioned earlier, the CI configuration is part of the versioned source code, and therefore, the CI activities are always specific to Git branches. This is the reason why next to the Git commit message on the left, there is also the branch name in the center. It is also possible to further introspect each job of an executed pipeline as illustrated by Figure 4. Each step of a job can be expanded to see step specific logs. This, in particular, allows to RESCALE – Public – Page 16 / 41 D5.3: Pilot Deployment, Test and Demonstration (first version) Figure 3: GitHub CI UI Pipeline View introspect logs from the actual run of the static code analysis module, which are showcased in Section 5.2. It can also be seen that a run of the actual static code analysis container takes a bit more than 3 minutes. 3.3 Challenges and Solutions There have not been any major problems or challenges in integrating the static code analysis module. However, the module has been developed to a large part by PST with its own CI requirements in mind, and hence, it is not surprising that it could be integrated into PSTs own CI system with ease. It must be noted though that a rather powerful CI host is recommended to handle the workloads of local LLM models (which are utilized e.g. by SAVE-ME). However, there was a significant challenge in generating the actual SBOM for GRiSP.io (see RESCALE SharePoint [13]) as the current state of tooling in Erlang certainly does not meet modern requirements. Although there exists a plugin called rebar3_sbom [12] for the Erlang build tool rebar3 [10], the resulting SBOM is outdated and impractical, as it outputs CycloneDX [2] 1.1. To address this, PST submitted a pull request on GitHub [11] to improve the tool. However, the maintainer expressed a preference for a broader redesign and refactoring of the rebar3_sbom plugin. This sparked further discussions about CycloneDX support in Erlang: Depending on how the RESCALE project as a whole evolves in the future, PST might invest into the development of a standalone CycloneDX support library for Erlang, which could then be integrated by the rebar3_sbom plugin as well. For now, PST is using their own fork of rebar3_sbom, incorporating the improvements proposed in their pull request. RESCALE – Public – Page 17 / 41 D5.3: Pilot Deployment, Test and Demonstration (first version) Figure 4: GitHub CI UI Job View 3.4 User requirements covered Table 3 illustrates which user requirements of RESCALE based on D2.3 are covered from the view of PST. Note that there are several user requirements which are not directly related to the first step of integration as outlined in this document. Table 3: List of Initial User Requirements for RESCALE URID Title Comment UR010 Static Code Analysis of Erlang SAVE-ME is integrated into the static code analysis module and usable, though the tool is in an early stage and requires a lot more development work UR011 Static Code Analysis of GRiSP.io IoT Platform The module is integrated and able to push SSCGs into the RESCALE platform RESCALE – Public – Page 18 / 41 D5.3: Pilot Deployment, Test and Demonstration (first version) Table 3 – continued from previous page URID Title Comment UR012 Dynamic Security Testing of GRiSP.io IoT Platform The module is ready to be integrated in the very near future, including API fuzzing tools like RAISE and Evomaster which can be used in combination with OpenAPI UR013 Continuous Security Testing for GRiSP.io IoT Platform Partially covered by means of the static code analysis module UR014 Dry/Standalone Testing for GRiSP.io IoT Platform Integrated for the static code analysis module UR015 Dry/Standalone Testing for GRiSP.io IoT Platform Users Not implemented yet UR016 Constructive Feedback on Security Findings for GRiSP.io IoT Platform Not implemented yet, requires more research and implementation within the SSCG/DSCG Generators as well as the other RESCALE components UR017 Constructive Feedback on Security Findings for GRiSP.io Users See UR016 UR018 Quick to Understand Summaries of Security Findings for Executive Entities See UR016 UR019 Dynamic Mutation Fuzzing Integration into GRiSP.io Not implemented yet, possibly covered in future phases of the project (this is a ’could’ requirement) UR020 TBOM for GRiSP.io IoT Platform Not integrated yet, though a concrete plan forward is laid out for that in Section 3.6 UR021 TBOM Integration into GRiSP.io IoT Platform See UR020 UR022 User Specified Trust Zones in GRiSP.io This is a feature specific to PST which is currently under development. The feature partially relies on data sensitivity information from the RESCALE platform, which might be subject to future project efforts. (This is a ’should’ requirement) UR023 Cryptographic Primitive Assignment in GRiSP.io See UR022 UR024 Sensitive Data Classification in GRiSP.io IoT Platform See UR022 UR025 Explore Erlang VM Separation for GRiSP.io IoT Platform Not implemented yet, possibly covered in future phases of the project (this is a ’could’ requirement) UR026 Low-Level System Security Testing of GRiSP.io IoT Platform Not implemented yet, possibly covered in future phases of the project (this is a ’should’ requirement) RESCALE – Public – Page 19 / 41 D5.3: Pilot Deployment, Test and Demonstration (first version) Figure 5: GRiSP.io Component in the RESCALE Dashboard 3.5 Components covered The current state of the integration includes the static code analysis module and in particular, the tool SAVE-ME (see D3.1) which is a static code analysis tool for the Erlang programming language. With respect to the architecture overview (Figure 1), it is currently possible for PST to use the services of the “Management Domain” with a limited set of features. It is possible to create a new component, which yields a RESCALE_ACCESS_TOKEN that can be used by PST’s CI system to push SBOM, SSCG and DSCG information. These informations are reflected in the RESCALE Dashboard as showcased by Figure 5. So far only the static code analysis module is integrated, and hence just an SSCG can be pushed. Note that GRiSP.io is just a product name, the PST internal technical name for the GRiSP.io project is “Seawater” which is the reason why that name is used in the RESCALE Dashboard. The “Security and Trust Domain” (see Figure 1) is, as of now, only partially integrated. The document repositories for SSCG, DSCG, and TBOM are functional, even though just the SSCG repository is used right now. More details can be found in D5.1. 3.6 Next steps The integration of the dynamic testing module will be the next prioritized step. However, the dynamic testing module is far more complex and uses an ensemble of Docker containers. The general approach here is to execute all tool specific containers and cache the output (e.g. the test reports) in the CI system such that in a final step, a container with the DSCG Generator can use these test reports together with further options to generate and publish the DSCG. Figure 6 captures this idea. Two stages are used where the first stage runs a tool container as a single job, possibly in parallel as the single tool containers are independent from each other. Then, the outputs from each tool are aggregated in a cache which is provided by GitHub CI. RESCALE – Public – Page 20 / 41 D5.3: Pilot Deployment, Test and Demonstration (first version) Figure 6: Conceptual Dynamic Analysis CI Integration It is usually not necessary to define the cache itself in the CI configuration; it is rather set up automatically by defining dependencies between jobs in a way that requires a forwarding of artefacts from one job to another. For dynamic testing, the tools RAISE and Evomaster (see D3.3) are of particular interest as they are API fuzzing tools working on OpenAPI [9] specifications, which are already integrated for GRiSP.io. Hence an integration with these tools in the PST CI system should be relatively straightforward. The integration with FATex needs more research, as the overall setup involves very hardware specific configuration. As PST might also provide access to the RESCALE platform and the analysis tooling through a web UI there is a need to execute standalone workloads triggered through that web UI. This can also be realized using GitHub CI with pipelines (or workflows) that are triggered by means of a REST interface. A customer would provide a URL to its (usually also GitHub hosted) software project which is supposed to be tested. name: API-Triggered Job on: repository_dispatch: types: [trigger-ci] jobs: api-job: RESCALE – Public – Page 21 / 41 D5.3: Pilot Deployment, Test and Demonstration (first version) runs-on: ubuntu-latest steps: - run: echo "Triggered by API!" - run: echo "URL: ${{ github.event.client_payload.url }}" In the above example, such a GitHub CI workflow is defined. For demonstration purposes, there is just one job api-job that is triggered through a REST interface. The job simply returns a URL that was provided by the customer. The complete CI workflow can be extended in a very similar way as presented with GRiSP.io and the static code analysis module. The only difference here is that the software project to be tested is fetched from a configurable source. The whole workflow can then be triggered using e.g. the following sceleton of a cURL call: curl -X POST -H "Accept: application/vnd.github.everest-preview+json" \ -H "Authorization: token YOUR_GITHUB_TOKEN" \ https://api.github.com/repos/OWNER/REPO/dispatches \ -d ’{ "event_type": "trigger-ci", "client_payload": { "url": "https://github.com/some/project" } }’ Note that the customer provided URL is placed in the client_payload JSON object and the specific CI workflow is identified using the event_type key. This actual integration will certainly vary in the details from this approach. RESCALE – Public – Page 22 / 41 D5.3: Pilot Deployment, Test and Demonstration (first version) 4 Deployment of the RESCALE platform for SkyFlok 4.1 Description SkyFlok is Chocolate Cloud’s main product aimed at individuals and small to medium businesses. It is a secure file storage platform which enables users to store their data easily and reliably across multiple cloud storage providers (see D2.1 for more details). Static and dynamic testing of the SkyFlok components play a key role in making sure the solution is secure and free of vulnerabilities. Chocolate Cloud stores the source code of its software components in Bitbucket [1] and uses Bitbucket Pipelines for CI/CD tasks, therefore running the RESCALE testing modules will be demonstrated using this tool. The following two subsections describe the integrations steps the pilot took through two separate software components to maximize the coverage of the RESCALE tools. 4.2 Static and dynamic testing of rlnclib 4.2.1 Description Rlnclib is Chocolate Cloud’s Random Linear Network Coding library written in C++ used to encode and decode file fragments when uploading or downloading files to its SkyFlok platform. It uses cmake as a build system. It plays an important role in the pilot’s software architecture, because many other components build upon this library’s features, so it is crucial to test it thoroughly. 4.2.2 Integration steps To generate an SBOM for rlnclib pilot partner CC uses cdxgen, which is the official CyclonDX CLI tool to generate BOM files [3]. This tool can be run in a docker container and it produces an sbom.json file by analyzing the CMakeLists.txt of the project (see RESCALE SharePoint [13]). Running the Static Code Analysis Module locally with DRY RUN Below is a batch script that runs the static analyzer module locally with DRY RUN enabled. docker run -e DRY_RUN = true ^ -e SBOM_PATH ="/ app /sbom. json " -v .\ bom . json :/ app / sbom . json ^ -e SRC_PATH ="/ app /src /" -v .\ rlnclib :/ app/src -v /app /src /build -v / app /src / extern ^ -e LANG_INFO =" Cpp " ^ -v .\ out :/ app/out ^ harbor . rescale - project . eu/wp3 / static_analysis_module RESCALE – Public – Page 23 / 41 D5.3: Pilot Deployment, Test and Demonstration (first version) This docker run command uses volumes to mount the sbom.json, and the source code to be used by the static analyzer module. Paths and other configuration parameters are passed as environment variables. For the output it also utilizes a volume. Successfully executing the command produces the following output. Validating sbom. json ... BOM validated successfully . [C++] Processing C++ source at /app/src/ with output at / app /out /test - reports / [ SASTer ] Running scan ... [ SASTer ] Scan completed [C++] C ++ source scans completed [ SSCG Generator ] Generating SSCG ... - SBOM Path: /app/sbom. json - Test Report Folder : / app / out /test - reports / - SSCG Path: /app/out / sscg .json JSON successfully stored to /app / out/ sscg . json Validating sscg. json ... BOM validated successfully . Dry run mode enabled . SSCG is not published . SSCG generation / publishing process completed In the logs we can see the static analysis module ran SASTer (see Table 1), then generated an SSCG. After that, it validated the sscg and finally, because it is a dry run, the uploading of the SSCG is skipped. The output is saved to the out folder as sscg.json, so the developers can analyze the results. Running the Static Code Analysis Module in CI with DRY RUN Below you can find the excerpt from the bitbucket-pipelines.yml for running RESCALE static analysis module in Bitbucket Pipelines. - step : & rescale - static - analysis name: Rescale Static Analysis test services: - docker script: - docker run -v $BITBUCKET_CLONE_DIR:/app:rw -t ghcr .io/ cyclonedx / cdxgen -r / app -o / app /sbom . json -t cpp - docker login harbor . rescale - project . eu -- username $RESCALE_HARBOR_USERNAME --password $RESCALE_HARBOR_PASSWORD - > docker run -e DRY_RUN = true -e SBOM_PATH ="/ app/sbom. json " -v $BITBUCKET_CLONE_DIR / sbom. json :/ app / sbom . json -e SRC_PATH ="/ app /src /" -v $BITBUCKET_CLONE_DIR:/app/src -v $BITBUCKET_CLONE_DIR/out:/app/out -e LANG_INFO =" Cpp " harbor . rescale - project . eu /wp3 / static_analysis_module artifacts : # Store build artifacts for use in the following steps - out / sscg. json - out /test - reports /* RESCALE – Public – Page 24 / 41 D5.3: Pilot Deployment, Test and Demonstration (first version) First, the script runs cdxgen to generate an SBOM, then logs in to harbor to be able to pull images, and finally runs the static analysis docker container, by mounting volumes and passing options using environment variables. As a post step, the sscg.json and the test reports are uploaded as artifacts. Storing these artifacts enables the developers to download and analyze the results and fix the findings before releasing the software. Figure 7: Running the static analyzer in Bitbucket Pipelines Running the Static Code Analysis Module in CI without DRY RUN The step to run the static analyzer without DRY RUN differs only in the configuration parameters of the docker run command. - step : & rescale - static - analysis name: Rescale Static Analysis test services: - docker script: - docker run -v $BITBUCKET_CLONE_DIR:/app:rw -t ghcr .io/ cyclonedx / cdxgen -r / app -o / app /sbom . json -t cpp - docker login harbor . rescale - project . eu -- username $RESCALE_HARBOR_USERNAME --password $RESCALE_HARBOR_PASSWORD - > docker run -e SBOM_PATH ="/ app/sbom. json " -v $BITBUCKET_CLONE_DIR / sbom. json :/ app / sbom . json -e SRC_PATH ="/ app /src /" -v $BITBUCKET_CLONE_DIR:/app/src -v $BITBUCKET_CLONE_DIR/out:/app/out -e USER_ACCESS_TOKEN=$RESCALE_ACCESS_TOKEN -e LANG_INFO =" Cpp " harbor . rescale - project . eu /wp3 / static_analysis_module artifacts : # Store build artifacts for use in the following steps - out / sscg. json - out /test - reports /* First the DRY RUN parameter is omitted, and an access token is passed. This access token is generated through the RESCALE Dashboard. RESCALE – Public – Page 25 / 41 D5.3: Pilot Deployment, Test and Demonstration (first version) as well, along with smaller visual, usability changes. This constant feedback loop will be maintained during the next phase of the project. Figure 9: Logging into the dashboard Figure 10: Registering a new component in the dashboard RESCALE – Public – Page 32 / 41 D5.3: Pilot Deployment, Test and Demonstration (first version) Figure 11: Listing components in the dashboard 5.2 Testing results for pilot partner PST As outlined in section 3.2 the static code analysis module was integrated into PST’s GitHub CI System. The execution of an actual CI run can be seen in Figure 12. The output there is truncated to focus on the download of the static code analysis container and the actual execution of the module, specifically the tool SAVE-ME. After the tests are executed, an SSCG is generated and depending on the DRY_RUN variable the SSCG is published to the RESCALE platform. In the last step the SSCG is also kept in a local cache such that developers are able to inspect it. In the last line a URL is provided to download the SSCG. An example SSCG can also be viewed in the RESCALE SharePoint [13], and a video demonstration of the process can be found on the RESCALE YouTube channel [5]. RESCALE – Public – Page 33 / 41 D5.3: Pilot Deployment, Test and Demonstration (first version) Figure 12: Detailed View on the Job Execution for the Static Code Analysis Module 5.3 Testing results for pilot partner CC Sections 4.2.2 and 4.3.2 describe how it was integrated into pilot partner CC’s development pipeline. It is possible to run the static analysis both locally and in Bitbucket Pipelines with DRY RUN or without it and uploading the SSCG to the RESCALE platform as seen in figure 13. A video demonstrating how pilot partner Chocolate Cloud deployed the RESCALE solution into its software pipeline can be found on the RESCALE YouTube channel [4]. RESCALE – Public – Page 34 / 41 D5.3: Pilot Deployment, Test and Demonstration (first version) Figure 13: Successfully running the Static Analyzer Module in Bitbucket Pipelines with uploading the SSCG. Running the Static Analyzer Module found the following issues in the tested code components. No real errors were identified at this phase of the project that would require attention. The outputs of the static analysis runs can be found on the RESCALE SharePoint [13]. • Rlnclib –19 Notes: E.g. buffer/memcpy:Does not check for buffer overflows when copying to destination (CWE-120) –3 Warnings: random/srand:This function is not sufficiently random for security-related functions such as key and nonce creation (CWE-327). These warnings were are all found in test codes, so can be classified as False positives. • Skyflok Email Service (excerpt) –47 Low, E.g. Use of assert detected. The enclosed code will be removed when compiling to optimised byte code. Found in test codes, so can be classified as False positive. –3 Medium: E.g Possible SQL injection vector through string-based query construction. Classified as false positive because it is constructed using constants. RESCALE – Public – Page 35 / 41 D5.3: Pilot Deployment, Test and Demonstration (first version) 5.4 Key Performance Indicators During the work carried out in Task 5.2 a number of KPIs were identified as possibly related to the pilot deployment activities. Details on how these KPIs relate to the pilots and some possible means of verification for some of these are presented in Table 5. Note that this list can change as the project progresses. A more detailed, exhaustive catalog and results will be presented in Task 5.3 and its deliverables. Table 5: List of KPIs related to the Pilot deployment activities KPI id Title Relevance to the piloting activities KPI2.2 Detect more than 90% of known vulnerabilities at hardware and software level for the pilot’s vulnerable hardware and software solutions The hardware and software components of the pilot partners will be tested using both known benchmark applications and RESCALE solutions, then these results will be compared. KPI4.1 At least two (2) use cases examined on the pilot trials The two pilot partners present two different use cases which show the effectiveness of the RESCALE solution and its applicability on a wide range of scenarios. KPI4.2 Achieve an adoption rate of 20% for the RESCALE platform by relevant stakeholders circles In this iteration of testing, pilots were focused on integrating RESCALE solution into their environment. However, in the future, a comprehensive survey will be conducted to evaluate the adoption and usability of the proposed solution. KPI4.3 Detection of more than 95% of total insecure components during piloting activities for known benchmark applications see KPI2.2 KPI4.4 Construction of an informative mechanism for both security and non-security experts Only a small number of developers at the pilot partners are experts in security. That’s why the results of the tests and possible mitigation actions should be easy to understand and act upon. iKPI1 Increased trust and acceptance of the blockchain-assisted management processes of TBOM updates by collaborating parties in supply chains by at least 30%, including at least two hardware and two software components. see KPI4.2 iKPI4 Alignment of the RESCALE approach with the new NIS directive for security assessment and validation of the RESCALE overall security testing framework, integrating both static and dynamic security and privacy properties, in at least two industry-led pilot scenarios. NIS Directive and its updated version NIS2 defines security requirements which needs to be satisfied and RESCALE solution will help pilots to perform security audits and assessments. Those reports may serve as evidence of security implementation and risk mitigation. RESCALE – Public – Page 36 / 41 D5.3: Pilot Deployment, Test and Demonstration (first version) Table 5 – continued from previous page KPI id Title Relevance to the piloting activities iKPI7 Identify at least 95% of insecure mechanisms for accessing and processing sensitive data at the piloting activities for known benchmark applications. see KPI2.2 iKPI8 Increase in self-assessed preparedness levels of TBOM components at the piloting phase by at least 50%. Detailed pilot reports will be produced that document the improvements in supply chain security and preparedness levels as a result of using TBOM components. iKPI15 Achieve more than 95% resilience on cyberattacks and on non-malicious failures during the project piloting activities on known benchmark applications. see KPI2.2 iKPI16 Increase the perception of security through the use of TBOM and Trustor by 20%. see iKPI8 iKPI17 Reduce time to detect known and emerging vulnerabilities in supply chains by 10%. Currently it takes a long time and manual effort to detect new vulnerabilities in the pilot partner’s development activities. With the help of the Security Assurance components this can be greatly improved. iKPI27 At least 80% acceptance of proposed technologies that are piloted in two different environments. see KPI4.2 RESCALE – Public – Page 37 / 41 D5.3: Pilot Deployment, Test and Demonstration (first version) 6 Roadmap to Final Version 6.1 Next Steps for Dynamic Testing Integration As explained in previous sections, it is still necessary to integrate the dynamic testing module for both pilot partners. This will require a more complex automation setup due to the higher complexity of that module compared to the static code analysis module. A first integration is expected to be finished within the next three months after this report is submitted. There were already successful attempts to generate a DSCG and even a TBOM using manually crafted development setups. 6.2 Expanding Testing Scope for More Components For demonstrating how real supply chains can utilize the RESCALE platform, the pilot partners will work with more components and their dependencies such that more data (SSCG, DSCG, TBOM) is generated. For the pilot partners it is of high relevance how real, complex supply chains are handled by the platform. Another major point is the trust assurance of the generated and published data. The pilot partners are expected to integrate security mechanisms that will enable trust in generated documents and the ability to trace down ill-generated (corrupted, manipulated etc.) data. The foundation for these mechanisms is currently subject to project research in WP4. In addition, the integration of more tools (see figures 1 and 2) and their refinement represents a large body of work for the pilot partners. Note that many tools require a very specific configuration and additional specifications on how to test a specific piece of software or hardware. Also, as of now, only a smaller part of the WP3 tools is integrated into their respective module and probably all of them will benefit from direct feedback to the tools developer when used on real world setups. 6.3 Enhancements in BOM Tooling Besides the integration of RESCALE specific tooling, the pilot partners are also striving to enhance BOM related tooling. From the perspective of an industrial end user, it is obvious that major parts of the open source landscape regarding BOM processing are under-developed. Possible enhancements lie particular in the generation of SBOMs where, at least in the case of the Erlang programming language, the technological foundation lacks major features and/or sophistication. 6.4 On-Premises Deployments Another topic of less importance is a possible installation on-premises of the RESCALE platform. As of now, the platform is deployed using specific (cloud) technologies within the inRESCALE – Public – Page 38 / 41 D5.3: Pilot Deployment, Test and Demonstration (first version) frastructure of a partner. For an on-premises setup, it is desirable to enable the pilot partners to install the platform as easily as possible. RESCALE – Public – Page 39 / 41 D5.3: Pilot Deployment, Test and Demonstration (first version) 7 Conclusion The first iteration of the pilot deployment and integration shows how RESCALE established a robust foundation for securing the supply chain through the Static Analysis module. This initial integration played a crucial role in improving the module by uncovering and resolving numerous bugs, ultimately enhancing its effectiveness. The insights gained from this process will significantly contribute to the project’s ongoing development, ensuring continuous refinement and optimization. While the Static Analysis module has been successfully integrated, the main challenge ahead is incorporating the Dynamic Testing module. This next step will be essential in strengthening the overall security framework in the pilots, as it will complement static analysis with real-time assessment capabilities that include runtime vulnerabilities, API fuzzing, memory safety and other areas. The experience gained from the initial deployment as running the modules locally and in CI/CD pipelines will help streamline this integration, making it a key focus for future iterations. As the first version of this deliverable, this document outlines the foundational work achieved so far. The next iteration will focus on the integration of the Dynamic Testing module, which will complete the security validation process as well as incorporating the newly developed features of the RESCALE platform such as the trust mechanisms described in WP4. As development continues, ongoing refinements will further enhance the RESCALE project’s ability to secure the supply chain. RESCALE – Public – Page 40 / 41 D5.3: Pilot Deployment, Test and Demonstration (first version) References [1] Bitbucket. https://bitbucket.org/, 2025. [2] Cyclonedx. https://cyclonedx.org/, 2025. [3] Cyclonedx generator. https://github.com/CycloneDX/cdxgen, 2025. [4] Deployment of rescale in cc. https://youtu.be/CD64xB1i614, 2025. [5] Deployment of rescale in pst. https://youtu.be/VQvGwlWfQSs, 2025. [6] Erlang. https://www.erlang.org, 2025. [7] Grisp. https://www.grisp.org, 2025. [8] Grisp.io. https://www.grisp.io, 2025. [9] Openapi. https://www.openapis.org, 2025. [10] Rebar3 erlang build tool. https://rebar3.org, 2025. [11] Rebar3 sbom plugin pull request for json support and update cyclonedc version. https: //github.com/voltone/rebar3_sbom/pull/20, 2025. [12] Rebar3 sbom plugin with cyclonedx support. https://github.com/voltone/rebar3_ sbom, 2025. [13] Rescale sharepoint files. https://imisathena.sharepoint.com/:f:/r/sites/ RESCALE/Shared%20Documents/RESCALE%20Project%20repository/WP5/ Deliverables/D5.3%20Pilot%20Deployment,%20Test%20and%20Demonstration% 20(first%20version)/files?csf=1&web=1&e=4aizRQ, 2025. RESCALE – Public – Page 41 / 41