Blog Post Archives – rescale-project.eu

From Innovation to Standard: How RESCALE Is Building a…

A secure supply chain cannot depend on trust alone. It needs evidence, and that evidence must be understandable, verifiable, and reusable across organisations, industries, and national borders. This is where standardisation becomes essential. RESCALE is developing a holistic cybersecurity assessment framework for software and hardware supply chains, centred on the Trusted Bill of Materials, or TBOM. However, creating effective technical solutions is only part of the challenge. For these solutions to achieve long-term impact, their terminology, processes, outputs, and trust mechanisms must connect with recognised standards, certification frameworks, and European cybersecurity requirements. The RESCALE Contribution to Standardisation White Paper 2025 explains how the project intends to establish this connection and identifies the results that could contribute to future standards in supply chain security, certification, and trust management.

1. Creating a Common Language for Supply Chain Security

Before organisations can exchange security evidence, they must agree on what that evidence means. Software and hardware supply chain cybersecurity currently brings together a wide range of overlapping terms, assurance models, regulatory requirements, and technical processes. Different stakeholders may use different expressions for similar concepts, which can make interoperability, certification, and conformity assessment more difficult. RESCALE addresses this challenge through its Reference Architecture and Glossary, which define the project’s main architectural elements and establish a shared vocabulary for trusted supply chains. These concepts include the Trusted Bill of Materials, the Static Supply Chain Guarantee, the Dynamic Supply Chain Guarantee, and the Bill of Vulnerabilities. By consolidating this terminology, RESCALE provides a common foundation that can be understood by developers, manufacturers, security professionals, auditors, regulators, and end users. The Reference Architecture therefore functions not only as a technical design for the RESCALE platform, but also as a potential blueprint for wider European and international discussions on supply chain assurance.

2. Moving from a Bill of Materials to a Trusted Bill of Materials

A traditional Bill of Materials can identify the components included in a digital product, but an inventory alone does not demonstrate that those components have been securely developed, tested, or continuously monitored. RESCALE extends this concept through the Trusted Bill of Materials. The TBOM combines information about hardware and software components with evidence produced by static and dynamic security testing. It can incorporate the Static Supply Chain Guarantee, the Dynamic Supply Chain Guarantee, known vulnerability information, and proof that relevant testing activities have taken place. In this way, the TBOM becomes more than a list of dependencies. It becomes a structured, traceable, and reproducible assurance artefact that can support security evaluation throughout the lifecycle of a product. The approach is designed to build upon established machine-readable BOM formats such as CycloneDX and SPDX while adding the evidence needed to support security certification and continuous assurance. For manufacturers, integrators, auditors, and users, this creates a clearer view of what a product contains, how its components were assessed, and what security findings must still be addressed.

3. Transforming Security Testing into Reusable Assurance Evidence

Security testing is most valuable when its results can be preserved, interpreted, and reused beyond a single assessment. RESCALE therefore develops a modular toolbox that converts different security evaluation activities into structured supply chain guarantees. The Static Code Analysis Module examines source code without executing it, helping developers detect coding errors, vulnerabilities, and security weaknesses early in the development process. Its results are captured in the Static Supply Chain Guarantee and are designed to reflect assurance principles associated with frameworks such as Common Criteria. The Dynamic Testing Module evaluates applications, binaries, and hardware components during execution. It combines dynamic analysis, runtime monitoring, fuzzing, and hardware side-channel leakage assessment to produce the Dynamic Supply Chain Guarantee. RESCALE also develops RAISE, the REST API Intelligent Security Explorer, which extends automated API testing through machine learning enhanced fuzzing. RAISE generates sequences of API requests to identify security weaknesses in cloud and microservice-based environments. Through the RESCALE Platform and its Advanced Visualisation Toolkit, these results can be integrated into role-based views that support monitoring, decision-making, incident management, and auditing. The key contribution is that assessment findings do not remain isolated inside individual testing tools. They become part of a structured evidence chain that can support future reassessment, certification, vulnerability management, and regulatory compliance.

4. Making Trust Evidence Verifiable Without Exposing Sensitive Information

Security evidence must be protected from manipulation, but publishing complete technical reports could expose sensitive information about products, components, vulnerabilities, or testing environments. RESCALE addresses this balance through its Trust Storage Platform. Instead of placing complete TBOMs and assessment reports directly on a public blockchain, the platform records cryptographic hashes that act as verifiable references to the original evidence. These hashes make unauthorised changes detectable while allowing the underlying reports to remain protected. This approach supports integrity, traceability, transparency, and immutability without requiring the public disclosure of confidential security information. The Trust Storage Platform can also connect with existing standards and mechanisms for identity, digital signatures, secure key storage, and signed supply chain statements. Relevant technologies include X.509 certificates, PKCS#7 or Cryptographic Message Syntax, PKCS#11, CycloneDX, and the registration and verification mechanisms being developed by the IETF Supply Chain Integrity, Transparency, and Trust working group. Together, these elements could support a Trusted Certification Evidence Repository model in which assurance evidence is securely linked, cryptographically verifiable, and usable across different organisations and certification environments.

5. Connecting RESCALE with International Standards and European Regulation

RESCALE does not develop its approach in isolation. The project maps its results to a broad ecosystem of standards, standardisation bodies, certification initiatives, and European regulatory requirements. ISO/IEC 27001 and the wider ISO/IEC 27000 series provide controls related to supplier relationships, supply chain security, configuration management, monitoring, and information security governance. ISO/IEC 20243 addresses trusted technology providers and ICT supply chain risk mitigation, while ISO/IEC 15408 and ISO/IEC 18045 provide internationally recognised methods for security evaluation. NIST SP 800-115 offers guidance for technical security testing, and NIST SP 800-161 provides a structured approach to cybersecurity supply chain risk management. ETSI standards and technical reports are relevant to IoT security, threat and vulnerability assessment, secure updates, and supply chain risk management. CycloneDX and SPDX provide established foundations for machine-readable Bills of Materials, while IETF SCITT focuses on interoperable mechanisms for registering and verifying trustworthy supply chain statements. CEN-CENELEC JTC 13, IEC, ISO committees, and ENISA certification initiatives provide further pathways for aligning RESCALE results with European and international conformity assessment practices.

This alignment also connects RESCALE with the NIS2 Directive and the Cyber Resilience Act. RESCALE’s TBOM, continuous security validation mechanisms, security assessment reports, and cryptographically verifiable evidence can support organisations addressing supply chain risk management requirements under NIS2 Article 21. The same capabilities can help manufacturers and other stakeholders organise evidence related to the secure development, vulnerability management, lifecycle assurance, and transparency requirements associated with Annex I of the Cyber Resilience Act. RESCALE does not replace formal certification or conformity assessment. Instead, it provides practical tools, structured outputs, and traceable evidence that can make these processes more effective and easier to demonstrate.

6. Turning Research Results into a Standardisation Journey

Standardisation is not simply a final step that takes place after technical development has been completed. It is a continuous process that helps ensure that research results can be understood, adopted, integrated, and trusted outside the environment in which they were created. RESCALE is therefore engaging with key communities including ETSI TC CYBER, IETF SCITT, CEN-CENELEC JTC 13, ISO, IEC, and ENISA. As part of this effort, Athena Research Centre presented the RESCALE project to the SCITT working group during IETF 123 in Madrid. The presentation introduced the project’s concepts and opened discussions on how RESCALE could use SCITT mechanisms and contribute practical supply chain security use cases to the working group. These interactions provide an opportunity to test interoperability, refine the project’s approach, and ensure that RESCALE’s results remain compatible with developing international practices.

Building a Shared Foundation for Trusted Supply Chains

The RESCALE White Paper shows that the project is building more than a collection of cybersecurity tools. It is developing a structured approach to supply chain assurance that combines shared terminology, static and dynamic testing, continuous monitoring, structured security evidence, and cryptographic verification. The Reference Architecture creates a common language, the TBOM transforms component inventories into assurance artefacts, the testing modules generate reusable guarantees, and the Trust Storage Platform protects the integrity of the resulting evidence. By connecting these results with established standards and European regulatory frameworks, RESCALE is working to ensure that its innovations can support a wider community of manufacturers, developers, auditors, regulators, and end users.

The next generation of secure software and hardware supply chains will not be built by a single platform or organisation. It will depend on collaboration, interoperability, and a common language of trust. RESCALE’s contribution to standardisation is an important step toward making that shared foundation practical, transparent, and verifiable.

Read the whole whitepaper here.

Blog Post

The Anatomy of an Update: How RESCALE Built a…

When you are building something as critical as a secure-by-design supply chain solution, you cannot just stick to the initial draft. The project is evolving!

That is the philosophy behind RESCALE. Our mission is to revolutionize security in both hardware and software supply chains, anchored by our flagship development: the Trusted Bill of Materials (TBOM). But a great tool is useless without a great plan.

We started with a foundational set of Use Case specifications, but as our two pilots (CC and PST) got to work and new insights emerged, it was clear we needed an important update. This is not just paperwork; it is a living, breathing blueprint for a more secure world.

Here is the five-step, collaborative, and iterative methodology we followed to build the updated Use Case specifications that are robust and battle-tested:

Talking to the People Who Matter (Pilot Engagement)

Before we drew a single line on the updated specs, we went straight to the source: our pilot teams and their technical staff.

This was not a one-and-done survey. We established continuous feedback loops -from online meetings to ad-hoc team chats- to ensure we were not working in a vacuum. We translated their real-world insights into practical challenges, expectations, and technological constraints. If a specification does not accurately reflect their business needs, it is not a solution! This continuous, open dialogue was essential to making sure our plan was grounded.

The Collaborative Summit (Specifications Workshop)

We believe the best ideas happen when people are in the same room. So, we brought all key pilot stakeholders together to our Amsterdam Plenary meeting for a dedicated, in-person workshop.

Think of it as a deep-dive summit. The objective was to reassess and refine the initial Use Cases. Participants analyzed existing specifications, debated their relevance, and collaboratively incorporated refinements. This session fostered a shared understanding, allowing us to identify crucial new specifications while refining existing ones to perfectly address the pilots’ specific operational needs.

Learning from the Test Drive (Platform Evaluation)

Why wait until the end to find out if your plan works? We put the first release of the RESCALE Platform into the pilots’ hands early on.

The observations gathered from this real-world testing were priceless. They helped us identify operational friction points and alignment gaps. Essentially, the test drive helped us iron out the wrinkles in our existing specifications, ensuring the updated version was perfectly aligned with how the platform operates. This step was also key in formulating the updated usage scenarios we will use to validate the final release.

Getting Smart with MoSCoW Prioritization

Once we had a long list of refined ideas and new requirements, we needed to focus on our resources where they mattered most. Enter the MoSCoW Prioritization Technique.

This structured framework allowed our pilot stakeholders to collaboratively categorize every requirement, which helped eliminate ambiguity and ensure we directed our energy toward the highest-impact functionalities:

Must have: The absolute, non-negotiable features essential for pilot success.
Should have: Important features that significantly enhance functionality but are not critical for the initial go-live.
Could have: Desirable features that add value if time and resources permit.
Won’t have: Features out of scope.

The Blueprint is Complete (Finalizing the Specs)

The final step was the consolidation phase. We merged the insights from continuous stakeholder engagement, the structured refinements from the workshop, and the real-world feedback from the platform evaluation.

This iterative, cooperative process resulted in a final, robust set of Updated Use Case Specifications and the Usage Scenarios needed to validate the final release. This refined blueprint ensures that RESCALE is building an adaptable, relevant, and truly secure-by-design solution for trusted software and hardware supply chains.

Blog Post

The Silent Threat: Addressing Side-Channel Vulnerabilities in Software Supply…

Introduction

Supply chains form the backbone of modern industries, and their resilience is a cornerstone of operational security. While much of the discourse around supply chain vulnerabilities focuses on conventional cybersecurity risks, such as software vulnerabilities or malicious actors, side-channel vulnerabilities present an equally critical, yet often underestimated, threat. These vulnerabilities exploit indirect information leaks, such as timing, power consumption, or electromagnetic emissions, to infer sensitive data. The impact of such attacks on software and hardware supply chains can be devastating, leading to compromised components that cascade failures across dependent systems.

In this article, we delve into the nature of side-channel vulnerabilities in supply chains, examine their implications, and discuss emerging methodologies to mitigate these risks.

Understanding Side-Channel Vulnerabilities in Supply Chains

Side-channel attacks exploit unintended information channels that arise from the physical implementation of software or hardware components. Unlike direct attacks that target software flaws or network vulnerabilities, side-channel attacks leverage physical characteristics, such as:

Timing Information: Differences in execution time for specific operations can reveal
cryptographic keys.
Power Consumption Patterns: Variations in power usage during computations can be
correlated with specific data inputs.
Electromagnetic Emissions: Emanations from circuits can be intercepted and
analysed to extract sensitive information.

While side-channel vulnerabilities have traditionally been studied in the context of cryptographic systems, their impact on supply chains is equally profound. Components affected by these vulnerabilities can serve as entry points for attackers, compromising the integrity of the entire supply chain.

Examples of Side-Channel Vulnerabilities in Supply Chains

Hardware Trojans: Introduced in Third-Party Manufacturing, many supply chains rely on external manufacturing facilities for hardware production. Malicious modifications to chip designs can introduce hardware Trojans, which can be exploited through side-channel techniques. For example, minor changes to circuit timing or power requirements can act as covert communication channels, enabling attackers to exfiltrate sensitive data.
Software Libraries and Timing-Based Data Leaks: Third-party libraries integrated into critical software systems can inadvertently introduce timing vulnerabilities. For instance, a dependency library might handle sensitive data using non-constant time operations, allowing attackers to infer encryption keys or passwords.
IoT Devices and Electromagnetic Emanations: The rise of IoT devices has exacerbated supply chain risks. Many IoT devices operate in environments where they can be physically accessed, making them susceptible to electromagnetic analysis. Inadequate shielding or poorly implemented security measures can make these devices prime targets for attackers seeking to compromise broader networks.

Mitigation Strategies for Side-Channel Risks

Enhanced Static and Dynamic Analysis Tools: To detect side-channel vulnerabilities should be integrated into software development lifecycles and supply chain evaluation processes. Static code analysis and dynamic runtime testing can identify operations susceptible to timing or power-base attacks.
Trusted Bill of Materials (TBOM): Adopting TBOM frameworks is critical for tracking the provenance and security posture of every component in the supply chain. Including side-channel resistance as a parameter in the TBOM can help ensure that components meet stringent security standards.
Physical Security Measures for Hardware: Physical countermeasures, such as electromagnetic shielding, power line filtering, and secure enclaves, can mitigate side-channel risks for hardware components. Techniques such as randomised clocking or noise injection can further obscure exploitable patterns.
Runtime Monitoring and Anomaly Detection: Integrating runtime monitoring systems focusing on side-channel-specific anomalies can detect potential exploitation attempts in real-time. Machine learning models trained on side-channel attack patterns can enhance the accuracy of these systems.
Standardisation and Certification: Developing industry-wide standards for side-channel resistance is essential. Certification processes for hardware and software components should incorporate rigorous side- channel vulnerability assessments.

Conclusion

Side-channel vulnerabilities represent a critical yet underexplored dimension of supply chain security. The RESCALE project, emphasising secure-by-design supply chains, is uniquely positioned to address these risks. By integrating advanced analysis tools, fostering transparency through TBOM frameworks, and advocating for robust security standards, we can mitigate the cascading threats posed by side-channel attacks. The call to action is clear: organisations must prioritise side-channel resilience within their
supply chain strategies to safeguard the integrity and trust of their systems.

Blog Post

Analyzing Hardware Security: The Tools Powering RESCALE’s Dynamic Hardware…

Detecting and mitigating hardware vulnerabilities requires specialized tools capable of extracting, processing, and analyzing physical security risks within cryptographic and FPGA-based systems. The Dynamic Hardware Analyzer (DHA) in RESCALE is built around a suite of tools designed to identify side-channel leakage, detect exploitable vulnerabilities, and assess security risks in hardware implementations. These tools focus on trace collection, preprocessing, and attack simulations, ensuring that supply chain components undergo rigorous security validation before deployment.

Extracting Side-Channel Data with the Trace Collection Tools

To detect hardware vulnerabilities, the first step is capturing physical traces from the target system. The Trace Collection Layer of the Dynamic Hardware Analyzer includes several specialized tools that record power consumption, electromagnetic emissions, and timing variations during cryptographic operations. These traces serve as the foundation for further analysis.

One of the primary tools in this layer is FlexLECO, an FPGA-based leakage assessment framework that performs large-scale trace collection and real-time monitoring. Unlike conventional power measurement tools, FlexLECO integrates directly with FPGA implementations, enabling high-speed acquisition of side-channel signals while minimizing measurement interference. Additionally, the system leverages ChipWhisperer, a well-known open-source platform designed for side-channel attack research. ChipWhisperer captures power consumption fluctuations during cryptographic operations, allowing security analysts to detect unintended leakage paths.

Another key tool in the trace collection phase is the use of on-chip FPGA sensors, which monitor transient power variations and signal fluctuations at an extremely fine-grained level. These sensors allow for low-noise trace acquisition, making it possible to detect even minimal leakage that could expose cryptographic keys or other sensitive data.

Processing and Filtering Traces with the Preprocessing Software Library

Once traces are collected, they must undergo preprocessing to filter out noise and highlight relevant leakage information. The Trace Preprocessing Software Library plays a crucial role in this phase by applying signal filtering, normalization, and correlation analysis techniques. This ensures that collected traces are clean, structured, and ready for in-depth security assessment.

This software suite applies statistical tests such as Test Vector Leakage Assessment (TVLA) to determine whether the captured traces exhibit unintended data-dependent variations. TVLA is the primary statistical method used in RESCALE for evaluating cryptographic leakage. It helps identify leakage points where cryptographic implementations may be revealing sensitive information. These points appear as deviations in signal quantification, which can be statistically analyzed to determine the likelihood of an exploitable vulnerability.

The AES Leakage Plot above illustrates the results of a TVLA leakage test. The graph visualizes quantification over time samples, with several identified peaks that indicate points of significant leakage. These leakage points suggest areas where cryptographic keys or sensitive operations might be unintentionally exposed, requiring further investigation to assess their exploitability. The presence of strong deviations in power consumption signals at specific time samples confirms that certain cryptographic operations may be leaking data in a manner detectable through side-channel analysis.

Detecting Security Weaknesses with the SCA Script Software Library

After preprocessing, the SCA Script Software Library is used to conduct security evaluations and attack simulations. This toolset applies correlation power analysis (CPA), machine-learning-based template attacks, and non-specific (NS) assessments to determine whether an attacker could extract sensitive information from the collected traces.

The CPA method is particularly effective in identifying linear relationships between power consumption and cryptographic key bits, making it a widely used attack technique against AES, RSA, and other encryption standards. In contrast, machine-learning-based template attacks leverage pre-trained statistical models to recognize leakage patterns, even in the presence of noise or countermeasures.

The NS assessment approach is used to detect leakage without assuming a specific attack model. This technique helps analysts identify general leakage trends before applying targeted cryptographic attack models like CPA. NS assessment is particularly useful in discovering unexpected security weaknesses that might not align with traditional attack strategies, ensuring a broader evaluation of side-channel resilience.

The SCA Trace Analyzer Flow diagram illustrates the relationship between preprocessing, penetration testing, and reporting within the Dynamic Hardware Analyzer. At the core of this system, the Trace Preprocessing Software Library processes collected traces, applying signal filtering and statistical assessments. The SCA Script Software Library then runs advanced side-channel attack models, including SCA penetration testing assessments, which attempt to exploit detected vulnerabilities. The results are structured into NS reports and SCA pentest reports, feeding into broader supply chain security validation efforts.

Assessing Multi-Tenant FPGA Security Risks

One of the unique challenges addressed by the Dynamic Hardware Analyzer is the security of multi-tenant FPGA environments. When multiple users share the same FPGA fabric, one user may unintentionally or maliciously extract information from another user’s operations, leading to data leakage risks.

To analyze this threat, the DHA integrates tools that simulate cross-tenant leakage scenarios, measuring how shared hardware resources expose unintended data flows. These tests assess whether attackers can infer cryptographic computations performed by another tenant, helping to enforce stricter FPGA isolation policies.

Generating Security Reports for Supply Chain Validation

The final step in the hardware security analysis process is structuring the collected findings into a standardized security report. The results from FlexLECO, ChipWhisperer, and the SCA Script Software Library are aggregated into the Dynamic Supply Chain Component Guarantee (DSCG). This structured document provides a comprehensive assessment of detected vulnerabilities, categorizing them based on severity, exploitability, and recommended mitigations.

The CDX Validator processes these reports to ensure they adhere to standard security assessment frameworks. Once validated, the DSCG is integrated into the RESCALE Management Module, contributing to supply chain security assurance and risk mitigation strategies.

Conclusion

The Dynamic Hardware Analyzer in RESCALE is powered by a sophisticated suite of tools designed to capture, process, and analyze side-channel leakage data. FlexLECO and ChipWhisperer provide high-resolution trace collection, while on-chip FPGA sensors enable real-time monitoring of leakage effects. The Trace Preprocessing Software Library ensures high-quality signal processing, while the SCA Script Software Library applies advanced CPA, machine-learning, and non-specific analysis techniques to detect vulnerabilities.

By aggregating results into the DSCG, the module provides structured security assessments that contribute to supply chain risk management. As hardware security threats continue to evolve, automated security testing tools remain essential for ensuring that cryptographic and FPGA-based systems remain resistant to side-channel attacks and unintended leakage risks.

Follow us on Social Media

Blog Post

Detecting Hardware Vulnerabilities: The Role of RESCALE’s Dynamic Hardware…

As modern computing systems become more interconnected, the need for hardware-level security has never been more critical. While traditional security measures focus on software vulnerabilities, attackers increasingly exploit low-level hardware flaws to bypass security protections, extract sensitive information, or launch side-channel attacks. Hardware vulnerabilities are particularly dangerous because they often persist across software updates and may not be easily patched once a system is deployed.

Within the RESCALE project, the Dynamic Hardware Analyzer is specifically designed to address these risks by detecting and analyzing hardware vulnerabilities and leakage threats. By employing advanced security testing techniques, the module helps uncover side-channel attack (SCA) risks, power analysis vulnerabilities, and data leakage threats in cryptographic and FPGA-based systems

Understanding Hardware Vulnerabilities and Side-Channel Attacks

Hardware vulnerabilities can arise due to various factors, including design flaws, unintended electromagnetic emissions, power fluctuations, or signal timing variations. Unlike software-based vulnerabilities, these issues cannot be fixed with a simple patch; instead, they require thorough detection and mitigation strategies before deployment.

One of the most concerning classes of hardware threats is side-channel attacks. These attacks do not directly exploit software bugs but rather take advantage of unintended physical leakages such as power consumption, electromagnetic emissions, or execution timing. SCAs are particularly effective against cryptographic hardware implementations, allowing attackers to extract secret encryption keys by analyzing physical behavior rather than breaking the encryption algorithm itself.

The Dynamic Hardware Analyzer in RESCALE is designed to systematically detect such vulnerabilities, ensuring that hardware security risks are identified before attackers can exploit them.

How the Dynamic Hardware Analyzer Works

The Dynamic Hardware Analyzer is an advanced security testing module that evaluates hardware components, cryptographic accelerators, and FPGA-based designs for security weaknesses. Its primary role is to collect, process, and analyze side-channel leakage traces, determining whether a system exhibits security flaws that could be exploited through power analysis, timing attacks, or other forms of SCAs.

The process begins with trace collection, where the analyzer captures physical side-channel data from hardware devices during cryptographic operations or other sensitive computations. Once collected, these traces undergo trace preprocessing, where signal processing techniques and statistical methods such as the Trace Preprocessing Software Library and SCA Script Software Library are applied to remove noise and extract useful security insights. Finally, the system conducts attack simulations and risk assessments, leveraging Test Vector Leakage Assessment (TVLA) tests and NS report-based analysis to determine whether an attacker could successfully exploit the detected leakages.

These steps ensure a comprehensive evaluation of hardware security risks, helping organizations strengthen their supply chain security before deploying critical hardware components.

Architecture of the Dynamic Hardware Analyzer

The architecture of the Dynamic Hardware Analyzer is structured to efficiently process side-channel leakage data and detect potential hardware vulnerabilities. It consists of several key components that work together to analyze security risks in cryptographic implementations and FPGA-based systems.

As illustrated in the Dynamic Hardware Analyzer architecture, the module consists of three main layers: the Trace Collection Layer, the Trace Analysis Layer, and the Evaluation and Reporting Layer. The Trace Collection Layer is responsible for capturing side-channel data such as power consumption, electromagnetic emissions, or execution timing variations from a target hardware system. This data is then transferred to the Trace Analysis Layer, where advanced statistical methods, correlation analysis, and machine learning models process the information, identifying whether the hardware leaks sensitive information. Finally, the Evaluation and Reporting Layer integrates these findings into structured security reports, ensuring that vulnerabilities are properly categorized and assessed.

This layered architecture ensures that security assessments are not only comprehensive but also scalable, allowing multiple hardware components to be evaluated within a controlled environment. By structuring the analysis process in a modular way, the Dynamic Hardware Analyzer can be adapted to different hardware platforms, making it a versatile tool in RESCALE.

Integration with RESCALE

The Dynamic Hardware Analyzer does not function in isolation. It is fully integrated into the broader RESCALE security pipeline, ensuring that hardware security risks are assessed alongside software vulnerabilities. The findings from the module contribute directly to RESCALE’s Trusted Bill of Materials (TBOM), consolidating security guarantees across the entire supply chain.

By working in conjunction with other security modules, such as the Static Code Analysis Module and the Low-Level Security Testing Module, the Dynamic Hardware Analyzer ensures that both hardware and software components undergo rigorous security validation before deployment. This multi-layered security approach strengthens the overall resilience of computing systems, helping organizations detect, analyze, and mitigate hardware security threats before they become a liability.

Importance of Hardware Security

Hardware vulnerabilities are becoming an increasingly attractive target for advanced persistent threats (APTs) and state-sponsored attacks. Unlike software exploits, which can often be mitigated through patches and updates, hardware flaws may persist throughout a device’s lifecycle, making early detection crucial.

By integrating hardware security testing into supply chain security practices, organizations can reduce the risk of data breaches, intellectual property theft, and cryptographic key extraction. The Dynamic Hardware Analyzer in RESCALE ensures that hardware vulnerabilities are systematically detected and addressed, reinforcing the security of critical computing infrastructure.

Conclusion

The Dynamic Hardware Analyzer in RESCALE is a key component in modern hardware security testing, providing organizations with the ability to detect, analyze, and mitigate hardware-level vulnerabilities before they can be exploited. By leveraging advanced trace collection, preprocessing, and side-channel attack detection techniques, the module plays a crucial role in strengthening supply chain security.

By integrating with the broader RESCALE security framework, the module ensures that low-level security assessments contribute to the overall supply chain security process. In the next article, we will explore the specific tools and methodologies used within the Dynamic Hardware Analyzer, including trace collection devices, machine learning-based SCA detection techniques, and advanced cryptographic leakage assessments.

Follow us on Social Media

Blog Post

Unveiling Security Flaws in Low-Level Components: The Tools Behind…

Securing low-level system components such as firmware, kernel modules, and system drivers is essential for modern cybersecurity. Unlike higher-level application security testing, low-level security assessments focus on identifying vulnerabilities that reside within memory management, hardware interactions, and kernel-space execution flows. Attackers increasingly exploit speculative execution flaws, kernel privilege escalation bugs, and Return-Oriented Programming (ROP) gadgets to gain control over systems at the lowest level.

To address these risks, RESCALE’s Low-Level Security Testing Module integrates a set of specialized tools that systematically analyze firmware, detect execution flaws, and assess security vulnerabilities in embedded and kernel-level components. These tools provide automated and scalable methods for identifying low-level security weaknesses, ensuring that supply chain components undergo rigorous security validation before deployment.

Detecting Exploitable Gadgets with InSpectre Gadget

One of the most critical attack vectors in modern systems is Return-Oriented Programming (ROP) exploitation, where attackers chain exploitable instruction sequences (gadgets) to execute arbitrary code without injecting new code into memory. InSpectre Gadget is a low-level security analysis tool that systematically scans kernel binaries to identify and classify potentially exploitable ROP gadgets.

The tool processes kernel targets, analyzing compiled binaries to extract instruction sequences that could be repurposed by an attacker. Once extracted, these exploitable gadgets undergo automated filtering, removing sequences that are unlikely to be useful for an exploit. The remaining filtered gadgets are then reviewed by security analysts, who assess whether they can be leveraged to bypass control defenses and craft working exploits.

The provided diagram illustrates the workflow of InSpectre Gadget. It begins by analyzing kernel binaries to extract potentially exploitable instruction sequences. The filtering stage refines these sequences, ensuring that only relevant gadgets are retained. A security analyst then evaluates the control defenses in place, selecting a final set of gadgets that can be used to develop proof-of-concept exploits. This structured process ensures that kernel vulnerabilities are identified efficiently, allowing organizations to mitigate ROP-based attack risks before they can be exploited.

Mitigating Side-Channel Attacks with SafeFetch

Modern processors are vulnerable to side-channel attacks, where attackers extract sensitive information by exploiting microarchitectural behaviors such as speculative execution, cache timing, and branch prediction. SafeFetch is a specialized security testing tool designed to detect and mitigate speculative execution vulnerabilities in syscall operations.

The tool evaluates syscall handling mechanisms, identifying cases where untrusted input can manipulate processor behavior to leak privileged information. SafeFetch achieves this by analyzing syscall execution flows, detecting unsafe speculative accesses, and ensuring that all execution paths conform to strict security policies.

The provided SafeFetch architecture diagram illustrates how the tool monitors syscall execution. When a syscall is invoked, SafeFetch first applies a transfer function that defines a sanitized search range, ensuring that speculative execution does not access unauthorized memory regions. The cache frontend checks if the syscall results can be retrieved securely from a cached entry. If a cache miss occurs, the backend allocator provisions a new entry, ensuring that speculative execution does not introduce side-channel vulnerabilities.

SafeFetch plays a crucial role in mitigating speculative execution flaws, preventing attackers from leveraging side-channel leaks to extract sensitive system data. Its integration into the Low-Level Security Testing Module ensures that firmware and kernel components are systematically tested for microarchitectural security risks, reducing the likelihood of exploits such as Spectre, Meltdown, and other transient execution attacks.

Enhancing Security Testing with FATex

FATex is another core component of the Low-Level Security Testing Module, focusing on firmware and kernel-level fault injection testing. Unlike conventional fuzzing tools, which primarily test application-layer inputs, FATex is designed to simulate fault conditions at the hardware and firmware execution levels.

By running fault injection campaigns, FATex assesses how firmware and kernel components behave under abnormal conditions, such as corrupt memory states, unexpected interrupts, and hardware failures. These tests reveal critical stability and security weaknesses, allowing developers to fortify system resilience against real-world attack scenarios.

The tool integrates with emulation frameworks such as QEMU, enabling large-scale automated firmware testing without requiring direct hardware access. By ensuring that low-level components are tested for execution robustness, FATex strengthens supply chain security validation, making it a key asset in the RESCALE security pipeline.

Generating the DSCG for Low-Level Security Assessments

As with other security testing modules in RESCALE, the results from InSpectre Gadget, SafeFetch, and FATex are aggregated into the Dynamic Supply Chain Component Guarantee (DSCG). This structured document consolidates security findings from low-level component analysis, ensuring that all vulnerabilities are properly categorized, validated, and integrated into supply chain security workflows.

The DSCG generation process aggregates findings from multiple analyzers, verifying that all tested firmware and kernel components adhere to strict security policies. The results are then processed by the CDX Validator, ensuring that vulnerabilities are reported in a standardized format. Once validated, the DSCG is fed into the RESCALE Management Module, where it becomes part of the broader security assurance framework.

By incorporating low-level security testing results into structured security assessments, the DSCG ensures that all firmware and kernel security guarantees are properly documented, helping organizations maintain high-security standards throughout the supply chain.

Conclusion

The Low-Level Security Testing Module in RESCALE is powered by a specialized set of security tools designed to analyze firmware, kernel components, and hardware interactions. InSpectre Gadget detects exploitable ROP gadgets, helping security teams identify kernel-level attack vectors before they are weaponized. SafeFetch mitigates speculative execution vulnerabilities, preventing side-channel data leaks in system calls. FATex enables firmware and kernel fault injection testing, strengthening system resilience against memory corruption and unexpected execution failures.

Together, these tools provide a comprehensive assessment of low-level security risks, ensuring that firmware, kernel modules, and embedded software undergo rigorous testing before deployment. By integrating their findings into the DSCG, the Low-Level Security Testing Module ensures that all vulnerabilities are properly validated and integrated into the broader supply chain security framework.

As cyber threats increasingly target low-level system components, automated security testing remains essential for protecting modern computing environments. The RESCALE framework ensures that all tested components receive structured security guarantees, providing a robust foundation for supply chain security.