Can SOLARBURST go silicon? A systematic analysis on software supply chain attacks for VLSI design flows

Can SOLARBURST go silicon? A systematic analysis on software supply chain attacks for VLSI design flows

arXiv:2610.22580v1 [cs.CR] 15 Oct 2026

Fabiha Hashmat Purdue University

Zeren Li Purdue University

Abstract

Modern VLSI design projects (e.g., Google–SkyWater Open MPW program [40, 68, 103], Riscduino [5, 114], and Microwatt 64-bit OpenPOWER core [16]) increasingly rely on a SWSC composed of open-source tools spanning multiple stages, these include Yosys, OpenROAD, Magic and the OpenLane. This reliance is consistent with industry trends: over 90% of codebases in the computer hardware and semiconductor domain include open-source components, which constitute a significant fraction of the overall software stack [97]. Similarly, commercial VLSI design projects such as Cadence also relies on the use of open source software or IP licensed from third parties in their products [21]. While these projects benefit from open-source and thirdparty software for accelerated development, they also introduce a wholly new attack surface into the VLSI design process. Large-scale industry studies show that open-source components are pervasive and frequently vulnerable: the 2024 Open Source Security and Risk Analysis (OSSRA) report by Synopsys found that 84% of audited codebases contained at least one known vulnerability [98]. In parallel, SWSC attacks targeting open-source dependencies have increased sharply in recent years [67]. Further, according to Cadence 2024 Annual Report [21], they admitted the use of open source solutions in their products may cause vulnerabilities that are in turn exploited by attackers. When those open source and third-party components with known vulnerabilities are integrated into VLSI toolchains as trusted software artifacts, design-level flaws may be introduced, and their misbehavior can propagate across the entire VLSI design pipeline. An attacker targeting the SWSC of these VLSI software suites maybe able to fully subvert a VLSI pipeline uniquely from a software perspective. This highlights a fundamental challenge in securing VLSI design process SWSC – how can we ensure the trustworthiness of a VLSI design when misbehaving open-source software within its toolchain can compromise the entire pipeline? However, literature on both SWSC [34, 58] and VLSI security [33, 70, 72, 96] has not explored the ways in which software can be used to subvert the security of the VLSI

An attacker targeting the software supply chain (SWSC) of VLSI tools can fully subvert the VLSI design pipeline through purely software level compromises. However, current literature on both SWSC and VLSI hardware security has not explored how software can be used to subvert the security of the VLSI design flow. In order to bridge this gap, this paper presents a systematic analysis of the vulnerable surface of VLSI from a SWSC standpoint. We carry this analysis through three major activities. First, we did an empirical analysis of VLSI software suites, focusing on their software composition, security features, and tool interactions within the VLSI design flow. Second, we develop a VLSI-SWSC attack taxonomy model that links software supply chain attacks and their mechanisms to the VLSI attacks they enable, the design-flow stages they affect, and their resulting security outcomes, allowing us to identify 717 possible new attacks, including 60 high feasibility attacks supported by evidence collected in our empirical analysis. Third, we identify what possible security outcomes can be achieved by an attacker from these attacks and produce a comprehensive VLSI SWSC threat model. We evaluate the feasibility of the attacks identified by our taxonomy across VLSI design stages and assess existing defenses to determine which attacks are mitigated and which remain unaddressed. In addition, we present case studies using a reference VLSI design flow consisting of opensource VLSI tools and highlight attacks identified through our taxonomy on the VLSI SWSC uniquely from a software perspective.

1

Santiago Torres-Arias Purdue University

Introduction

The software supply chain (SWSC) of the VLSI supply chain is a combined network of software artifacts (e.g., design tools, source code, and open-source or third party dependencies), and software driven processes (e.g., build pipelines, deployment configuration/environment) involved in the design, transformation, optimization and validation of VLSI designs [68]. 1

supply chain. For example, methodologies like split manufacturing [46], which are effective in protecting against hardware Trojans, IP theft [23, 51], and unauthorized reproductions [113], prompt the inquiry — can these threats also be conducted through a software only vector? This same vector can also enable IP theft and unauthorized reproduction, since VLSI software suites are tightly interconnected and depend on external components such as third-party IP cores. In practice, this occurs through software-level compromise of tool binaries, plugins, or shared libraries that handle intermediate design artifacts, which often contain proprietary IP. To address this research gap, we aim to answer: how an attacker can subvert a VLSI design process, uniquely from a software perspective, and what can they achieve by doing so? The main contributions of the research are: Systematic study of reference VLSI software composition: we analyze select VLSI software suites to identify their SWSC, with a particular focus on open source components and libraries utilized during “pre-silicon” phases: VLSI design, testing, and synthesis. VLSI-SWSC attack taxonomy: we develop a VLSI-SWSC attack taxonomy that links SWSC attacks and their mechanisms to the VLSI attacks they enable, the design-flow stages they affect, and their resulting security outcomes, allowing us to identify 717 possible new attacks, including 60 highfeasibility attacks supported by evidence collected in our empirical analysis. Exhaustive study of possible security outcomes: with the two above, we identify what possible outcomes can be carried out from these attacks and use them to construct a comprehensive VLSI-SWSC threat model. Defense Analysis: Leveraging the CIS SWSC Security Guide, we evaluate the coverage of existing defenses against VLSI SWSC attack-path classes and identify gaps in current mitigation strategies. Case Study: We evaluate our threat model on a representative VLSI design flow consisting of open-source tools by implementing software-only attacks selected from our VLSI-SWSC attack taxonomy, focusing on vectors introduced through third-party libraries and dependencies. We discuss one speculative attack scenario derived from the same taxonomy. Our analysis reveals that software dependencies embedded within VLSI software suites can serve as direct attack vectors capable of subverting the integrity of the entire VLSI design process. Through our empirical study and VLSI-SWSC attack taxonomy, we identify 717 possible new attacks, including 60 high-feasibility attacks supported by evidence collected in our empirical analysis, and characterize how these attacks can affect different VLSI design stages. Our results show that while certain classes of attacks are partially mitigated by existing industry practices and current literature, significant coverage gaps remain particularly for attacks emerging from unvalidated open-source components and inter-tool interactions. By mapping these model identified attacks to defense controls

outlined in the CIS SWSC Security Guide, our study reveals critical blind spots in existing VLSI SWSC protections and highlights where future defenses must improve.

Figure 1: VLSI Design Process

2

Background and Research Gap

This section introduces the terminology used throughout the paper, outlines the software supply chain of the VLSI design process, characterizes SWSC attack phases, and identifies the research gap that motivates our study.

2.1

Terminology

Multiple organizations define SWSC terminology, including the National Institute of Standards and Technology (National Institue of Standards and Technology, NIST) through SP 800161 Rev. 1 and the Secure Software Development Framework (SSDF), the Open Source Security Foundation (OSSF) threat classifications, the Cybersecurity and Infrastructure Security Agency (CISA), the European Union Agency for Cybersecurity (ENISA) ICT supply chain risk models, the Center for Internet Security (CIS) SWSC Security Guide. While these differ in scope and intended audience, they consistently describe the SWSC in terms of software artifacts, build and integration process. Among these NIST consolidates all of these core concepts within a single, unified framework, providing sufficient coverage of the terminology required for our analysis. Prior software SWSC research commonly adopts NIST terminology when formalizing attack surfaces. We therefore follow NIST terminology as a single reference point to remain consistent with existing literature and to avoid redundant comparison of largely overlapping definitions. Following are the definitions of basic supply chain terms being used henceforth. Software Supply Chain: NIST SP 800-204D [9] defines a software supply chain as “a collection of steps that create, transform, and assess the quality and policy conformance of software artifacts. These steps are often carried out by different actors who use and consume artifacts to produce new artifacts” Supply Chain Attack: NIST SP 800-161 Rev. 1 [18] defines this as “an occurrence within the supply chain whereby the confidentiality, integrity, or availability of a system or the 2

information the system processes, stores, or transmits is jeopardized.” SWSC Attack: NIST SP 800-204D [9] defines this as “a malicious party tampering with the steps, artifacts, or actors within the chain to compromise downstream consumers of a software artifact.” Such attacks typically follow a three-stage process [56]: (i) artifact, step, or actor compromise, (ii) propagation through the chain, and (iii) exploitation to achieve attacker goals (e.g., data exfiltration, cryptojacking). In this context, actors represents the entities that perform activities in the supply chain (e.g., developers, or build systems); steps refer to the software-development or delivery processes (e.g., build, test, package, deploy); and artifacts are the software objects exchanged between these steps (e.g, source code, binaries, packages, or container images). CIA Triad: As we know, confidentiality, integrity, and availability (CIA) form the core security objectives; we adopt the NIST definitions from NIST SP 800-12 Rev. 1 [77]. Confidentiality—preserving authorized restrictions on access and disclosure, including protection of privacy and proprietary data; Integrity—guarding against improper modification or destruction and ensuring authenticity; and Availability—ensuring timely and reliable access.

2.2

be used. These IPs are often sourced from third-party vendors (3PIPs) [15], and pose a security risk if malicious or unverified, potentially introducing backdoors or undocumented behaviors from the outset. High-Level Synthesis (HLS): converts software-like specifications (e.g., C, MATLAB) into hardware level descriptions (e.g., Verilog). A compromised HLS tool or script can misallocate resources, insert convert logic or degrade parallelismintroducing inefficiencies or malicious behavior into the RTL (Register Transfer Level). Verification: confirms functional correctness after HLS using simulation or formal methods. Formal techniques—such as equivalence checking, model checking, and theorem proving—verify behavior against specifications. If verification fails to capture transformations, injected logic or altered properties may remain undetected Logic Synthesis: converts RTL into a gate-level netlist using standard cell libraries with delay and power data. It includes logic simplification, synthesis, technology mapping and optimization. Malicious scripts or tool misuse can modify logic or insert hidden structures, risking functional correctness. Post-Synthesis Verification: ensures the synthesized gatelevel netlist matches the RTL design. Equivalence checking is used to detect unintended changes. Compromising this step may fail to catch logic tampering/synthesis induced deviations. Design for Test (DFT): adds test structures like scan chains and JTAG for post-silicon debugging. It includes placement and routing (floor-planning, clock tree synthesis, etc.) and static timing analysis to ensure timing correctness. Malicious manipulation can misreport timing paths, enabling timingbased side-channel attacks, and expose internal states or introduce access points (e.g., a hidden JTAG port).

SWSC of VLSI Design Process

Following NIST’s definition of a software supply chain, we consider the VLSI SWSC as the software-supply-chain steps and artifacts involved in the VLSI design flow, where EDA software consumes, transforms, and produces design artifacts across successive design stages. This scope includes the EDA tools and their software components and dependencies used from design specification through manufacturing testing. Various tasks are involved in creating an electronic device, including laying out functional units of a device (i.e., logical portions of the device), synthesizing that design into a lowlevel gate design, and ensuring the quality of the end-result (e.g., by ensuring electrical/timing properties are held), among others. [112] [15, 69] Below, we elaborate on the most common activities performed on the VLSI design flow. Figure 1 provides a graphical overview of the VLSI design process steps, compiled through a study of tool vendors such as Cadence [20]) as well as academic sources like [10]. In the context of this paper, we focus on the pre-silicon phase-from design specification to physical verification and sign off. We list the tools within this flow in Table 1. We examine pre-silicon design workflows because the software used at this stage—synthesis, simulation, verification, and timing analysis—pulls in a diverse set of third-party components (e.g., SAT/SMT solvers, parsing libraries, numerical optimization engines, scripting runtimes) [6, 85]. Design Specification: Defines high-level functional requirements and identifies the set of Intellectual property blocks to

2.3

Software Supply Chain Security

SWSC security have two related but distinct categories: vulnerable supply chain and deliberate supply chain attacks. The first category covers accidental weakness (vulnerable dependencies or poor development practices) that adversaries may later exploit. While second category,deliberate supply chain attacks result in by intervention in trusted tools, dependencies, build processes to alter downstream supply chain steps and artifacts. In this paper, we are focused on the later scenario. Software Supply Chain Attacks [62, 81, 108], are devastating attack vectors that can fully subvert a software product without exploiting vulnerabilities in the software itself. Such attacks typically involve three phases: injection, where an attacker compromises a dependency or tool (e.g., a compiler) to insert malicious code; propagation, where the modified artifact spreads through the supply chain to reach the target; and exploitation, where the attacker leverages the compromised artifact (e.g., a backdoored binary) to achieve their goals. As recent incidents have shown, SWSC attacks have be3

come increasingly prevalent, impacting organizations across multiple sectors, including government systems [29].

2.4

Figure 2: The research methodology. We first explore the vulnerable surface from VLSI software, incorporate an attack feasibility assessment and a defense analysis guided by the CIS framework, and then tie this surface to security-relevant outcomes. We finally synthesize a threat model using this information and test the model against a VLSI design flow.

Research Gap:

With this in mind, we posit the following research question: In what ways can an attacker subvert a VLSI design process, uniquely from a SWSC perspective? RQ 1: What are the key characteristics of VLSI software suites and nature of the software vulnerabilities that are often introduced in VLSI software through their supply chain, and how can we systematically categorize their roles, capabilities, and interactions within the design process? (Section 4) RQ 2: What are the potential security outcomes of SWSC attacks, and how can we systematically categorize these outcomes to ensure a comprehensive and exhaustive security taxonomy? (Section 6) RQ 3: What defense mechanisms—analyzed using the CIS SWSC Security Guide—currently exist to mitigate VLSI-SWSC attack model classes? (Section 7)

3

hardening, and artifact verification which precisely covers the surfaces exploited in software-centric VLSI threats. We then mapped all attacks to the CIS SWSC Security Guide [41] - a consensus-based framework outlining measurable practices for securing SWSC - to quantify defense coverage across the identified attack-path classes Section (5). We further test this threat model through a case study using a representative VLSI design flow composed of opensource software. We implement three attacks selected from our VLSI-SWSC attack taxonomy (P376, P703, and P616) and separately discuss one additional taxonomy-derived attack scenario (P624) as speculative. For open-source tools we used Yosys (a logic synthesis tool) [122], OpenLane (a toolchain providing RTL-to-GDSII implementation flow) [28] and Magic [90]. We selected these tools based on their active community development, citation frequency in academic literature, and inclusion in widely used open-source VLSI flows such as OpenLane and the Google–SkyWater Open MPW program [103]. Mapping Software Tools For VLSI Design (Section 4): In order to concretize the possible operations carried by software within the VLSI design flow, we study popular open source VLSI software suits which are commonly used in academic and industry workflows. Open source VLSI design process tools are gaining traction as a cost effective, easy access to education and research, and the transparent, open collaborative and community driven nature provides an alternative to proprietary solutions, which often pose barriers to accessibility due to licensing restrictions and vendor lock-in [82]. Notably, initiatives like DARPA’s Electronics Resurgence Initiative have actively supported open-source EDA development. Moreover, strategic assessments of semiconductor resilience now recognize that long-term trends such as "open-silicon" -encompassing open source EDA, IP and PDKs- warrant global support, especially in response to geopolitical constraints on proprietary EDA exports [60]. Further, we lean on literature from [10] and [62] that explore conceptual models for the VLSI design process. This way, we are able to categorize individual tools within each suite, within a particular application domain. Doing this will enable us to develop three pieces of knowledge: first, a clear understanding of tool capabilities (i.e., what is expected from

Methodology

To answer these research questions, we conduct a structured analysis of the current literature and an in-lab empirical analysis of VLSI software suites using standard software analysis techniques. Succinctly put, we aim to understand the state of the art in the VLSI design flow to identify the tools used within it, then develop a comprehensive VLSI-SWSC attack taxonomy of software-only entry points for attackers in this chain, linking SWSC attacks and their mechanisms to the VLSI attacks they enable, the design-flow stages they affect, and their resulting security outcomes. To evaluate the feasibility of the attack paths identified by our taxonomy model, we use empirical evidence from our VLSI software analysis to classify the synthesized paths as high, medium, or low feasibility. We then assess how existing defenses align with these attack-path classes. Multiple software supply chain security frameworks exist, such as NIST SSDF, NIST SP 800-161 Rev.1, SLSA, CISA’s SBOM guidance, and the CIS SWSC security guide. Each offers different scopes and levels of abstraction, from high-level organizational governance (e.g, SSDF) to developer and buildsystem level operational controls (e.g, CIS, SLSA). Without a consistent reference model, evaluating attacks and defenses becomes difficult. Therefore, we select the CIS SWSC Security Guide because, among existing frameworks, it offers the most implementation-oriented control families that map directly to the developer, dependency, and build behavior present in VLSI software suits. Whereas SSDF and SP 800161 provide high level policy guidance, and SLSA focuses narrowly on buid integrity provenance, CIS provides controls spanning source integrity, dependency validation, build 4

a tool, behaviorally). This includes the expected inputs/outputs and transformations a tool performs. Without baseline understanding of behavior, we cannot determine whether an attack/anomaly reflects normal tool functionality. Second, a concrete notion of data flow between tools (i.e., which tools produce software artifacts used by other tools). This data flow structure determines where supply chain vulnerabilities can propagate. Third, an overview of which vendors provide which tools, because we assume that companies may use a combination of vendors to fully satisfy their design activities. This context allows us to reason about cross-tool trust relationship and vendor-specific risk surfaces. Identifying Security Outcomes: (Section 5): We carry out a systematic exploration of possible security outcomes and identify security expectations such as data privacy (i.e., protecting intellectual property), data integrity (i.e., preventing hardware trojans), and availability (i.e., preventing sabotage of finalized designs). We use these security outcomes, together with the identified software-side attack vectors, exploitation mechanisms, and VLSI design stages, to construct our VLSI-SWSC attack taxonomy. In other words, by understanding the security expectations and the capabilities of a tool, we are able to answer research question RQ2 in order to achieve an outcome, what class of tools should an attacker compromise using a SWSC attack? Threat Model Synthesis (Section 6): Lastly, we employ the information from the two previous activities to synthesize and formalize a threat model by developing a taxonomy-based model that outlines the degrees of access that an attacker require to achieve a security outcome. In other words, we combine tool capabilities, with security expectations, and attacker access, to derive all possible SWSC related entry-points for an attacker on each individual target. This taxonomy-based model also allows us to determine strategies to enumerate and explore the vulnerable surface of any particular instantiation of a VLSI design software. Attack and Defense Analysis (Section 7): Building on the VLSI-SWSC attack taxonomy, we evaluate the feasibility of the identified attacks and examine the extent to which existing defenses address them. Given its comprehensive coverage of software supply chain controls and industry adoption, we employ the CIS Software Supply Chain Security Guide as a structured framework to analyze countermeasures against software supply chain threats in VLSI flows. This structured analysis highlights critical coverage gaps in mitigating SWSC threats within VLSI design flows, guiding the development of our defense mapping framework. We further evaluate the feasibility of synthesized attack paths using empirical evidence and assess their coverage under existing software supply chain security controls Evaluation (Section 8): Finally, we utilize the model derived above to select representative attacks for evaluation on an open-source VLSI design flow. Specifically,

we implement three attacks selected from our VLSI-SWSC attack taxonomy—P376, P703, and P616, covering confidentiality, availability, and integrity outcomes, respectively, and separately discuss one taxonomy-derived speculative scenario, P624. Using these scenarios, we demonstrate how compromises of VLSI tools and their dependencies can affect design artifacts and downstream stages of the VLSI design flow.

4

Empirical Analysis of VLSI software suites

This section presents an empirical analysis of VLSI software suites to understand why and how their roles, capabilities, interactions, and dependencies form a critical SWSC risk surface within the VLSI design process. We address this through the following research questions. RQ 1.1 What types of software are used in carrying out VLSI design process and how do these tools interact with each other? RQ 1.2 What are the capabilities of these tools with regard to the software artifacts being produced or used? RQ 1.3 What types of software libraries are utilized by these software tools, and how do these dependencies contribute to their vulnerable risk surface? We address each sub-question in the sections below. RQ 1.1: Tools Across VLSI Design Process and Their Interactions To answer RQ 1.1, we reviewed vendor documentation, open-source repositories, and academic literature to map the key open-source and proprietary tools used across each stage of the VLSI design process and analyze their interactions. This mapping reveals that key stages—especially logic synthesis and verification—rely heavily on open-source tools. This concentration matters because a compromise introduced through an open-source tool at these stages can persist in the generated design artifacts and propagate to subsequent stages, regardless of whether the downstream flow is implemented using open-source, proprietary, or mixed EDA toolchains. RQ 1.1 Key Findings Open-source tools support most pre-silicon design stages, with the highest concentration in logic synthesis, verification, and placement & routing, critical to design integrity and optimization as shown in Table 2. The growing contributors base e.g., Yosys with over 552 contributors (contributor counts are derived from public Github statistics) signals a rising shift towards community-driven alternatives in VLSI design.

Table 1 shows the tools utilized in VLSI design process. RQ 1.2 Capabilities of tools with regard to the software artifacts being produced or used To evaluate these capabilities, we employed a multi-pronged methodology combining dynamic syscall tracing, static dependency inspection, and privilege analysis.

5

Table 1: Capabilities and System Level Interactions of VLSI Software Suites. File System Access symbols: ● = Present, # G= Partial, #= None. ✓ = Yes, ✗ = No. Design Step High Level Synthesis High Level Synthesis Verification Logic Synthesis Logic Synthesis Placement & Routing Placement & Routing Static Timing Anal. Design for Testability Manufacturing Test

Tool LegUp Bambu Symbiyosys Yosys ABC Magic Qrouter OpenTimer Fault Atalanta

Artifact ● ● ● ● ● ● ● ● ● ●

File System Access Log Config Other #

#

●

G #

#

G #

#

G #

#

● ● ●

#

G #

# #

● ● G #

# # #

# G # G # G # G # # # #

CIS Technique

Third-party Tool Invoked

Shell Injection

Code Risks Code Risks Third-Party Code Risks Pipeline Instructions Third-Party Third-Party Code Risks Access to Artifacts Code Risks

✓ ✓ ✓ ✗ ✗ ✓ ✗ ✗ ✗ ✗

✗ ✗ ✗ ✗ ✗ ✓ ✓ ✗ ✗ ✗

posing clear code injection risks which is captured under the CIS Third-Party category.. These tools present moderate exposure due to unvalidated scripting and loose integration boundaries. OpenTimer, Fault, and Atalanta operate with minimal system interaction, lack external tool invocation, and show no evidence of privileged syscall use. Their execution is limited to local I/O with a narrow syscall surface. This behavior corresponds to lower exposure within the CIS Code Risks and Access to Artifacts category.

RQ 1.2 Key Findings Across the tools analyzed in Table 1, 100% operated at user-level privileges and none initiated network connections. However, 80% supported external script execution or third-party tool invocation.

System call tracing: We used strace and ltrace to observe key system-level interactions such as file access (openat, read, write), shell invocations (execve, system), and inter-process communication (mmap, socket, shmget). Dependency inspection: Using ldd to capture dynamically linked libraries and detect obsolete or vulnerable .so versions. Privilege examination: Using /proc/<pid>/status and pscap to verify whether elevated capabilities (e.g., CAP_SYS_ADMIN) are required. Security feature identification: We examined official documentation, help menus (e.g., -help, -h), and runtime logs to identify any built-in security options such as sandboxing, audit logging, privilege dropping, or strict parsing modes (e.g., -e, -s, -x.) The tools were exercised with minimal but realistic workflows (e.g., loading verilog files, running synthesis) to simulate standard use cases. Table 1 shows these observations. Our findings reveal that all analyzed tools operate at user-level privileges without requiring special system capabilities. Most tools lack essential security mechanisms such as input validation, and privilege confinement. Yosys, SymbiYosys, and LegUp operate in a path-confined mode without invoking external tools or shell commands, consistent with lower exposure in CIS Code Risks and Third-Party categories. ABC and Bambu exhibit similar isolation levels but rely on user-level configuration files or compilers, corresponding to exposure captured under the CIS Pipeline Instructions and Code Risk categories. Magic and Qrouter accept external Tcl scripts without validation and lack syscall restrictions. This behaviors reflects exposure within the CIS Third-Party category. While Magic invokes third-party plotting utilities, Qrouter supports exec within scripts,

RQ 1.3 Software Libraries utilized by VLSI Software Suites We identified third-party libraries in VLSI software using a combination of static analysis and dynamic inspection techniques. This included parsing build scripts, analyzing binary symbol tables using off-the-shelf tools (e.g., ldd) as well as custom tools, to performing source level inspection and trace both shared and statically linked external code. Concretely, we set off to identify the following measures: Static TPL Library Metadata, Ownership in VLSI Software Suites To measure the risk surface from a SWSC level, we identified the amount of external code and functions used by these tools. We sought to identify code that was statically integrated in these tools first. We measured these in low-level instructions (i.e., the percentage of code that exists in the tool’s binary). Percentage of Third-Party Shared Libraries Among All Shared Libraries Used by Each VLSI Software Similarly, we sought to identify the dynamically-loaded functions from third party code. We measured this at a function level, as it is impossible to know which version of this library will be loaded by a particular tool in every deployment. Table 2 presents the extent of integration of third-party libraries within open-source VLSI software by listing both shared and statically linked dependencies. This table highlights the widespread reliance on external components and record their roles, maintainers and last known update dates. Function6

level inspection reveals deep integration of shared libraries. Our shared library analysis tool can also identify which specific functions from shared third-party libraries are used. Yosys relies on popular libraries like libedit (12 functions), libtcl(24), libz(9), and libffi(7) functions. OpenSTA invokes 48 from libtcl and 5 libz functions. Further, tools like ABC and Magic utilize libedit (2) and libctl (5), confirming presence of third party libraries across the VLSI design process. Tools such as Yosys, OpenSTA, Magic, and OpenTimer depend on third-party libraries for core functionalities including scripting (libtcl8), command editing (libedit, readline), SAT solving (CUDD, MiniSAT), compression (libz), and graphics (libcairo, libXrender). These transitive and loosely maintained TPLs expand the risk surface by introducing indirect attack paths, particularly in the synthesis and timing analysis stages where silent injection or malformed data can propagate undetected. We also provide a breakdown of the contribution from each third-party library to the execution of each tool. As shown in Table 3, a significant portion of these originate from third-party sources. Tools like Yosys and OpenLane exhibit over 50% usage of shared third-party libraries, with Yosys having over 90% of its binary code originating from statically linked libraries such as abc, cudd, and solverl, indicating a growing reliance on external code that increases SWSC risk. Figure 3: Library Exposure Across VLSI Flow Stages. Stages correspond to the VLSI design steps shown in Figure 1. Cells mark stages affected by a vulnerable library within a tool (T1–T6), while cells denote unaffected stages. Tool-specific exposure is labeled by tool identifiers (T1–T6). Tools are: T1=ABC, T2=Yosys, T3=OpenSTA, T4=OpenLane, T5=OpenTimer, and T6=Magic. Annotations show downstream detection phases (Table 6).

RQ 1.3 Key Findings Our analysis shows that VLSI software suits relies heavily on thirdparty/open-source libraries. Across the analyzed software suites, these libraries form a substantial portion of the dependency base (both dynamically and statically linked libraries). Further, several of these libraries correspond to legacy versions last updated over decade ago, indicating potential security and maintenance gaps. The CVE distribution across third-party libraries demonstrates a significant risk surface.

Across five major VLSI software, third-party libraries account for up to 62% of total dependencies, with Yosys and OpenLane leading in external reliance. In Yosys, over 90% of binary functions in yosys-abc originate from statically linked TPLs. Similarly, OpenSTA’s sta binary shows notable dependence on libraries like CUDD and Eigen. Despite this heavy integration, certain third-party libraries used by VLSI software (e.g., libedit, libuuid, and statically linked components such as MiniSAT) correspond to legacy versions last updated over a decade ago, indicating potential security and maintenance gaps. The CVE distribution across third-party libraries in tools like Yosys (552 contributors, 9 CVEs at 9.8) and OpenLane (722 contributors, 8 CVEs at 9.8) demonstrates a significant risk surface. Further, Fig. 3 shows the exposure of third-party libraries across the VLSI design flow. Each row lists a library associated with a specific tool, while columns represent design stages. The colored cells mark the stages where a given library is used, revealing its span and persistence within the flow. These empirical observations provide the evidence used in

our feasibility analysis of the attacks identified by the VLSISWSC attack taxonomy(section: 5).

5

VLSI SWSC Attack Taxonomy

Before answering RQ2 we must develop an end-to-end model that accounts for software-supply-chain attack vectors, Asw , that enable capabilities, Msw , that can lead to a VLSI design attack, Avlsi , at a particular stage to achieve an outcome O. This allows us to identify exhaustively all possible attacks. Further, we reduce the list of possible attacks with a second pass to gauge feasibility by leveraging risk indicators from the section above. Formally, our modeled attack paths follow the ensuing sequence on the software side: Isw → Psw → Esw , where Isw denotes the SWSC injection or compromise 7

Table 2: Third-Party Library Risk Metadata Across VLSI Software Suites VLSI Software

Shared Library Category

Shared: Maintainers 1 552

Shared: Oldest Update 2012 2012

ABC Yosys

Command Editing Command Editing, Scripting, Compression, Interop/Linking, Visualization, UI, System Utils

OpenTimer OpenLane

94 722

2022 2010

OpenSTA

Scripting Scripting, Compression, Graphics, Parsing, X11/Display, System Utils Scripting, Compression

156

2022

Magic

Graphics, Scripting

436

2012

Static Library Category

SAT/Logic Solving Command Editing, Scripting, Parsing, Hashing/Security, SAT/Logic Solving, Interop/Linking, Math, File Format, Hierarchical Analysis Parsing n/a Graphics, SAT/Logic Solving, Math Scripting, Graphics

Table 3: Third-Party Library Usage in VLSI Software Suites VLSI Tool abc yosys OpenTimer OpenLane OpenSTA

Shared Libraries 16.67% 62.00% 12.50% 57.80% 11.10%

Static: Maintainers 1 881

Static: Oldest Update 2016 2010

High-Risk CVEs (>7.5)

1 n/a

2018 n/a

0 8 (9.8), 4 (8.8)

572

2015

436

2012

6 (9.8), 2 (8.8), 3 (7.8) 0

0 9 (9.8), 4 (8.8), 2 (9.1), 1 (9.0), 1 (8.5), 1 (8.4), 1 (8.1), 6 (7.8)

We define a complete VLSI-SWSC attack path as

Static TPL (function %) 0.00% 90.30% 0.17% 0.00% 5.37%

A p = ⟨Asw , Msw , Avlsi , S, O⟩, where A p denotes the attack path, Asw denotes the SWSC attack category, Msw denotes the software-side attacker capability enabled by that category, Avlsi denotes the corresponding VLSI-side attack class, S denotes the VLSI design stage where the attack can be realized or propagated, and O denotes the resulting security outcome. The complete category names and definitions for Asw , Msw , Avlsi , S, and O are provided in Appendix A. The derived model is shown in Fig. 4 and details are presented as follows.

point, Psw denotes propagation through the software supply chain, and Esw denotes exploitation when the compromised software element is consumed. We use this three-stage sequence as the conceptual basis for characterizing software supply-chain attacks. In the synthesized taxonomy, Asw denotes a software supply-chain attack category that forms the first element of the VLSI-SWSC attack path. Each software supply-chain attack category Asw can enable a software-side capability gained by the attacker, denoted Msw . Here, Asw captures how the attacker affects the software supply chain, while Msw captures the software-side capability enabled by that attack. The software-side capability Msw is then mapped to a VLSIside attack class Avlsi , which captures what the attacker can cause within the VLSI design flow. The VLSI-side attack class can occur at a design stage S and affect a security outcome O. Thus, the complete operational mapping of the model is Asw → Msw → Avlsi → S → O. The connection between the SWSC definition and the VLSI-side realization occurs through Msw . The exploitation stage Esw provides the attacker with a software-side capability; this capability is represented by Msw and determines which VLSI-side attack class Avlsi can subsequently be realized. Therefore, the conceptual SWSC sequence and the operational taxonomy are connected as

Isw → Psw → Esw

⇒

Figure 4: Overview of the VLSI-SWSC model. The first panel derives attack paths from SWSC and VLSI-security literature, while the second evaluates their feasibility using empirical evidence from Section 4.

Attack Path Exploration: Given the attack-path model defined above, we synthesize VLSI-SWSC attack paths by composing valid relationships between consecutive model

Asw → Msw → Avlsi → S → O. 8

elements. Rather than constructing an unrestricted Cartesian product, a path is generated only when an Asw category enables an Msw capability, that capability can be realized as an Avlsi attack class, and the corresponding VLSI-side attack can occur at a design stage and affect a security outcome. The final attack-path synthesis rule implemented in our model is:

under the current evidence set. The complete evidence mappings and feasibility rubric are provided in Appendix A. The principal rule used to identify high-feasibility attack paths is: high_feasibility_path(A_sw, M_sw, A_vlsi, Stage, Outcome) :attack_path(A_sw, M_sw, A_vlsi, Stage, Outcome), category_high_with_evidence(asw, A_sw), category_high_with_evidence(msw, M_sw), category_supported_with_evidence(avlsi, A_vlsi), observed_stage(Stage).

attack_path(A_sw, M_sw, A_vlsi, Stage, Outcome) :valid_asw_msw_pair(A_sw, M_sw), valid_msw_avlsi_pair(M_sw, A_vlsi), valid_causes(A_vlsi, Stage, Outcome).

We constructed the Prolog model by synthesizing attack categories from prior software supply-chain and VLSI-security literature. Specifically, we encoded software supply-chain attack types (Asw ), software-side attacker capabilities (Msw ), VLSI-side attack classes (Avlsi ), design-flow stages (S), and security outcomes (O) as model entities. We then added reviewed mappings between these entities. The Asw → Msw mappings capture how software supply-chain attack types can lead to attacker capabilities in the software environment, while the Msw → Avlsi mappings capture how those capabilities can realize VLSI-side attack classes. Finally, the Avlsi → S and Avlsi → O mappings capture where each VLSI-side attack class may occur and which security property it may affect. Together, these mappings define possible paths of the form Asw → Msw → Avlsi → S → O. Here, valid_asw_msw_pair requires that Asw enables Msw ; valid_msw_avlsi_pair requires that Msw can realize Avlsi ; and valid_causes requires that Avlsi is possible at stage S and affects outcome O. These constraints determine which combinations form valid model-generated VLSISWSC attack paths.

Accordingly, a synthesized path is classified as high feasibility only when both Asw and Msw have high support backed by mapped empirical evidence, Avlsi has high or medium support backed by mapped evidence, and the corresponding design stage was observed in our empirical analysis. Paths that do not satisfy the high-feasibility rule are classified as medium feasibility when partial support remains across the modeled components. Specifically, medium feasibility requires either support for both Asw and Msw , high support for either software-side component together with an observed stage, or support for Avlsi together with an observed stage and support for at least one software-side component. A synthesized path that satisfies neither the high- nor mediumfeasibility conditions is classified as low feasibility. Thus, low feasibility indicates insufficient support under the current empirical evidence rather than impossibility of the attack. The complete medium- and low-feasibility rules are provided in Appendix A.

6 Feasibility Evaluation: We treat the generated paths as possible model paths rather than plausible attacks. To assess their feasibility, we add a separate evidence layer tied to the same model categories. We manually extract empirical evidence from Table 1, Table 2, Table 3, and Figure 3, including tool behavior, third-party tool invocation, shell-injection exposure, dependency exposure, CVEs, third-party library percentages, static-linking evidence, and library exposure across stages. We then map this evidence back to the existing Asw , Msw , and Avlsi categories. This keeps the feasibility analysis connected to the Prolog model rather than introducing a separate scoring vocabulary, and bridges the model-generated path space with the empirical observations from our tool analysis. The second pass evaluates the feasibility of the synthesized attack paths using evidence collected through the empirical analysis in Section 4. We encode the empirical observations as evidence facts and map them to the corresponding Asw , Msw , and Avlsi categories, while separately recording the VLSI design stages observed in our analysis. At the category level, high denotes strong empirical support, medium denotes partial or indirect support, and low denotes insufficient support

Synthethized Threat Model

Having described the abstract model to evaluate attacks, we instantiate the model using existing data and research to answer RQ2.

6.1

Model Instantiation

Having described the abstract model to evaluate attacks, we input data from the literature to the model to answer RQ2. We identified classes from literature for all of Asw , Msw , Avlsi , S, and O to instantiate a model using peer-reviewed attack information. This allows us to build attack paths from well-established data that can ultimately aid in answering RQ2. Table 4 outlines the sources and the types of information provided. The extracted vectors were normalized into 7 Asw categories and 8 Avlsi classes; the associated software-side mechanisms were consolidated into 8 Msw capability classes. We utilize the evidence of Section 4 to enrich the feasibility analysis. The resulting evidence set contains 50 evidence facts and 40 evidence-to-category mappings. 9

Table 4: Sources used to instantiate the VLSI-SWSC model. Source

Reference

Data Type

Class Count

Ohm et al. Gokkaya et al. Gu et al. Ladisa et al. Liu et al. Pundir et al. Tehranipoor et al. Tehranipoor et al. Xiao et al.

[79] [47] [49] [62] [65] [84] [104] [106] [120]

SWSC attack vectors SWSC attack vectors SWSC attack vectors SWSC attack vectors VLSI attack vectors VLSI attack vectors VLSI attack vectors VLSI attack vectors VLSI attack vectors

17 15 12 51 15 20 8 26 11

6.2

Source Code: The Source Code layer encompasses techniques targeting developer actions, repository configuration, contributor access, third-party inclusion, and static code risk detection. Multiple strategies (S1–S5) from prior work (see Appendix) attempt to mitigate supply chain threats at this stage. Code Changes (S1): Techniques such as commit signature enforcement, threshold approvals, and reviewer bypass prevention [1, 35, 55, 57, 79, 121] aim to block unauthorized or stealthy code insertions. These strategies directly address A p,11 and partially address A p,1 , A p,2 , A p,3 , and A p,4 by hardening the commit workflow. However, they offer minimal protection against A p,13 , A p,14 , A p,15 , and A p,16 or A p,8 , A p,9 , and A p,10 , which may occur post-merge through tool misuse or flawed design artifacts. See S1 in Appendix. Repository Management (S2): Trust-enhancing mechanisms such as sigstore signing, per-package repository delegation, and role separation [73, 74, 78] help verify repository authenticity and mitigate takeover risks. These efforts contribute to A p,11 resilience but lack runtime enforcement, leaving A p,12 and A p,13 , A p,14 , A p,15 , and A p,16 under-addressed. See S2 in Appendix. Contribution Access (S3): CI-based access control, onboarding filters, and change logging [13, 32, 117] improve contributor vetting and traceability, relevant to A p,11 and A p,12 . Still, these rely on pre-deployment enforcement and offer limited reach into A p,8 , A p,9 , and A p,10 (faulty or unavailable designs) or A p,13 and A p,14 (tool disruption), which involve unintended behaviors post-contribution. See S3 in Appendix. Third Party (S4): Community-scale protections like SBOM mandates and cross-project trust policies [118, 119] help govern external code inclusion. These mitigate A p,11 and A p,12 when third-party components are involved but do not explicitly trace downstream runtime failures or dynamic misbehavior, such as A p,8 , A p,9 , A p,10 , A p,13 , and A p,14 . See S4 in Appendix. Code Risks (S5): LLM-driven tools for vulnerability discovery and malware pattern detection [7, 124] target latent flaws in committed code. While promising for identifying security weaknesses that may enable information leakage or malicious design modification, these methods lack guarantees for timing-based exfiltration or environment-specific failures, thus providing only partial mitigation for information leakage, design tampering, or design-flow disruption. See S5 in Appendix.

Model Derived Attack Paths

Applying these rules to the 717 synthesized attack paths results in 60 high-feasibility attacks, 346 medium-feasibility attacks, and 311 low-feasibility attacks. These classifications quantify the degree of empirical support for modelgenerated possible attacks and do not constitute experimental validation of all identified attacks. Although hardware Trojan/backdoor attacks form the largest class in the synthesized space with 216 paths, the 60 high-feasibility paths are concentrated in access abuse/system disruption (32 paths) and design tampering/malicious modification (28 paths). All 60 originate from build/toolchain compromise or vulnerability/configuration exploitation and span multiple VLSI design stages from HLS through physical verification and signoff. The high-feasibility paths affect integrity and availability equally, with 30 paths each. The complete attack-category definitions, evidence mappings, feasibility rubric, and the 60 high-feasibility paths are provided in Appendix 5. The complete set of 717 synthesized attack paths and their classifications is available in the accompanying Open Science artifact.

7

Attack & Defense Analysis

This section presents a systematic evaluation of our software supply chain attacks to understand how effectively existing defenses mitigate them across the VLSI design process (see Appendix A for full rubric definitions). To evaluate the coverage of existing defenses against VLSI SWSC attacks, we adopt a systematized mapping strategy grounded in the CIS software supply chain security guide. We align each CIS-based mitigation domain with published academic and industry techniques, grouped and encoded as strategy codes (S1–S147).This section walks through each mitigation category row by row, identifying relevant S-codes, their supporting literature, and the rationale for their suitability against the proposed VLSI SWSC attack vector. Table 5 shows the CIS based mitigation mapping across VLSI SWSC attacks.

Build Pipelines The Build Pipelines layer secures compilation and integration workflows. Strategies S6–S9 target reproducibility, build isolation, and CI/CD hardening (Appendix). Build Environment (S6): Reproducible builds and deterministic patching [19, 43, 88] defend against A p,11 and reduce A p,1 –A p,4 risks, but do not detect A p,12 or A p,8 –A p,10 , nor address runtime degradation in A p,13 –A p,16 . Build Worker (S7): Worker isolation and sandboxing [39] 10

limit attacker persistence. While effective against build-time tampering (A p,11 ), they do not monitor generated artifacts for malicious logic or design modification (A p,1 , A p,2 , A p,3 , and A p,4 ) or compromised flow/build-script behavior (A p,12 ). Pipeline Instructions (S8): Scripting hardening and CI/CD control flows [24, 99] help disrupt attacker-triggered builds (A p,11 and A p,12 ), but lack runtime or testing enforcement, thus under-addressing A p,8 , A p,9 , and A p,10 (faulty or unavailable designs) as well as A p,13 , A p,14 , A p,15 , and A p,16 (tool or flow disruption). Pipeline Integrity (S9): Policy-as-code and artifact logging [38, 109] strengthen build auditability. While for traceability, these strategies are retrospective and insufficient for dynamic threats like testing flaws (A p,8 , A p,9 , and A p,10 ) or performance and flow sabotage (A p,15 and A p,16 ).

verified artifact is internally compromised or misused in a flow script (A p,12 , A p,13 , and A p,14 ).

8

Threat Model Evaluation: Case Studies

Finally, we evaluate our VLSI-SWSC attack taxonomy on a reference implementation of a VLSI design flow. All experiments were conducted in a controlled laboratory environment running Ubuntu 24.04.1 LTS on an x86-64 system equipped with a 13th Gen Intel Core i7-13700K processor and 32 GB of RAM. We implement three attack paths synthesized by our taxonomy model and separately discuss one additional taxonomy-derived scenario as speculative. The following describes each case study and its corresponding synthesized attack path. S1: P376 – Build/Toolchain Compromise Leading to Information Leakage: P376 is characterized by Asw : build/toolchain compromise, Msw : build/toolchain execution control, Avlsi : information leakage/asset exposure, S: logic synthesis, and O: confidentiality. In this case study, we instantiate P376 using Yosys at the logic-synthesis stage. Yosys relies on the third-party zlib library to decompress compressed design files (e.g., .v.gz). We created a malicious version of zlib that hijacks the gzread() function. When Yosys executes with the compromised library, the malicious function intercepts reads of the Verilog design, copies the design data, and writes it to an external file. The attack therefore exposes the circuit design during logic synthesis, resulting in information leakage and loss of IP confidentiality.

Dependencies The Dependencies layer mitigates risks from external packages via detection, validation, and hygiene enforcement (Appendix). Third Party Packages (S10, S15, S19): Static diffing, behavioral modeling, and typo-squatting detection [44, 63, 102] address malicious or misused dependencies (A p,11 , A p,1 , A p,2 , A p,3 , and A p,4 ) through structural and naming anomaly detection. However, these strategies often rely on known patterns or blacklists, offering limited protection against novel runtime exfiltration scripts (A p,12 ) or latent availability degraders (A p,13 , A p,14 , A p,15 , and A p,16 ). Validate Packages (S11–S18): Advisory mapping [37, 76], silent patch tracking [75], and freshness scoring [89, 125] verify dependency safety and reduce legacy or residual information leakage, design vulnerabilities that may enable malicious design modificationmpering, or design-flow disruption, but do not prevent malicious code injection or intentional flow degradation. CVE-based tools may miss backdoored yet functional packages. Overall, dependency validation improves hygiene but lacks semantic inspection of functional intent, making it partially effective against integrity and minimally effective against confidentiality or availability threats.

S2: P703 – Configuration-Based Flow Disruption Affecting Availability: P703 is characterized by Asw : vulnerability/configuration exploitation, Msw : vulnerability/configuration-based control, Avlsi : access abuse/system disruption, S: logic synthesis, and O: availability. In this case study, we instantiate P703 using Yosys at the logic-synthesis stage. Yosys uses the standard C library to perform file operations, including the fopen() function for accessing Verilog input files. We created a malicious shared object that overrides fopen() and loaded it through the LD_PRELOAD mechanism (e.g., to mimic the malicious dlopen hijack from the xz-utils compromise). The malicious function denies access to the intended RTL file and redirects the tool to a fake or empty input file. This configuration-based control disrupts synthesis by preventing Yosys from processing the required RTL artifact. As a result, the expected synthesis output is missing or invalid, disrupting subsequent stages of the VLSI design flow and affecting availability.

Artifacts This category focuses on verifying, tracking, and restricting access to artifacts to preserve integrity and traceability. Verification (S20) Tools Memptec [50] leverage anomaly detection to flag malicious packages. While effective against backdoored tools (A p,11 ) or packaging-based obfuscation, they cannot analyze code intent, limiting their efficacy against flow scripts (A p,12 ) or availability threats (A p,15 and A p,16 ). Access to Artifacts (S21), Package Registries (S22), Origin Traceability (S23). These strategies enhance provenance and access control. SLSA-aligned artifact forensics [80] and public registry signing [94] provide origin authentication and tamper resistance (A p,11 , A p,1 , A p,2 , A p,3 , and A p,4 ). Argo-SLSA pipelines [107] further bind build processes to verified sources. However, they offer little protection once a 11

S3: P616 – Configuration-Based Design Tampering Affecting Integrity: P616 is characterized by Asw : vulnerability/configuration exploitation, Msw : vulnerability/configuration-based control, Avlsi : design tampering/malicious modification, S: logic synthesis, and O: integrity. In this case study, we instantiate P616 using Yosys at the logic-synthesis stage. We created a malicious shared object that overrides the read() function used during Verilog file processing. When Yosys reads the design input, the malicious function modifies the input stream by inserting an additional line, such as invalid_gate xyz();, before the legitimate data is processed. This configuration-based control modifies the design artifact during synthesis, resulting in a malformed netlist containing invalid components. The attack therefore tampers with the design and violates its integrity, while also causing downstream timing, placement, and layout stages to fail. S4: P624 – Speculative Configuration-Based Timing Manipulation Affecting Integrity: P624 is characterized by Asw : vulnerability/configuration exploitation, Msw : vulnerability/configuration-based control, Avlsi : design tampering/malicious modification, S: static tim-

G #

G #

G #

G #

G #

G #

G #

#

#

G # G #

G # G # G #

G # G # G #

G #

G #

G #

G #

G #

G #

G # G # G # G # G # G # G #

G # G # G # G # G # # #

G # G # G # G # G # # #

G # G #

G #

G #

G #

G #

G #

G #

G #

G # G # G # G # G # G # G #

G # G # G # G # G # G # G #

G #

G #

G #

#

G #

G #

G #

G #

G #

#

#

#

#

G #

G # #

G # G # G # G # G # G # G # #

G # # #

G # #

G # G # G # G # G # G # G # #

G # G #

G # #

G # G # G # G # G # G # G # G # G # #

G #

G # #

G # G # G # G # G # G # G # G # G # #

G #

G # #

G # G # G # G # G # G # G # G # G # G #

A p,16

G #

#

A p,15

#

#

A p,14

G #

#

A p,13

G #

G #

A p,11

G #

#

A p,12

G #

A p,10

G #

A p,9

G #

A p,7

A p,5

G #

A p,8

A p,4

G #

A p,6

A p,3

Sample References Strategy (S Codes) [1, 2, 35, 55, 57, 62, 79, 83, 95, 116, S1–S11 121] Repository Manage- [73, 74, 78] S12–S27 ment Contribution Access [13, 32, 55, 117] S28–S50 Third Party [117–119] S41–S55 Code Risks [7, 11, 17, 59, 66, 124, 127, 130] S56–S62 Build Environment [19, 43, 88] S63–S71 Build Worker [39] S72–S74 Pipeline Instructions [24, 48, 73, 99] S75–S85 Pipeline Integrity [36, 38, 39, 109, 110] S86–S88 Third Party Packages [8, 38, 44, 123, 126, 129] S89–S111 Validate Packages [4, 27, 30, 31, 124, 128] S112–S118 Verification [50] S119–S125 Access to Artifacts [80, 100] S126–S130 Package Registries [94] S131–S135 Origin Traceability [107] S136–S140 Deployment Configu- [26, 86, 91, 115] S141–S144 ration Deployment Environ- [42, 45] S145–S147 ment

A p,2

CIS Technique Source Code

A p,1

Table 5: CIS-Based Mitigation Mapping Across VLSI Software Supply Chain Threats. Symbols: = Fully Met, # G= Partially Met, #= Not Met. Attack-Path Classes: A p,1 = {P614, P616}; A p,2 = {P334, P336, P338}; A p,3 = {P618, P620, P622}; A p,4 = {P340, P342, P344, P346}; A p,5 = {P615, P617}; A p,6 = {P423, P425}; A p,7 = {P427, P429, P431, P435}; A p,8 = {P420, P422, P424, P426}; A p,9 = {P619, P621, P623, P625, P627}; A p,10 = {P428, P430, P432, P436}; A p,11 = {P333, P335, P337, P339}; A p,12 = {P341, P343, P345}; A p,13 = {P700, P702, P704, P706}; A p,14 = {P419, P421}; A p,15 = {P430, P432, P436}; A p,16 = {P701, P703, P705, P707, P708, P709, P710, P711, P712, P713, P716, P717, P624, P626}. Full Attack Paths: and S-Codes: Full legend (S1–S147) See Appendix A.

#

#

#

#

#

#

G #

G #

G #

G #

G #

G #

G #

G #

G #

G #

#

G #

#

#

#

#

#

G # G # G # G # G # G # G # G # G # G # G # G # G #

#

G # G # G # G # G # G # G # G # G # G # G #

# # # #

G # #

G # G # G # G # G # #

G #

# # # #

G # #

G # G # G # G # G # G # #

# # # #

G # #

G # G # G # G # G # G # G #

# # # #

G # #

G # G # G # G # G # #

G #

ing analysis, and O: integrity. In this speculative case study, we consider an attack on the static timing analysis stage enabled by third-party library dependencies in VLSI timing tools. Tools such as OpenTimer, OpenSTA, and OpenLane rely on scripting and data-processing libraries that can expose software-side attack surfaces. An attacker could load a malicious parsing library that intercepts functions responsible for processing timing values. By modifying the returned timing constraints, the compromised library could cause the timing tool to incorrectly accept violated setup or hold constraints as valid. This configuration-based control could therefore manipulate timing-analysis results, allowing incorrect timing information to propagate through signoff and compromising the design.

9

Related Work

The field of Hardware Supply Chain Security has been established in research and development. This area of research focuses on detecting and preventing malicious hardware changes (i.e., Trojans) during manufacturing as well as preventing the theft of IP when outsourcing manufacturing to a third party — who is generally overseas. To avoid malicious 12

tampering in hardware supply chains, various approaches have been proposed. Hardware designs face increasing threats from side-channel attacks, logic-locking vulnerabilities, fault injection, hardware Trojans, and IP piracy. Recent research focuses on identifying and mitigating these hardware supply-chain vulnerabilities across abstraction levels, from RTL to gate level. [96], cross talk [64], and electromagnetic leakages in complex computing environments [12]. SCAR [96] uses graph neural networks on RTL-level control-data flow graphs for pre-silicon identification and mitigation of power side-channel vulnerabilities, achieving high localization accuracy (94.49 %), with automated code-level mitigations generated by large language models (LLMs). This work [64] demonstrates a crosstalkbased quantum side channel attack in multi-tenant NISQ environment, using graph learning to identify victim circuits from CNOT gate signatures with 85.7 % accuracy. Recent studies have also focused on detecting hardware Trojans and evaluating the resilence of logic locking and obfuscation techniques, revealing practical limitations in securing layouts against reverse engineering and SAT based attacks. Additionally, [71] transforms IC layouts into graphs and applies graph neural networks to classify functional regions, detecting and localizing hardware trojans based on low confidence predictions without a golden IC. Further, [61] presents a large scale red versus blue team evaluation of fabrication-time hardware Trojan insertion, demonstrating that even optimized 7nm IC layouts with strict design constraints remain vulnerable, and releases a comprehensive benchmarking framework for continued research. Moreover, [53] demonstrates that current logic locking techniques based on the corrupt-and-correct (CAC) model are vulnerable to structural attacks enbaled by EDA tools optimizations, introducing the SPI attack which breaks all tested CAC schemes with 100 % success, calling for co-design of secure locking and EDA flows. Further, [52] enhances stripped functionality logic locking (SFLL) by proposing multi-objective node selection strategies that improve output corruption and coverage, with MinCn showing superior scalability and effectiveness for larger key sizes. Further, [33] work investigates clock signal obfuscation as a logic locking primitive showing that while clock based schemes offer limited security per overhead, targeted designs may benefit from specialized de-obfuscation resistance. Recent studies expose key vulnerabilities in the hardware IP lifecycle, including SAT-based de-obfuscation, insecure provisioning, and unverified protection mechanisms. Delay-locked circuits remain susceptible to TimingSAT attacks, prompting the proposal of a stripped-functionality locking scheme for enhanced resilience [22]. SAP introduces a lightweight hardware IP to enable secure asset provisioning and SoC authentication in untrusted environments [93]. Despite advances in CAD-driven IP protection (e.g., obfuscation, watermarking), scalability and robustness issues persist under globalized supply chains [14]. Architectural oversights—not

physical tampering—are shown to underlie most PCB-level attacks, emphasizing the role of sound design principles [54]. Logic locking and trust verification continue to be key defenses against Trojans and IP theft [92], while IV&V frameworks ensure these protections hold under real-world EDA flows [101]. Recent work explores pre-silicon security verification and SoC attack models using formal and learning-based approaches. RTL-ConTest applies RTL-level concolic testing to detect processor- and peripheral-level vulnerabilities in open-source SoCs. [70], while Re-Pen and RL-TPG employ reinforcement learning to generate optimized test patterns for automated vulnerability discovery under limited design knowledge [3]. FuncTeller reveals that eFPGA redaction does not guarantee confidentiality, recovering IP functionality through black-box queries with 85% accuracy [51]. HUnTer systematically verifies system-level vulnerabilities by linking formal threat models to exploitable instruction sequences on SoC architectures [87]. Complementarily, formal RTL fault-injection techniques uncover early-stage vulnerabilities in control logic without relying on gate-level representations [111]. Clock gating has also been explored for IP protection through programmable integrated clock gate insertion at RTL [105]. Finally, studies expose software-based side-channel attacks—using power telemetry interfaces and CPU frequency throttling—on Apple SoCs, enabling AES key recovery from user space and challenging assumptions about isolation in modern processors [25].

10

Conclusion

This paper presented a systematic analysis of SWSC vulnerabilities within the VLSI design flow, demonstrating how software-level attacks can compromise hardware security. Through an empirical analysis of VLSI software suites, we characterized their software composition, assessed tool interactions, and evaluated their security features and operating privileges. Building on these insights, we developed a VLSI-SWSC attack taxonomy that links software-side attacks and capabilities to VLSI-side attacks, design stages, and security outcomes. The taxonomy further informed the construction of our threat model, capturing potential security outcomes arising from compromised software components. Finally, we evaluated representative taxonomy-derived attacks on an open-source VLSI design flow by implementing three attack scenarios and separately analyzing one additional speculative scenario. We hope that, through this, a first bridge into mapping the security posture of VLSI software suites from SWSC attacks is created.

13

Ethical Considerations

instructions are available in our anonymized GitHub repository: https://anonymous.4open.science/r/VLSI-E052

This section discusses the ethical considerations of analyzing software supply chain vulnerabilities in VLSI design flow. Our work focuses on empirical analysis of VLSI software suites and identified attacks that can be carried out from a software supply chain prespective and as a result create software-only attack taxonomy. We did the evaluation of these software-only attacks in a controlled environment.

References [1] Ahmed Akinsola and Abdullah Akinde. Enhancing software supply chain resilience: Strategy for mitigating software supply chain security risks and ensuring security continuity in development lifecycle. arXiv preprint arXiv:2407.13785, 2024.

• Risks and benefits from identified software supply-chain weaknesses: Our analysis reveals that untrusted open source software dependencies and tool interactions in VLSI design flows can enable software-only attacks affecting the confidentiality, integrity, and availability of the design process. These risks are clearly defined threat model and demonstrated only in controlled environments using open-source tools and synthetic designs.The primary benefit of this analysis is to expose previously underexplored software-driven risks in VLSI pipelines and to inform prioritization and mitigation by tool developers and practitioners.

[2] Sana Al-Farsi, Muhammad Mazhar Rathore, and Spiros Bakiras. Security of blockchain-based supply chain management systems: challenges and opportunities. Applied Sciences, 11(12):5585, 2021. [3] Hasan Al Shaikh, Shuvagata Saha, Kimia Zamiri Azar, Farimah Farahmandi, Mark Tehranipoor, and Fahim Rahman. Re-pen: Reinforcement learning-enforced penetration testing for soc security verification. IEEE Transactions on Very Large Scale Integration (VLSI) Systems, 2024. [4] Mahmoud Alfadel, Diego Elias Costa, Emad Shihab, and Bram Adams. On the discoverability of npm vulnerabilities in node.js projects. ACM Transactions on Software Engineering and Methodology, 32(4):1–27, 2023.

• Risks and benefits from the existence of this work: Thsi work provides a systematic taxonomy and threat model for software supply chain risks in VLSI design flow. While such analyses could be misused, we mitigate this risk by avoiding release of exploit code or weaponized artifacts and by reporting attacks at an abstract level.

[5] Dinesh Annayya. riscduino, 2021. URL: https:// github.com/dineshannayya/riscduino.

• Responsible Disclosure As part of this work, we have engaged with relevant VLSI software vendors regarding the security issues identified in our analysis. Our goal is to responsibly communicate potentially actionable findings and provide vendors an opportunity to review them before broader disclosure. We avoid releasing sensitive implementation details that could enable misuse and limit public reporting to information necessary to support the scientific findings of this work.

[6] AnySilicon. The ultimate guide to open source eda tools, n.d. URL: https://anysilicon.com/theultimate-guide-to-open-source-eda-tools/. [7] Virendra Ashiwal, Soeren Finster, and Abdallah Dawoud. Llm-based vulnerability sourcing from unstructured data. In 2024 IEEE European Symposium on Security and Privacy Workshops (EuroS&PW), pages 634–641. IEEE, 2024.

Open Science

[8] Frederick Barr-Smith, Tim Blazytko, Richard Baker, and Ivan Martinovic. Exorcist: Automated differential analysis to detect compromises in closedsource software supply chains. In Proceedings of the 2022 ACM Workshop on Software Supply Chain Offensive Research and Ecosystem Defenses, pages 51–61, 2022.

We implemented three end-to-end software supply chain attacks—P376, P703, and P616—using only open-source tools and libraries. In P376, we hijack gzread() in libz.so to leak compressed Verilog designs via dynamic preloading (LD_PRELOAD), demonstrating build/toolchain compromise leading to information leakage. In P703, we hook fopen() in glibc to silently substitute empty or fake RTL input files, causing configuration-based flow disruption that affects availability. In P616, we use a custom wrapper on read() in libc.so to inject malformed gates, resulting in configuration-based design tampering that affects integrity. All attack implementations, input examples, and reproduction

[9] Michael Bartock et al. Strategies for the integration of software supply chain security in devsecops ci/cd pipelines. Technical Report NIST SP 800-204D, National Institute of Standards and Technology, 2022. URL: https://nvlpubs.nist.gov/nistpubs/ SpecialPublications/NIST.SP.800-204D.pdf. 14

[10] Kanad Basu, Samah Mohamed Saeed, Christian Pilato, Mohammed Ashraf, Mohammed Thari Nabeel, Krishnendu Chakrabarty, and Ramesh Karri. Cadbase: An attack vector into the electronics supply chain. ACM Transactions on Design Automation of Electronic Systems (TODAES), 24(4):1–30, 2019.

for open and closed source software. Software Quality Journal, 31(3):687–719, 2023. [20] Cadence. Vlsi fundamentals: A practical approach education kit, n.d. URL: https://www.cadence.com/ en_US/home/company/cadence-academicnetwork/educators/vlsi-fundamentals.html.

[11] Giacomo Benedetti, Luca Verderame, and Alessio Merlo. Alice in (software supply) chains: risk identification and evaluation. In International Conference on the Quality of Information and Communications Technology, pages 281–295. Springer, 2022.

[21] INC CADENCE DESIGN SYSTEMS. Cadence design systems, inc. annual report on form 10k for the fiscal year ended december 31, 2024, 2025. URL: https://www.cadence.com/content/ dam/cadence-www/global/en_US/documents/ company/investors/form-10-k-2024.pdf.

[12] Md Kawser Bepary, Tao Zhang, Jingbo Zhou, Fahim Rahman, Farimah Farahmandi, and Mark Tehranipoor. Towards efficient gate-level electromagnetic sidechannel leakage modeling and vulnerability assessment. Journal of Hardware and Systems Security, pages 1–14, 2025.

[22] Abhishek Chakraborty, Yuntao Liu, and Ankur Srivastava. Evaluating the security of delay-locked circuits. IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems, 40(4):608–619, 2020.

[13] Som Sekhar Bhattacharyya and Saurabh Kumar. Study of deployment of “low code no code” applications toward improving digitization of supply chain management. Journal of Science and Technology Policy Management, 14(2):271–287, 2023.

[23] Abhishek Chakraborty, Ankit Mondai, and Ankur Srivastava. Hardware-assisted intellectual property protection of deep learning models. In 2020 57th ACM/IEEE Design Automation Conference (DAC), pages 1–6. IEEE, 2020.

[14] Swarup Bhunia, Amitabh Das, Saverio Fazzari, Vivian Kammler, David Kehlet, Jeyavijayan Rajendran, and Ankur Srivastava. Hardware ip protection against confidentiality attacks and evolving role of cad tool. In Proceedings of the 41st IEEE/ACM International Conference on Computer-Aided Design, pages 1–8, 2022.

[24] Ramaswamy Chandramouli, Frederick Kautz, and Santiago Torres-Arias. Strategies for the integration of software supply chain security in devsecops ci/cd pipelines. Special Publication 800-204D, National Institute of Standards and Technology (NIST), 2024. Retrieved February 2024 from https://nvlpubs.nist.gov/nistpubs/ SpecialPublications/NIST.SP.800-204D.pdf.

[15] Swarup Bhunia and Mark Tehranipoor. Hardware security: a hands-on learning approach. Morgan Kaufmann, 2018.

[25] Nikhil Chawla, Chen Liu, Abhishek Chakraborty, Igor Chervatyuk, Thais Moreira Hamasaki, Ke Sun, and Henrique Kawakami. Uncovering software-based power side-channel attacks on apple m1/m2 systems. In Proceedings of the 61st ACM/IEEE Design Automation Conference, pages 1–6, 2024.

[16] Anton Blanchard. microwatt-caravel, 2022. URL: https://github.com/antonblanchard/ microwatt-caravel. [17] Biagio Boi, Christian Esposito, and Sokjoon Lee. Smart contract vulnerability detection: The role of large language model (llm). ACM SIGAPP applied computing review, 24(2):19–29, 2024.

[26] Michele Chiari, Michele De Pascalis, and Matteo Pradella. Static analysis of infrastructure as code: a survey. In 2022 IEEE 19th International Conference on Software Architecture Companion (ICSA-C), pages 218–225. IEEE, 2022.

[18] Jon Boyens and Angela Smith. Nist special publication nist sp 800-161r1 cybersecurity supply chain risk management practices for systems and organizations, 2022. URL: https://nvlpubs.nist.gov/nistpubs/ SpecialPublications/NIST.SP.800-161r1.pdf.

[27] CloudSecurityAlliance. gsd-database, 2021. URL: https://github.com/cloudsecurityalliance/ gsd-database.

[19] Simon Butler, Jonas Gamalielsson, Björn Lundell, Christoffer Brax, Anders Mattsson, Tomas Gustavsson, Jonas Feist, Bengt Kvarnström, and Erik Lönroth. On business adoption and use of reproducible builds

Efabless announces the [28] Efabless Corporation. release of the openlane 2 development platform, transforming custom silicon design flows, 2024. URL: https://www.globenewswire.com/news15

[38] William Enck, Yasemin Acar, Michel Cucker, Alexandros Kapravelos, Christian Kastner, and Laurie Williams. S3c2 summit 2023-06: Government secure supply chain summit. https://arxiv.org/abs/ 2308.06850, June 2023. arXiv:2308.06850.

release/2024/04/18/2865597/0/en/efablessannounces-the-release-of-the-openlane-2development-platform-transforming-customsilicon-design-flows.html. [29] National Counterintelligence and Security Center. Solarwinds orion software supply chain attack, 2021. URL: https://www.dni.gov/files/ NCSC/documents/SafeguardingOurFuture/ SolarWinds%20Orion%20Software%20Supply% 20Chain%20Attack.pdf.

[39] William Enck and Laurie Williams. Top five challenges in software supply chain security: Observations from 30 industry and government organizations. IEEE Security & Privacy, 20(2):96–100, 2022. doi: 10.1109/MSEC.2022.3142338.

[30] Joel Cox, Eric Bouwers, Marko van Eekelen, and Joost Visser. Measuring dependency freshness in software systems. In 2015 IEEE/ACM 37th IEEE International Conference on Software Engineering, Volume 2, pages 109–118. IEEE, 2015. doi:10.1109/ ICSE.2015.140.

[40] Johan Euphrosine. Build open silicon with google, 2022. URL: https: //opensource.googleblog.com/2022/05/Build% 20Open%20Silicon%20with%20Google.html. Cis software sup[41] Center for Internet Security. ply chain security guide, 2022. URL: https: //www.cisecurity.org/insights/white-papers/ cis-software-supply-chain-security-guide.

[31] Roland Croft, M. Ali Babar, and M. Mehdi Kholoosi. Data quality for software vulnerability datasets. In 2023 IEEE/ACM 45th International Conference on Software Engineering (ICSE), pages 121–133. IEEE, 2023.

Is continuous deployment too risky? [42] FORTR. security concerns and mitigations. https: //www.tripwire.com/state-of-security/ continuous-deployment-too-risky-securityconcerns-and-mitigations, 2025.

[32] Jun Cui. The role of devops in enhancing enterprise software delivery success through r&d efficiency and source code management. arXiv preprint arXiv:2411.02209, 2024.

[43] Marcel Fourné, Dominik Wermke, William Enck, Sascha Fahl, and Yasemin Acar. It’s like flossing your teeth: On the importance and challenges of reproducible builds for software supply chain security. In 44th IEEE Symposium on Security and Privacy (IEEE S&P). IEEE, 2023.

[33] Rajesh Datta, Guangwei Zhao, Kanad Basu, and Kaveh Shamsi. A security analysis of circuit clock obfuscation. Cryptography, 6(3):43, 2022. [34] Ghada Dessouky, David Gens, Patrick Haney, Garrett Persyn, Arun Kanuparthi, Hareesh Khattri, Jason M Fung, Ahmad-Reza Sadeghi, and Jeyavijayan Rajendran. {HardFails}: Insights into {SoftwareExploitable} hardware bugs. In 28th USENIX Security Symposium (USENIX Security 19), pages 213–230, 2019.

[44] Fabian Niklas Froh, Matías Federico Gobbi, and Johannes Kinder. Differential static analysis for detecting malicious updates to open source packages. In Proceedings of the 2023 Workshop on Software Supply Chain Offensive Research and Ecosystem Defenses, pages 41–49, 2023.

[35] Ruian Duan, Omar Alrawi, Ranjita Pai Kasturi, Ryan Elder, Brendan Saltaformaggio, and Wenke Lee. Towards measuring supply chain attacks on package managers for interpreted languages. arXiv preprint arXiv:2002.01139, 2020.

[45] Chinmay Gaikwad. Ci/cd best practices, 2026. URL: https://www.harness.io/blog/best-practicesfor-awesome-ci-cd. [46] Vasudev Gohil, Mark Tressler, Kevin Sipple, Satwik Patnaik, and Jeyavijayan Rajendran. Games, dollars, splits: A game-theoretic analysis of split manufacturing. IEEE Transactions on Information Forensics and Security, 16:5077–5092, 2021.

[36] Trevor Dunlap, Yasemin Acar, Michel Cucker, William Enck, Alexandros Kapravelos, Christian Kastner, and Laurie Williams. S3c2 summit 2023-02: Industry secure supply chain summit. http://arxiv.org/abs/ 2307.16557, 2023. arXiv:2307.16557.

[47] Betul Gokkaya, Leonardo Aniello, and Basel Halak. Software supply chain: A taxonomy of attacks, mitigations and risk assessment strategies. Journal of Information Security and Applications, 97:104324, 2026.

[37] Trevor Dunlap, Elizabeth Lin, William Enck, and Bradley Reaves. Vfcfinder: Seamlessly pairing security advisories and patches. https://arxiv.org/ abs/2311.01532, 2023. arXiv:2311.01532. 16

[48] Yacong Gu, Lingyun Ying, Huajun Chai, Chu Qiao, Haixin Duan, and Xing Gao. Continuous intrusion: Characterizing the security of continuous integration services. In 2023 IEEE Symposium on Security and Privacy (SP), pages 1561–1577. IEEE, 2023.

interview study of software signing for supply chain security. arXiv preprint arXiv:2406.08198, 2024. [58] Rahul Kande, Addison Crump, Garrett Persyn, Patrick Jauernig, Ahmad-Reza Sadeghi, Aakash Tyagi, and Jeyavijayan Rajendran. {TheHuzz}: Instruction fuzzing of processors using {Golden-Reference} models for finding {Software-Exploitable} vulnerabilities. In 31st USENIX Security Symposium (USENIX Security 22), pages 3219–3236, 2022.

[49] Yacong Gu, Lingyun Ying, Yingyuan Pu, Xiao Hu, Huajun Chai, Ruimin Wang, Xing Gao, and Haixin Duan. Investigating package related security threats in software registries. In 2023 IEEE Symposium on Security and Privacy (SP), pages 1578–1595. IEEE, 2023.

[59] Evangelos Katsadouros, Charalampos Z. Patrikakis, and George Hurlburt. Can large language models better predict software vulnerability? IT Professional, 25(3):4–8, 2023.

[50] Sreeparna Halder, Shirshendu Routh, Rahul Pathak, Ashutosh Sharma, and Supratik Chakraborty. Memptec: Malicious package detection using metadata information. arXiv preprint arXiv:2402.07444, 2024. URL: https://arxiv.org/abs/2402.07444.

[60] Jan-Peter Kleinhans. The eda chokepoint dilemma? openness, oligopolies, and china’s ecosystem. Technical report, UC Institute on Global Conflict and Cooperation, 2022. Working Paper, Accessed: 2025-04-14. URL: https: //ucigcc.org/wp-content/uploads/2022/12/ kleinhans-working-paper_-IGCC-2022-1.pdf.

[51] Zhaokun Han, Mohammed Shayan, Aneesh Dixit, Mustafa Shihab, Yiorgos Makris, and Jeyavijayan JV Rajendran. {FuncTeller}: How well does {eFPGA} hide functionality? In 32nd USENIX Security Symposium (USENIX Security 23), pages 5809–5826, 2023.

[61] Johann Knechtel, Mohammad Eslami, Peng Zou, Min Wei, Xingyu Tong, Binggang Qiu, Zhijie Cai, Guohao Chen, Benchao Zhu, Jiawei Li, et al. Trojan insertion versus layout defenses for modern ics: Redversus-blue teaming in a competitive community effort. IACR Transactions on Cryptographic Hardware and Embedded Systems, 2025(1):37–77, 2025.

[52] Zhaokun Han, Muhammad Yasin, and Jeyavijayan JV Rajendran. Multi-objective strategies for strippedfunctionality logic locking. In 2020 IEEE International Symposium on Circuits and Systems (ISCAS), pages 1–5. IEEE, 2020. [53] Zhaokun Han, Muhammad Yasin, and Jeyavijayan JV Rajendran. Does logic locking work with {EDA} tools? In 30th USENIX Security Symposium (USENIX Security 21), 2021.

[62] Piergiorgio Ladisa, Henrik Plate, Matias Martinez, and Olivier Barais. Sok: Taxonomy of attacks on open-source software supply chains. In 2023 IEEE Symposium on Security and Privacy (SP), pages 1509– 1526. IEEE, 2023.

[54] Jacob Harrison, Nathan Jessurun, and Mark Tehranipoor. Sok: A security architect’s view of printed circuit board attacks. arXiv preprint arXiv:2410.09993, 2024.

[63] Piergiorgio Ladisa, Merve Sahin, and Serena Elisa et al. Ponta. The hitchhiker’s guide to malicious third-party dependencies. In Workshop on Software Supply Chain Offensive Research and Ecosystem Defenses 2023, pages 65–74, 2023.

[55] Jan-Ulrich Holtgrave, Kay Friedrich, Fabian Fischer, Nicolas Huaman, Niklas Busch, Jan H. Klemmer, Marcel Fourné, Oliver Wiese, Dominik Wermke, and Sascha Fahl. Attributing open-source contributions is critical but difficult: A systematic analysis of github practices and their impact on software supply chain security, 2025.

[64] Ruixuan Li, Navnil Choudhury, Chaithanya Naik Mude, Sanjay Das, Preetham Chandra Tikkireddi, Swamit Tannu, and Kanad Basu. Crosstalk-induced side channel threats in multi-tenant nisq computers. In NDSS Symposium, San Diego, CA, USA, 2025.

[56] Eman Abu Ishgair, Marcela S Melara, and Santiago Torres-Arias. Sok: A defense-oriented evaluation of software supply chain security. arXiv preprint arXiv:2405.14993, 2024.

[65] Bao Liu and Gang Qu. Vlsi supply chain security risks and mitigation techniques: A survey. Integration, 55:438–448, 2016. [66] Zhihong Liu, Qing Liao, Wenchao Gu, and Cuiyun Gao. Software vulnerability detection with gpt and incontext learning. In 2023 8th International Conference

[57] Kelechi G Kalu, Tanya Singla, Chinenye Okafor, Santiago Torres-Arias, and James C Davis. An industry 17

on Data Science in Cyberspace (DSC), pages 229–236. IEEE, 2023.

[76] Truong Giang Nguyen, Thanh Le-Cong, Hong Jin Kang, Xuan-Bach D Le, and David Lo. Vulcurator: A vulnerability-fixing commit detector. In 30th ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering, pages 1726–1730, 2022.

[67] Stephen Magill. Introducing our 8th annual state of the software supply chain, 2022. URL: https: //www.sonatype.com/blog/8th-annual-stateof-the-software-supply-chain-report.

[77] Michael Nieles, Kelley Dempsey, and Victoria Yan Pillitteri. Nist special publication 800-12 revision 1 an introduction to information security, 2017. URL: https://nvlpubs.nist.gov/nistpubs/ SpecialPublications/NIST.SP.800-12r1.pdf.

[68] Ethan Mahintorabi, Johan Euphrosine, and Aaron Cunningham. Google funds open source silicon manufacturing shuttles for globalfoundries pdk, 2022. URL: https://opensource.googleblog.com/ 2022/10/announcing-globalfoundries-openmpw-shuttle-program.html.

[78] Sabato Nocera, Simone Romano, Massimiliano Di Penta, Rita Francese, and Giuseppe Scanniello. Software bill of materials adoption: A mining study from github. In 2023 IEEE International Conference on Software Maintenance and Evolution (ICSME), pages 39–49. IEEE, 2023.

[69] W. Maly. Computer-aided design for vlsi circuit manufacturability. Proceedings of the IEEE, 78(2):356–392, 1990. doi:10.1109/5.52217. [70] Xingyu Meng, Shamik Kundu, Arun K Kanuparthi, and Kanad Basu. Rtl-contest: Concolic testing on rtl for detecting security vulnerabilities. IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems, 41(3):466–477, 2021.

[79] Marc Ohm, Henrik Plate, Arnold Sykosch, and Michael Meier. Backstabber’s knife collection: A review of open source software supply chain attacks. In International Conference on Detection of Intrusions and Malware, and Vulnerability Assessment, pages 23– 43. Springer, 2020.

[71] Xingyu Meng, Abhrajit Sengupta, and Kanad Basu. A needle in the haystack: Inspecting circuit layout to identify hardware trojans. In 2024 25th International Symposium on Quality Electronic Design (ISQED), pages 1–8. IEEE, 2024.

[80] Marc Ohm, Arnold Sykosch, and Michael Meier. Towards detection of software supply chain attacks by forensic artifacts. In Proceedings of the 15th international conference on availability, reliability and security, pages 1–6, 2020.

[72] Samit S Miftah, Shamik Kundu, Austin Mordahl, Shiyi Wei, and Kanad Basu. Rtl-spec: Rtl spectrum analysis for security bug localization. In 2024 IEEE International Symposium on Hardware Oriented Security and Trust (HOST), pages 171–181. IEEE, 2024.

[81] Chinenye Okafor, Taylor R Schorlemmer, Santiago Torres-Arias, and James C Davis. Sok: Analysis of software supply chain security by establishing secure design properties. In ACM Workshop on Software Supply Chain Offensive Research and Ecosystem Defenses, 2022.

[73] Marina Moore, Trishank Karthik Kuppusamy, and Justin Cappos. Artemis: Defanging software supply chain attacks in multi-repository update systems. In Proceedings of the 39th Annual Computer Security Applications Conference (ACSAC ’23), pages 83– 97, New York, NY, 2023. ACM. doi:10.1145/ 3627106.3627129.

[82] The Volt Post. What is open source eda, growing importance, challenges and way ahead!, 2025. URL: https://thevoltpost.com/open-source-edatools-for-semiconductor-magic-vlsi/.

[74] Zachary Newman, John Speed Meyers, and Santiago Torres-Arias. Sigstore: Software signing for everybody. In Proceedings of the 2022 ACM SIGSAC Conference on Computer and Communications Security, pages 2353–2367, 2022.

[83] Piotr Przymus and Thomas Durieux. Wolves in the repository: A software engineering analysis of the xz utils supply chain attack. In 2025 IEEE/ACM 22nd International Conference on Mining Software Repositories (MSR), pages 91–102. IEEE, 2025.

[75] Son Nguyen, Thanh Trong Vu, and Hieu Dinh Vo. Vffinder: A graph-based approach for automated silent vulnerability-fix identification. In 2023 15th International Conference on Knowledge and Systems Engineering (KSE), pages 1–6. IEEE, 2023.

[84] Nitin Pundir, Sohrab Aftabjahani, Rosario Cammarota, Mark Tehranipoor, and Farimah Farahmandi. Analyzing security vulnerabilities induced by high-level synthesis. ACM Journal on Emerging Technologies in Computing Systems (JETC), 18(3):1–22, 2022. 18

[85] Yihang Qiu, Zengrong Huang, Simin Tao, Hongda Zhang, Weiguo Li, Xinhua Lai, Rui Wang, Weiqiang Wang, and Xingquan Li. Aieda: An opensource ai-aided design library for design-to-vector. IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems, 2025.

[95] Yijun Shen, Xiang Gao, Hailong Sun, and Yu Guo. Understanding vulnerabilities in software supply chains. Empirical Software Engineering, 30(1):20, 2025. [96] Amisha Srivastava, Sanjay Das, Navnil Choudhury, Rafail Psiakis, Pedro Henrique Silva, Debjit Pal, and Kanad Basu. Scar: Power side-channel analysis at rtl level. IEEE Transactions on Very Large Scale Integration (VLSI) Systems, 2024.

[86] Akond Rahman et al. Security smells in ansible and chef scripts: A replication study. arXiv preprint arXiv:1907.07159, 2019. URL: https://arxiv.org/ abs/1907.07159.

[97] Synopsys. Open source security and risk analysis report. Technical report, Synopsys, 2023. Technical report. URL: https://balwurk.com/wp-content/ uploads/2023/06/rep-ossra-2023.pdf.

[87] Sree Ranjani Rajendran, Nusrat Farzana Dipu, Shams Tarek, Hadi M Kamali, Farimah Farahmandi, and Mark Tehranipoor. Exploring the abyss? unveiling systems-on-chip hardware vulnerabilities beneath software. IEEE Transactions on Information Forensics and Security, 2024.

2024 open source se[98] Synopsys. curity and risk analysis report, 2024. URL: https://static.carahsoft.com/ concrete/files/1617/1597/8665/ 2024_Open_Source_Security_and_Risk_Analysis_Report_WR

[88] Zhilei Ren, Shiwei Sun, Jifeng Xuan, Xiaochen Li, Zhide Zhou, and He Jiang. Automated patching for unreproducible builds. In Proceedings of the 44th International Conference on Software Engineering (ICSE ’22), pages 200–211, New York, NY, 2022. ACM. doi:10.1145/3510003.3510102.

[99] Mahzabin Tamanna, Sivana Hamer, Mindy Tran, Sascha Fahl, Yasemin Acar, and Laurie Williams. Unraveling challenges with supply-chain levels for software artifacts (slsa) for securing the software supply chain. https://arxiv.org/abs/2409.05014, 2024. arXiv:2409.05014.

[89] renovatebot. renovate, 2019. URL: https:// github.com/renovatebot/renovate.

[100] Mahzabin Tamanna, Sivana Hamer, Mindy Tran, Sascha Fahl, Yasemin Acar, and Laurie Williams. Unraveling challenges with supply-chain levels for software artifacts (slsa) for securing the software supply chain. Available at SSRN 5119626, 2024.

[90] RTimothyEdwards. magic, 2019. URL: https:// github.com/RTimothyEdwards/magic. [91] Nuno Saavedra and João F. Ferreira. GLITCH: Automated polyglot security smell detection in infrastructure as code. arXiv preprint arXiv:2205.14371, 2022. URL: https://arxiv.org/abs/2205.14371.

[101] Benjamin Tan, Siddharth Garg, Ramesh Karri, Yuntao Liu, Michael Zuzak, Abhisek Chakraborty, Ankur Srivastava, Omid Aramoon, Qian Xu, Gang Qu, et al. Independent verification and validation of securityaware eda tools and ip. In 2021 58th ACM/IEEE Design Automation Conference (DAC), pages 1299– 1302. IEEE, 2021.

[92] Hassan Salmani, Tamzidul Hoque, Swarup Bhunia, Muhammad Yasin, Jeyavijayan JV Rajendran, and Naghmeh Karimi. Special session: countering ip security threats in supply chain. In 37th IEEE VLSI Test Symposium (VTS), 2019.

[102] Matthew Taylor, Ruturaj K Vaidya, Drew Davidson, Lorenzo De Carli, and Vaibhav Rastogi. Spellbound: Defending against package typosquatting. https://arxiv.org/abs/2003.03471, 2020. arXiv:2003.03471.

[93] Md Sami Ul Islam Sami, Jingbo Zhou, Sujan Kumar Saha, Fahim Rahman, Farimah Farahmandi, and Mark Tehranipoor. Sap: Silicon authentication platform for system-on-chip supply chain vulnerabilities. In 2024 IEEE International Symposium on Performance Analysis of Systems and Software (ISPASS), pages 109–119. IEEE, 2024.

[103] SkyWater Technology. Google partners with skywater and efabless to enable open source manufacturing of custom asics, 2020. URL: https://www.skywatertechnology.com/wpcontent/uploads/2020/11/Open-SourcePDK_MPW-Program_FINAL_11.12.20.pdf.

[94] Taylor R Schorlemmer, Bas Hemel, and Roel J Wieringa. Signing in four public software package registries: Quantity, quality, and influencing factors. arXiv preprint arXiv:2401.14635, 2024. URL: https: //arxiv.org/abs/2401.14635.

[104] Mark Tehranipoor, Kimia Zamiri Azar, Navid Asadizanjani, Fahim Rahman, Hadi Mardani Kamali, 19

and Farimah Farahmandi. Secure physical design. In Hardware Security: A Look into the Future, pages 401–445. Springer, 2024.

[116] Shenao Wang, Yanjie Zhao, Xinyi Hou, and Haoyu Wang. Large language model supply chain: A research agenda. ACM Transactions on Software Engineering and Methodology, 34(5):1–46, 2025.

[105] Mark M Tehranipoor, Farimah Farahmandi, Hadi Mardani Kamali, Mohammad Rahman, Rui Guo, and Fahim Rahman. Clock gating system and method for protecting hardware designs, December 19 2024. US Patent App. 18/734,443.

[117] Dominik Wermke, Jan H Klemmer, Noah Wöhler, Juliane Schmüser, Harshini Sri Ramulu, Yasemin Acar, and Sascha Fahl. "always contribute back": A qualitative study on security challenges of the open source supply chain. In 2023 IEEE Symposium on Security and Privacy (SP), pages 1545–1560. IEEE, 2023.

[106] Mohammad Tehranipoor and Farinaz Koushanfar. A survey of hardware trojan taxonomy and detection. IEEE design & test of computers, 27(1):10–25, 2010.

[118] Dominik Wermke, Noah Wöhler, Jan H. Klemmer, Marcel Fourné, Yasemin Acar, and Sascha Fahl. Committed to trust: A qualitative study on security & trust in open source software projects. In 43rd IEEE Symposium on Security and Privacy, 2022. Retrieved May 22, 2024 from https://www.ieeesecurity.org/TC/SP2022/index.html.

[107] Mohomed Thariq and Indrajith Ekanayake. Argoslsa: Software supply chain security in argo workflows. arXiv preprint arXiv:2503.20079, 2025. URL: https://arxiv.org/abs/2503.20079. [108] Santiago Torres-Arias. In-toto: Practical Software Supply Chain Security. Ph.d. dissertation, New York University Tandon School of Engineering, 2020.

[119] Laurie Williams, Sammy Migues, Jamie Boote, and Ben Hutchison. Proactive software supply chain risk management framework (p-sscrm) version 1. https://arxiv.org/abs/2404.12300, 2024. arXiv:2404.12300.

[109] Mindy Tran, Yasemin Acar, Michel Cucker, William Enck, Alexandros Kapravelos, Christian Kastner, and Laurie Williams. S3c2 summit 2022-09: Industry secure supply chain summit. http://arxiv.org/abs/ 2307.15642, 2022. arXiv:2307.15642.

[120] Kan Xiao, Adib Nahiyan, and Mark Tehranipoor. Security rule checking in ic design. Computer, 49(8):54–61, 2016.

[110] Greg Tystahl, Yasemin Acar, Michel Cucker, William Enck, Alexandros Kapravelos, Christian Kastner, and Laurie Williams. S3c2 summit 2024-03: Industry secure supply chain summit. https://arxiv.org/abs/ 2405.08762, 2024. arXiv:2405.08762.

[121] Aditya Sirish A Yelgundhalli, Patrick Zielinski, Reza Curtmola, and Justin Cappos. Rethinking trust in forgebased git security. Network and Distributed System Security (NDSS) Symposium, 2025.

[111] Azim Uddin, Sujan Kumar Saha, Farimah Farahmandi, and Mark Tehranipoor. Case study: Fault-injection vulnerability assessment at rtl level. In 2024 IEEE Physical Assurance and Inspection of Electronics (PAINE), pages 1–7. IEEE, 2024.

[122] YosysHQ. yosys, n.d. URL: https://github.com/ YosysHQ/yosys. [123] Zeliang Yu, Ming Wen, Xiaochen Guo, and Hai Jin. Maltracker: A fine-grained npm malware tracker copiloted by llm-enhanced dataset. In 33rd ACM SIGSOFT International Symposium on Software Testing and Analysis (ISSTA), pages 1759– 1771, 2024.

[112] M. M. Vai. VLSI Design. CRC Press, 1st edition, 2000. doi:10.1201/9781315274201. [113] Vivekananda Vedula, Jeyavijayan Rajendran, Arunshankar Dhandayuthapany, and Ramesh Karri. System, method and computer-accessible medium for security verification of third party intellectual property cores, September 25 2018. US Patent 10,083,303.

[124] Nusrat Zahan, Philipp Burckhardt, Mikola Lysenko, Feross Aboukhadijeh, and Laurie Williams. Shifting the lens: Detecting malware in npm ecosystem with large language models. https://arxiv.org/abs/ 2403.12196, 2024. arXiv:2403.12196.

[114] Matthew David Venn. Tiny tapeout: A shared silicon tapeout platform accessible to everyone. Authorea Preprints, 2024.

[125] Nusrat Zahan, Parth Kanakiya, Brian Hambleton, Shohanuzzaman Shohan, and Laurie Williams. Openssf scorecard: On the path toward ecosystem-wide automated security metrics. IEEE Security & Privacy, 21(6):76–88, 2023. doi:10.1109/MSEC.2023.3279773.

[115] Alexandre Verdet, Foutse Khomh, et al. Exploring security practices in infrastructure as code: An empirical study. arXiv preprint arXiv:2308.03952, 2023. URL: https://arxiv.org/abs/2308.03952. 20

[126] Nusrat Zahan, Thomas Zimmermann, Patrice Godefroid, Brendan Murphy, Chandra Maddila, and Laurie Williams. What are weak links in the npm supply chain? In 44th International Conference on Software Engineering: Software Engineering in Practice (ICSE-SEIP), pages 331–340, 2022. [127] Chenyuan Zhang, Hao Liu, Jiutian Zeng, Kejing Yang, Yuhong Li, and Hui Li. Prompt-enhanced software vulnerability detection using chatgpt. In 2024 IEEE/ACM 46th International Conference on Software Engineering: Companion Proceedings, pages 276–277, 2024. [128] Junan Zhang, Kaifeng Huang, Bihuan Chen, Chong Wang, Zhenhao Tian, and Xin Peng. Malicious package detection in npm and pypi using a single model of malicious behavior sequence. https://arxiv.org/ abs/2309.02637, 2023. arXiv:2309.02637. [129] Lyuye Zhang, Chengwei Liu, Sen Chen, Zhengzi Xu, Lingling Fan, Lida Zhao, Yiran Zhang, and Yang Liu. Mitigating persistence of open-source vulnerabilities in maven ecosystem. In 2023 38th IEEE/ACM International Conference on Automated Software Engineering (ASE), pages 191–203. IEEE, 2023. [130] Ying Zhang, Wenjia Song, Zhengjie Ji, Danfeng (Daphne) Yao, and Na Meng. How well does llm generate security tests? https://arxiv.org/abs/2310.00710, 2023. arXiv:2310.00710.

A

Appendix

21

Figure 5: S-codes S1-S147

22

Table 6: Detection Rubric. Detection verdict is derived by: (1) Access Vector baseline, (2) Detection Complexity adjustment, and (3) CIA Impact adjustment. Final verdict: Dfinal = DAV ⊕ DC ⊕CIA, where upgrades/downgrades follow: =3, # H=2, #=1, –=0. Metric No Detection Research

Identifier D:ND

Detection High

Complexity:

DC:H

Detection Medium

Complexity:

DC:M

Detection Low

Complexity:

DC:L

Confidentiality Impact: None Confidentiality Impact: Partial Confidentiality Impact: Full Integrity Impact: None

C:None

Integrity Impact: Partial

I:Partial

Integrity Impact: Full

I:Full

Availability Impact: None Availability Impact: Partial Availability Impact: Full

A:None

C:Partial C:Full I:None

A:Partial A:Full

Description No published VLSI-specific detection research or tooling. Requires specialized or nonautomated methods (formal equivalence, side-channel analysis). Partial automation; manual triage needed.

Example Only conceptual or unrelated discussions; no frameworks/datasets. Hidden logic in gate-level netlist detectable only via deep formal methods. Provenance mismatch between netlist and source commit requiring human validation. Fully automated detection using stan- CI rejects unsigned binaries using dard CI/CD safeguards. SBOM+signature enforcement. CIA Impacts (Included Inside Table) Research provides no confidentiality No encryption, isolation, or access protections. control. Research partially mitigates leakage Limited auditing or partial access rebut lacks complete protection. striction. Strong confidentiality mechanisms Access control, encryption, provepreventing IP/data leakage. nance tracking. Research does not ensure design/- Unsigned artifacts, no reproducible tool/integration integrity. builds. Some integrity checks or audit trails, Signed commits without build reprobut not complete. ducibility. Full integrity guarantees (signatures, Formally verified, attested artifacts. attestation, reproducible builds). No coverage against disruption/DoS. No redundancy or recovery.

Evaluation Not Met (#) — Represents a clear open research gap. Low (#) — Very hard to detect automatically; requires specialized tools.

Partial/ reactive resilience after disruption. Explicit uptime/resilience guarantees.

Slow detection or partial failover.

Partially Met (H #).

Redundancy, sandboxing malicious tools.

Fully Met ( ).

23

Medium (H #) — Some automation, but relies on expert analysis. High ( ) — Easily detectable via standard automated checks. Not Met (#) — No confidentiality controls present. Partially Met (H #) — Partial IP/data protection only. Fully Met ( ) — Clear confidentiality enforcement. Not Met (#). Partially Met (H #). Fully Met ( ). Not Met (#).

Table 7: Model entities used in the VLSI-SWSC attack taxonomy. Element

Category

Definition

Asw

Package introduction or misselection

Asw

Source repository or code tampering

Asw Asw

Trusted identity or maintainer compromise Build or toolchain compromise

Asw

Distribution, hosting, or update compromise

Asw

Signing or verification compromise

Asw

Vulnerability or configuration exploitation

Msw

Consumed software behavior control

Msw Msw Msw Msw Msw Msw Msw

Source or repository modification Trusted project or maintainer access Developer or maintainer environment control Build or toolchain execution control Distribution or update path control Signing or verification control Vulnerability or configuration-based control

Avlsi

IP theft, misuse, or counterfeiting

Avlsi Avlsi

Design tampering or malicious modification Hardware Trojan, backdoor, or logic bomb

Avlsi Avlsi

Information leakage or asset exposure Side-channel, fault, or physical attack

Avlsi Avlsi Avlsi

HLS-induced security vulnerability IC replacement or substitution Access abuse or system disruption

S

Design stages

O

Security outcomes

Introduction or selection of an attacker-controlled or misleading software package. Unauthorized modification of source code, repositories, or version-control content. Abuse or compromise of trusted developer, maintainer, or project-level access. Compromise of build processes, build infrastructure, compilers, or development tools. Manipulation of software distribution, hosting, mirrors, references, or update paths. Compromise or bypass of software signing and integrity-verification mechanisms. Exploitation of software vulnerabilities or insecure configurations in the software supply chain. Ability to control the behavior of software consumed by downstream tools or users. Ability to modify source code or repository contents. Ability to act through trusted project or maintainer privileges. Ability to control or manipulate a developer or maintainer environment. Ability to influence software execution during build or toolchain processing. Ability to manipulate software distribution, retrieval, or update paths. Ability to manipulate software signing or verification behavior. Ability gained through exploitation of software vulnerabilities or insecure configurations. Unauthorized extraction, use, reproduction, or counterfeiting of VLSI design assets. Unauthorized modification of VLSI design content or functionality. Insertion or realization of malicious hidden functionality within a hardware design. Exposure or exfiltration of sensitive VLSI design information or assets. Security compromise enabled through physical effects, side channels, or injected faults. Security weaknesses introduced or exposed during high-level synthesis. Replacement of a legitimate IC with a malicious or counterfeit component. Unauthorized access, privilege abuse, or disruption of VLSI tools or designflow operation. Design specification; high-level synthesis; logic synthesis; post-synthesis verification; design for testability; placement and routing; static timing analysis; physical verification and signoff; post-silicon validation; manufacturing testing. Confidentiality, integrity, and availability.

Table 8: Relationships used to construct VLSI-SWSC attack paths. The complete relationship mappings used by the Prolog model are available in the accompanying Open Science artifact. Relationship

Model Predicate

Meaning

Asw → Msw

valid_asw_msw_pair

Msw → Avlsi

valid_msw_avlsi_pair

Avlsi → S

possible_at

Avlsi → O

affects_outcome

Maps a software supply-chain attack category to the software-side attacker capability it enables. Maps a software-side capability to the VLSI-side attack classes that it can realize. Maps each VLSI-side attack class to the design stages where it can be introduced, enabled, observed, or propagated. Maps each VLSI-side attack class to the confidentiality, integrity, or availability outcomes it can affect.

24

Table 9: Evidence-to-category mappings used in the feasibility evaluation. The complete evidence records and mapping rationales are available in the accompanying Open Science artifact. ID

Evidence

Layer

Mapped Category

Strength

M1 M2 M3 M4 M5 M6 M7 M8 M9 M10 M11 M12 M13 M14 M15 M16 M17 M18 M19 M20 M21 M22 M23 M24 M25 M26 M27 M28 M29 M30 M31 M32 M33 M34 M35 M36 M37 M38 M39 M40

E2 E2 E2 E2 E3 E3 E8 E9 E10 E10 E10 E16 E19 E19 E22 E22 E27 E26 E35 E34 E28 E36 E36 E37 E48 E48 E38 E41 E41 E44 E43 E39 E45 E45 E46 E46 E47 E47 E49 E50

Asw Msw Avlsi Avlsi Asw Msw Msw Msw Msw Avlsi Avlsi Msw Msw Avlsi Asw Msw Msw Asw Msw Asw Msw Asw Msw Msw Asw Msw Msw Asw Msw Msw Asw Msw Asw Msw Asw Msw Asw Msw Avlsi Avlsi

vulnerability_or_configuration_exploitation consumed_software_behavior_control design_tampering_or_malicious_modification hardware_trojan_backdoor_or_logic_bomb vulnerability_or_configuration_exploitation vulnerability_or_configuration_based_control consumed_software_behavior_control consumed_software_behavior_control consumed_software_behavior_control design_tampering_or_malicious_modification access_abuse_or_system_disruption consumed_software_behavior_control consumed_software_behavior_control design_tampering_or_malicious_modification vulnerability_or_configuration_exploitation vulnerability_or_configuration_based_control consumed_software_behavior_control vulnerability_or_configuration_exploitation consumed_software_behavior_control vulnerability_or_configuration_exploitation consumed_software_behavior_control build_or_toolchain_compromise build_or_toolchain_execution_control build_or_toolchain_execution_control build_or_toolchain_compromise build_or_toolchain_execution_control consumed_software_behavior_control vulnerability_or_configuration_exploitation vulnerability_or_configuration_based_control consumed_software_behavior_control vulnerability_or_configuration_exploitation consumed_software_behavior_control build_or_toolchain_compromise build_or_toolchain_execution_control build_or_toolchain_compromise build_or_toolchain_execution_control build_or_toolchain_compromise build_or_toolchain_execution_control access_abuse_or_system_disruption access_abuse_or_system_disruption

Direct Direct Indirect Indirect Direct Direct Direct Direct Direct Indirect Indirect Direct Direct Indirect Direct Direct Direct Indirect Direct Indirect Indirect Direct Direct Direct Direct Direct Direct Direct Direct Direct Indirect Indirect Direct Direct Direct Direct Direct Direct Indirect Indirect

Table 10: Evidence-based feasibility rubric for synthesized VLSI-SWSC attack paths. The corresponding Prolog rules implement these High, Medium, and Low feasibility conditions. Asw Evidence

Msw Evidence

Avlsi Evidence

Stage Evidence

Final Label

✓ ✓ ✓ ✗ ✓/✗ ✗

✓ ✓ ✗ ✓ ✓/✗ ✗

✓ ✗ ✓/✗ ✓/✗ ✓ ✓/✗

✓ ✓/✗ ✓ ✓ ✓1 ✓/✗

High Medium Medium Medium Medium Low

25

Table 11: High-feasibility VLSI-SWSC attack paths. Each row reports the Integrity (I) and Availability (A) path for a common Asw → Msw → Avlsi → S combination. The complete set of 717 synthesized paths and classifications is available in the accompanying Open Science artifact. Asw → Msw → Avlsi

Stage S

I

A

build/toolchain compromise → build/toolchain execution control → design tampering/malicious modification

High-Level Synthesis

P333

P334

Logic Synthesis Post-Synthesis Verification Design for Testability Placement and Routing Static Timing Analysis Physical Verification and Signoff High-Level Synthesis

P335 P337 P339 P341 P343 P345 P419

P336 P338 P340 P342 P344 P346 P420

Logic Synthesis Post-Synthesis Verification Design for Testability Placement and Routing Static Timing Analysis Physical Verification and Signoff Manufacturing Testing High-Level Synthesis

P421 P423 P425 P427 P429 P431 P435 P614

P422 P424 P426 P428 P430 P432 P436 P615

Logic Synthesis Post-Synthesis Verification Design for Testability Placement and Routing Static Timing Analysis Physical Verification and Signoff High-Level Synthesis

P616 P618 P620 P622 P624 P626 P700

P617 P619 P621 P623 P625 P627 P701

Logic Synthesis Post-Synthesis Verification Design for Testability Placement and Routing Static Timing Analysis Physical Verification and Signoff Manufacturing Testing

P702 P704 P706 P708 P710 P712 P716

P703 P705 P707 P709 P711 P713 P717

build/toolchain compromise → build/toolchain execution control → access abuse/system disruption

vulnerability/configuration exploitation → vulnerability/configuration-based control → design tampering/malicious modification

vulnerability/configuration exploitation → vulnerability/configuration-based control → access abuse/system disruption

26

Related documents

• FuseChain: Runtime Evidence Reconstruction for Software Supply-Chain Attacks#280129
• Extension of the Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE) to Transport Layer Security (TLS)#502733
• CVE-2026-105570 — MEDIUM 6.7#1267630
• MCP Pitfall Lab: Exposing Developer Pitfalls in MCP Tool Server Security under Multi-Vector Attacks#128214
• From Retrieved Evidence to Security Outcomes: A Data-Driven Analysis of Java Security API Misuse in LLM-Generated Code#1200951