Skip to content

Back to the catalog

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

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

This paper analyses software supply chain (SWSC) attacks against VLSI design tools. It empirically studies the software composition, security features and tool interactions of VLSI suites, then builds a taxonomy linking SWSC attacks to VLSI attacks, design-flow stages and security outcomes. The taxonomy yields 717 possible new attacks, 60 of them high feasibility, with a threat model, a defense assessment and case studies on an open-source VLSI flow.

TL;DR Maps software supply chain attacks onto VLSI design flows, identifying 717 possible attacks (60 high feasibility) and gaps in existing defenses.
Document

What it is

A Purdue paper (Hashmat, Li, Torres-Arias; arXiv 2610.22580v1, 15 October 2026) on software supply chain (SWSC) attacks against the pre-silicon VLSI design flow. It treats EDA tools, their libraries and their build steps as the attack surface, instead of hardware Trojans or foundry-side threats. The fetched text stops partway through the methodology section, so the results are not covered here.

How it works

The authors start from the NIST three-phase model of a SWSC attack: injection, propagation, exploitation. They map it onto the stages of the VLSI flow, from design specification and high-level synthesis through verification, logic synthesis, post-synthesis verification and design for test (DFT).

Each stage has a stated risk:

  • Compromised high-level synthesis or logic synthesis tools can alter the RTL or netlist.
  • Compromised verification or equivalence checking can let those changes pass unnoticed.
  • Compromised DFT or timing steps can misreport timing paths or add access points such as a hidden JTAG port.
  • Unverified third-party IP in the specification stage can bring in backdoors from the start.

The paper's reason for focusing on pre-silicon is that synthesis, simulation, verification and timing tools pull in SAT/SMT solvers, parsing libraries, numerical optimisation engines and scripting runtimes.

Attack paths are rated high, medium or low feasibility using evidence from the authors' lab analysis of tool composition. Defenses are scored against the CIS Software Supply Chain Security Guide. The authors chose CIS over NIST SSDF, SP 800-161 and SLSA because its controls on source integrity, dependency validation, build hardening and artifact verification are closest to implementation.

Preconditions / Affected

The case study uses an open-source flow: Yosys (logic synthesis), OpenLane (RTL-to-GDSII) and Magic. The authors implemented three software-only attacks from their taxonomy, labelled P376, P703 and P616, mostly via third-party libraries and dependencies. A fourth, P624, is discussed only as speculative. The page text does not describe what these attacks do.

What to do

The visible text gives no concrete mitigations, commands or patches. Its practical content is a way to audit a flow: list the third-party components in each tool, check which stage consumes their output, and compare your controls with the CIS guide. The authors say the gaps are widest for unvalidated open-source components and for interactions between tools.

Caveats

  • The 717 attacks are possible attacks derived from the taxonomy, not observed incidents. Only 60 are rated high feasibility.
  • The paper addresses deliberate SWSC attacks, not accidental vulnerable dependencies.
  • Per-attack results, the defense coverage numbers and the commercial EDA findings are not in the fetched text.

Technologies named here

  • VLSI-SWSC threat model

Techniques named here

  • Empirical analysis of VLSI software suites
  • Feasibility evaluation of attacks across VLSI design stages

Threat actors named here