Blog Post Archives – rescale-project.eu

Giving Hardware a Verifiable Identity

RESCALE’s Hardware Fingerprinting Case Study

A Hardware Bill of Materials can describe the type, manufacturer, model, and expected configuration of a physical component. It cannot automatically prove that the specific device installed in a system is the same unit that was originally supplied.A component could be replaced or substituted during transport, integration, maintenance, or repair, while the related documentation remains unchanged.

RESCALE’s hardware fingerprinting case study explores how physical characteristics could provide a stronger connection between a device and its digital supply-chain record. The idea is to create evidence that depends on the physical properties of the component itself, rather than only on a printed serial number or externally assigned identifier.

Using Physical Differences Between Devices

Physical Unclonable Functions, or PUFs, use small manufacturing variations that naturally occur between devices. Two chips may share the same design and model number, but microscopic differences can influence memory startup states, signal delays, or oscillator frequencies. These variations can be measured and used to produce a device-specific response.

The case study reviews several approaches. SRAM PUFs use the preferred power-up states of memory cells. Arbiter PUFs compare the delay of signal paths, while Ring Oscillator PUFs compare the frequencies of oscillators affected by manufacturing variation. Each method has practical limitations. Some require direct physical access to the chip, while others are sensitive to temperature, voltage, routing, and nearby activity. Repeated measurements may also differ slightly, which means that error correction or fuzzy extraction may be needed to reproduce a stable result. A hardware fingerprint is therefore not created simply by taking one measurement and calculating a hash. It requires a controlled enrolment process and a reliable method for comparing later readings with the original reference.

Testing the Idea with GRiSP Hardware

The RESCALE case study examined a scenario in which a third-party processor is supplied as an external coprocessor for a GRiSP board. The goal was to explore whether the receiving organisation could verify that the processor was the same physical unit sent by the manufacturer.

The experimental setup included a GRiSP 2.0 board, a Dell Edge Gateway 5000, and two PIC12F1840 microcontrollers. The microcontroller acted as the external processor, while the Dell gateway collected timing measurements through a USB-to-serial connection. The selected method used variability in the PIC12F1840’s internal oscillator. The device repeatedly measured the number of instruction cycles completed within a one-millisecond window and transmitted the resulting timing values. In principle, a sufficiently stable subset of these measurements could form a fingerprint associated with that individual processor. A later measurement could then be compared with the enrolled reference.

What the Experiment Revealed

The case study identified two important practical challenges.

The first was physical access. Many fingerprinting methods require pin-level access to the component. This may be possible during manufacturing or when working with development boards, but it becomes much harder after a chip has been soldered into a finished product. The integrated memory on the GRiSP board was not suitable for the intended experiment, so the scenario was adapted to use an external processor.

The second challenge was measurement noise. The timing readings collected from the PIC12F1840 were not stable enough to create a functioning PUF. The variation between measurements made it impossible to isolate a sufficient number of repeatable values. Addressing this issue would require further work on temperature and voltage control, noise reduction, repeated enrolment measurements, threshold selection, and error-tolerant processing.

The case study is clear about this limitation. It did not produce a validated production-ready hardware fingerprint for the selected setup. Placeholder hashes were used to complete the wider design and demonstrate how the evidence could be represented within RESCALE.

Representing Fingerprints as Supply-Chain Evidence

One of the main outcomes of the work is a proposed way to represent hardware fingerprint information through CycloneDX.

The example structures include the target component, fingerprinting method, measurement configuration, raw sample sets, environmental conditions, statistical results, reliability information, and the processing steps used to derive the stable fingerprint. The relationships between these elements can also be recorded. For example, a stable fingerprint may depend on several raw sample sets and on the quantisation profile used to process them. The complete fingerprint document can remain off-chain under organisational control. Its canonicalised hash can then be registered through the RESCALE permissioned ledger and linked to the relevant TBOM or hardware-fingerprint record. Keeping fingerprint information separate from the general HBOM may also be useful. Several devices of the same model can share one component description while requiring a different fingerprint for each physical unit.

A Realistic Step Toward Stronger Hardware Assurance

Hardware fingerprinting could eventually help manufacturers, integrators, and operators verify that a component has not been substituted. It may be particularly useful for removable modules, accelerators, specialised processors, and other high-value components.

The RESCALE case study does not claim to have solved every practical challenge. Instead, it documents what is required, where the selected experiment encountered limitations, and how fingerprint evidence could fit into the wider trust architecture. This provides a realistic foundation for future work on linking physical device identity with machine-readable and verifiable supply-chain records.

Blog Post

Following a Vulnerability Through the Supply Chain

Inside RESCALE’s Graph Application

Finding a vulnerability is only the first step in understanding supply-chain risk. Once a vulnerable package has been identified, organisations still need to determine which products contain it, which components depend on those products, and how far the impact may spread. This becomes difficult when software is assembled through several layers of direct and indirect dependencies. A single library may be included in many products, while those products may themselves become dependencies of larger systems. Searching manually through a large collection of Bills of Materials can take valuable time and may still fail to reveal the complete picture.

RESCALE’s Supply Chain Vulnerability Graph Application was developed to make these relationships easier to explore. It connects component, dependency, vulnerability, and TBOM information in a graph, allowing users to move from one vulnerable package to the wider set of supply-chain elements that may be affected.

Looking at Dependencies in the Opposite Direction

A conventional SBOM tells us which packages are included in a product. For example, it may show that Product A depends on Library B. This information is essential, but during a vulnerability investigation the security team usually needs to ask the question in reverse: which products depend on Library B?

The Graph Application begins with the Package URL, or PURL, of the component under investigation. It identifies the BOMs that directly depend on that component and then continues through additional levels to find products that depend on those BOMs.

The results are organised as a layered reverse-dependency view. The starting component appears at the first level, followed by its direct dependants and then by components further downstream. Each result can include information such as the component PURL, BOM reference, dependencies, associated vulnerabilities, and related TBOM serial number. This makes it easier to estimate the potential blast radius of a newly disclosed vulnerability. Instead of receiving a list of disconnected matches, the analyst can see how the affected component sits within a larger chain of products and dependencies.

Connecting Evidence That Would Otherwise Remain Separate

The Graph Application combines information from several types of RESCALE artefacts. These can include Software and Hardware Bills of Materials, Trusted Bills of Materials, Bills of Vulnerabilities, and the guarantees produced through static and dynamic testing. The information is converted into a connected graph model. Components, vulnerabilities, serial numbers, and external references become graph entities, while relationships describe dependencies, ownership, vulnerability links, and membership in a wider trusted record.

This approach preserves the context around each piece of evidence. A vulnerability is connected to the component it affects, the component is linked to the BOM that identifies it, and the assessment evidence remains associated with the relevant TBOM and version. The application is implemented as a Python service backed by a Neo4j graph database. This allows it to answer questions that are difficult to address through isolated JSON documents, especially when the analysis must follow several levels of dependency relationships.

Viewing the Evidence Around a TBOM

The application also introduces the concept of a TBOM component island. A component island groups the documents and graph elements associated with one trusted supply-chain context.

The TBOM serial number acts as the starting point. From there, the application can retrieve the associated SBOM, vulnerability information, component relationships, external references, and available static or dynamic assessment evidence. This consolidated view is useful for analysts and auditors who need to understand why a particular security status was assigned. Instead of opening several documents separately and trying to match their identifiers manually, the user can inspect their relationships through one connected model.

The graph also makes incomplete evidence visible. An SBOM may reference a dependency for which no separate BOM has yet been uploaded. In this case, the application can preserve a placeholder node rather than hiding the relationship. When the missing document becomes available, the placeholder can be updated with the complete information. Lifecycle changes can be represented in the same way. Deprecated components can be excluded from an operational view or included when the user needs to examine historical dependencies and earlier product versions.

Supporting Faster and More Focused Decisions

The Graph Application turns supply-chain documentation into a resource for practical investigation. Security teams can identify the products that may be affected by a newly disclosed vulnerability. Product owners can see which trusted records require review, while auditors can trace the connection between a component, its assessment evidence, and its vulnerability state. The graph also improves communication between organisations. Instead of reporting only that a package contains a vulnerability, a partner can show which products depend on it, how those dependencies were identified, and which TBOMs may be affected.

Modern software supply chains are networks, not simple lists. By connecting RESCALE artefacts and supporting reverse-dependency analysis, the Supply Chain Vulnerability Graph Application provides a clearer way to understand how risk can move through those networks.

Blog Post

Beyond the Initial Assessment

How RESCALE Enables Continuous Security Assurance

A security assessment tells us what was known about a component at a specific moment. Static analysis can identify weaknesses in source code, dynamic testing can expose problems during execution, and hardware assessment can reveal risks that ordinary software testing may miss. Yet none of these checks can guarantee that the component will remain secure throughout its operational life. New vulnerabilities are disclosed continuously, and a dependency considered safe when a product was released may later become a source of risk. This is why RESCALE treats security assurance as an ongoing process rather than a one-time result. Its Continuous Security Assurance Platform keeps previously assessed components connected to updated vulnerability information. When a new issue is disclosed, the platform can check whether it affects a component or dependency already recorded in RESCALE and determine whether the associated security information needs to be updated.

Why One-Time Security Checks Are Not Enough

Modern digital products depend on a wide range of libraries, services, firmware packages, cloud resources, and hardware elements. Even when the product itself does not change, the information available about these dependencies may change significantly. A newly published CVE can alter the risk profile of a component that passed all relevant checks only a few months earlier. Repeating the entire assessment process whenever a new vulnerability appears would be costly and inefficient. RESCALE instead reuses the evidence that has already been collected. The platform compares registered component and dependency information with updated vulnerability data, helping organisations identify when an existing component may require further investigation.

This approach does not replace static or dynamic testing. Those assessments remain the foundation of the security evidence. Continuous assurance adds the ability to revisit that evidence when the wider threat landscape changes.

Connecting Components with Updated Vulnerability Information

The RESCALE Security Assurance component brings together several functions that support this continuous process. A local vulnerability database provides the platform with access to information used during assessment, while an update mechanism keeps it aligned with newly available records. The Security Engine then correlates those records with the assets and dependencies already represented in RESCALE. The platform also maintains the connection between a component, its Software Bill of Materials, and the related trusted records. When a new vulnerability is linked to a registered asset, the system can generate a structured notification containing details such as the vulnerability identifier, severity, description, affected component, and associated project.

This notification is passed into the wider RESCALE workflow so that the relevant vulnerability and trust information can be reviewed or updated. Users do not need to search manually through every SBOM or monitor multiple vulnerability sources independently. Instead, the platform helps connect newly disclosed risks with the components that may be affected. Continuous monitoring can also include events and logs from the RESCALE environment itself. Event Captors provide operational information that can help identify suspicious behaviour or conditions requiring further investigation. The purpose is not to replace a full incident-response process, but to ensure that important security changes are detected and communicated to the appropriate technical teams.

Improving Communication Between Platform Services

As the platform evolved, RESCALE also improved the way its services exchange security information. The first implementation relied on direct communication between the Security Assurance component and TrustOR. This created a strong dependency between the two services. A change, performance issue, or temporary failure in one component could immediately affect the other. The direct connection also needed stronger security protections. Communications containing vulnerability and component information must be protected against interception, manipulation, and unauthorised access.

The final version introduces RabbitMQ as a message broker between the services. Instead of depending on a single direct connection, notifications are placed in queues and processed asynchronously. If one service is temporarily unavailable, the message can remain in the queue until the receiving component is ready. This model makes the platform more resilient and easier to extend. Additional sources of vulnerability information or new notification consumers can be connected without redesigning the complete communication flow. Authentication and permissions can also be applied centrally at the broker, with further options available for TLS-protected connections and certificate-based authentication.

Security That Continues After Release

The Continuous Security Assurance Platform reflects a simple but important reality: a component that is secure today may not remain secure tomorrow. Assurance evidence must remain connected to the changing vulnerability landscape if it is to support reliable decisions over time.

By combining existing assessment results with updated vulnerability information, continuous monitoring, structured notifications, and more resilient service communication, RESCALE helps organisations keep their supply-chain security records relevant. Initial testing establishes the evidence, while continuous assurance ensures that the evidence does not become an outdated snapshot.

Blog Post

Building Trust into Distributed Cloud Storage

RESCALE in the SkyFlok Pilot

Privacy-focused cloud storage depends on more than encryption. It also depends on the software libraries, gateways, microservices, APIs, web applications, and external infrastructure used to process and move the data. A service may protect customer files while still relying on a complex software supply chain. A vulnerability in one supporting component could affect the security or reliability of the complete platform.

The second RESCALE pilot applies the project’s assessment and trust mechanisms to SkyFlok, a distributed cloud and edge storage platform developed by Chocolate Cloud.

Protecting Data Across Several Storage Locations

SkyFlok encrypts files and applies erasure coding before distributing the resulting fragments across selected storage providers and locations. A file can later be reconstructed when enough fragments are retrieved and combined. Depending on the service configuration, the encryption and coding operations may take place in the user’s browser or through gateways deployed at the edge, within customer-controlled infrastructure, or in public-cloud environments. The backend coordinates the process, while individual storage providers handle encrypted and erasure-coded fragments rather than the original file. This reduces dependence on a single provider and supports a privacy-by-design approach. At the same time, the architecture includes many software components. SkyFlok uses Python-based backend services, JavaScript and TypeScript web applications, C++ libraries, APIs, gateways, and external storage interfaces. These components have different dependencies and development processes, making the pilot a useful test for RESCALE’s cross-technology approach.

Integrating Static Analysis into Bitbucket Pipelines

The initial deployment connected the RESCALE Static Code Analysis Module to Chocolate Cloud’s Bitbucket pipelines.

During a pipeline run, the required container is retrieved from the RESCALE Harbor registry and executed against the selected source code. The resulting findings are processed by the SSCG Generator and can either be submitted to the RESCALE platform or retained as a pipeline artefact. The pilot tested the workflow against the RLNC library and a SkyFlok microservice. The analysis generated several warnings that were reviewed by the development team. Some findings appeared in test code, while another warning related to a query built from constant values. In the tested context, these results were classified as false positives. This is still an important part of the assessment process. Security tools are designed to identify patterns that may indicate a vulnerability, but developers must examine those findings within the actual code and deployment context. A useful workflow must therefore provide enough detail to support that review.

Combining Static and Runtime Evidence

The wider pilot scenario extends the static-analysis workflow toward dynamic testing of selected SkyFlok microservices.

A target service can be launched in a controlled environment and tested through API-focused tools using its OpenAPI description. The runtime results can then be used to generate the DSCG and connected to the existing static assessment. TrustOR can combine the validated SBOM, SSCG, DSCG, and vulnerability information into the TBOM. This provides a more complete view of the component by linking what can be found before execution with what happens while the service is running. The distinction is particularly important for cloud microservices. Some weaknesses become visible only when an API receives unexpected inputs, processes unusual sequences of requests, or interacts with other services.

After the TBOM is created, Continuous Security Assurance can monitor the recorded dependencies for newly disclosed vulnerabilities. If a relevant issue appears, the associated vulnerability information can be updated and the responsible organisation notified.

Extending Privacy by Design to the Software Supply Chain

The SkyFlok pilot demonstrates that privacy cannot be separated from component security. Protecting the data is essential, but users also need confidence in the software responsible for encryption, coding, transfer, authentication, and coordination. By integrating RESCALE into Bitbucket pipelines and connecting the resulting evidence to the wider assurance workflow, the pilot shows how supply-chain security can become part of an existing cloud-development process.

SkyFlok’s architecture reduces dependence on a single storage provider. RESCALE complements that approach by helping organisations assess and maintain trust in the software components that make the distributed storage service possible.

Blog Post

From Security Findings to Trusted Evidence

The Role of RESCALE’s Trust Orchestrator

Security tools can produce large amounts of useful information, but separate reports do not automatically create trust. Findings must be linked to the correct component and version, checked against the expected format, and combined with the other evidence required to describe the component’s security state.

Without this coordination, organisations may end up with several assessment reports that are technically correct but difficult to compare, verify, or maintain. RESCALE addresses this challenge through its Trust Orchestrator Framework and, in particular, the TrustOR component. TrustOR connects the results produced by the assessment tools with the platform’s management and trust mechanisms. Its role is to turn separate SBOMs, static and dynamic guarantees, and vulnerability information into a coherent and traceable TBOM workflow.

Moving Beyond a Collection of Reports

The static and dynamic testing modules focus on assessing components and generating structured results. The Static Supply Chain Component Guarantee, or SSCG, records the outcomes of static assessment, while the Dynamic Supply Chain Component Guarantee, or DSCG, captures evidence collected during execution. These artefacts are useful on their own, but their full value appears when they are connected to the same software component and supply-chain context. TrustOR checks these relationships before the evidence is accepted into the wider process. For example, the SBOM and SSCG are submitted together because one describes the software composition and the other describes the static assessment performed against it. TrustOR validates their CycloneDX structures, checks that the required component and version information is present, and confirms that the SSCG refers to the correct SBOM. The DSCG is submitted after dynamic testing. TrustOR verifies that it refers to an existing static assessment and that its identifiers are unique and consistent. These checks help prevent malformed, duplicated, or unrelated evidence from being combined into the same trusted record.

Coordinating the Complete Workflow

The State Manager acts as the main coordination point between the Dashboard, the assessment modules, and TrustOR. It receives component registrations and assessment results, checks access permissions, and forwards the relevant artefacts to TrustOR. Once the required evidence has been validated, TrustOR begins the TBOM creation process. It retrieves the related SBOM, SSCG, and DSCG, prepares the Bill of Vulnerabilities, and combines the available information into the trusted structure. The original documents remain available in the RESCALE repositories. The TBOM preserves the links between them, allowing users and systems to trace the final trust record back to the assessment evidence on which it was based.

Under the final RESCALE trust design, complete TBOM documents remain off-chain and under organisational control. Compact integrity evidence, including hashes, lifecycle transitions, and immutable events, can be anchored on the permissioned ledger. This makes later verification possible without publishing sensitive document contents on-chain. The State Manager keeps track of the process and allows the Dashboard to show the current status to the user. The user therefore sees the progress of the workflow without needing to interact with each individual assessment, repository, or trust service.

Keeping the Trust Record Up to Date

TrustOR’s role continues after the TBOM has been created. When the Continuous Security Assurance component identifies a newly disclosed vulnerability affecting a registered asset, it generates a structured alert. The alert can include the affected component, CVE identifier, severity, description, timestamp, and project reference. TrustOR uses this information to identify the appropriate TBOM and update the related vulnerability evidence. This creates a continuous connection between the initial assessment and the later security state of the component. The TBOM does not remain a fixed record created at release time. It can evolve as new information becomes available.

The Trust Orchestrator Framework is supported by the wider RESCALE integration environment. GitLab and Jenkins support source management and automated workflows, Docker provides consistent containerised deployments, Harbor distributes images, and Keycloak manages identity and access. REST interfaces allow components developed by different partners to exchange structured information without requiring a shared programming language or implementation model.

Turning Technical Results into Usable Assurance

The value of security assessment depends not only on what the tools detect, but also on what happens to the results afterwards. They must be validated, connected, protected, updated, and made understandable to the people who rely on them. TrustOR provides this coordination within RESCALE. By managing the relationships between component information, assessment results, vulnerability records, and trust mechanisms, it turns a collection of technical outputs into evidence that can support decisions across the supply chain.

Blog Post

Securing Embedded and IoT Development

RESCALE in the GRiSP.io Pilot

Embedded and Internet of Things platforms are built from more than application code. They combine hardware interfaces, operating environments, communication libraries, cloud services, update mechanisms, and third-party dependencies. A weakness in any one of these areas may affect the security of the complete product.

The first RESCALE pilot applies the project’s technology to GRiSP.io, a distributed cloud-to-edge and IoT platform developed by Peer Stritzinger GmbH. The pilot explores how security assessment can become part of the development process and how the resulting evidence can support more trusted deployment decisions.

A Distributed Environment with Different Trust Levels

GRiSP.io supports applications that operate across embedded devices, edge infrastructure, and cloud environments. Functions may be placed on different systems depending on factors such as processing capacity, network bandwidth, latency, and energy use. Security adds another important factor to these decisions. A component should not be deployed on a system based only on performance or availability. Its dependencies, assessment results, communication requirements, and the trustworthiness of the target environment must also be considered. The GRiSP ecosystem provides a realistic setting for this work. It includes Erlang-based software, hardware communication libraries, networking components, remote update functionality, and dependencies from several sources. Each of these elements forms part of the wider supply chain.

Bringing Security Assessment into GitHub CI

The initial pilot deployment integrated the RESCALE Static Code Analysis Module into PST’s GitHub-based CI workflow.

When the pipeline runs, it retrieves the required analysis container and executes the configured tools against the selected source code. The results are then passed to the SSCG Generator, which creates the Static Supply Chain Component Guarantee associated with the assessed software. The workflow supports two modes. The SSCG can be submitted directly to the RESCALE platform, or it can remain available as a pipeline artefact for local inspection. In both cases, the developer receives access to the generated report without having to run the complete analysis process manually. This makes security assessment part of the ordinary build process. Developers can receive structured findings during development rather than waiting for a separate assessment before release. The integration also preserves the connection between the findings, the SBOM, and the exact component version. This is essential because a report without a reliable link to the assessed software has limited value within a complex supply chain.

Supporting Different Roles in the Supply Chain

The pilot reflects the fact that supply-chain roles may change depending on the component being considered.

PST acts as the Producer of GRiSP platform components. It may also become a Consumer when it integrates or assesses a component supplied by another organisation. GRiSP.io customers can become Producers of their own applications built on top of the platform. This creates a multi-level supply chain in which platform software, customer applications, external libraries, and deployed systems all need to be connected through consistent evidence. The final use-case specification extends the workflow beyond static analysis. A Consumer can run dynamic testing against the component and generate a DSCG. TrustOR can then use the SBOM, SSCG, DSCG, and vulnerability information to create the TBOM.

The initial pilot demonstrated the GitHub CI integration and SSCG workflow. Deeper integration with the dynamic testing process and the full end-to-end TBOM lifecycle was identified as the next stage of the work. This distinction is important because the pilot documents both the progress achieved and the practical integration still required.

Lessons for Embedded Development

The GRiSP.io pilot shows that effective security integration depends on more than the quality of the analysis tools. Language support, SBOM generation, container distribution, CI configuration, report handling, and developer access to results all influence whether the technology can be used in practice. This is particularly relevant for the Erlang ecosystem, where some supply-chain and SBOM tools are less mature than their equivalents for more widely supported programming languages. The pilot helps identify where additional adaptation is required and where the RESCALE workflow can simplify the developer experience.

By bringing assessment into CI/CD and connecting the results to structured supply-chain evidence, RESCALE creates a path toward more trusted IoT and edge deployments. Security information becomes available closer to the point where software is developed, integrated, and prepared for deployment.