🤖 AI

ATLAS: AI-Assisted Threat-to-Assertion Learning for System-on-Chip Security Verification

ATLAS is an LLM-driven framework that automates System-on-Chip security verification by transforming standardized vulnerability knowledge into formal assertion-based properties and verification scripts, successfully detecting and validating numerous CWEs in benchmark evaluations.

Original authors: Ishraq Tashdid, Kimia Tasnia, Alexander Garcia, Jonathan Valamehr, Sazadur Rahman

Published 2026-03-03

📖 4 min read☕ Coffee break read

CC BY 4.0

Original authors: Ishraq Tashdid, Kimia Tasnia, Alexander Garcia, Jonathan Valamehr, Sazadur Rahman

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine you are building a massive, high-tech castle (a System-on-Chip or SoC) that runs your smart home, your car, and even your bank account. This castle is made of millions of tiny rooms, doors, and secret passages.

In the past, checking if this castle was secure was like hiring a single guard to walk through every single room, looking for open windows or broken locks. It was slow, exhausting, and the guard often missed things because the castle was too complex.

ATLAS is a new, super-smart AI assistant designed to fix this. Think of it as a digital Sherlock Holmes who doesn't just walk around; he has a magical encyclopedia of every possible way a castle can be broken into, and he knows exactly where to look.

Here is how ATLAS works, broken down into simple steps:

1. The "Wanted Poster" Library (The Knowledge Base)

Imagine a giant library containing "Wanted Posters" for every type of criminal trick known to man. In the tech world, these are called CWEs (Common Weaknesses). There are hundreds of thousands of these posters, describing things like "leaving the back door unlocked" or "letting anyone into the king's bedroom."

The Problem: Before ATLAS, engineers had to manually read these posters and guess which ones applied to their specific castle.
The ATLAS Solution: ATLAS has already read all the posters and organized them into a Threat Model Database. It knows exactly which "Wanted Poster" matches which part of the castle.

2. The "Asset Detective" (Finding What to Protect)

Before you can protect your castle, you need to know what's valuable inside. Is it the gold? The secret maps? The master key?

ATLAS scans the blueprints of your castle (the RTL code) and acts like a detective. It asks: "Where is the gold? Where are the secret keys?"
It identifies these "Assets" (like a memory chip or a password register) and tags them as "High Value."

3. The "Matchmaker" (Connecting the Dots)

Now, ATLAS does the magic. It takes the Assets it found and looks at its Wanted Poster Library.

It asks: "Okay, we have a 'Secret Key' here. Which criminal tricks (CWEs) are famous for stealing secret keys?"
It instantly matches the asset to the specific threats. It doesn't just guess; it uses a standardized template to say, "If a hacker tries to do X to this Key, the castle breaks."

4. The "Rulebook Writer" (Creating the Security Tests)

This is the most important part. In the past, writing the rules to test the castle was hard. You had to write complex legal language (formal assertions) that only a few experts understood.

The Old Way: A human expert tries to write a rule like, "If the door is open and the sun is shining, the guard must yell." They often get it wrong or miss a corner case.
The ATLAS Way: ATLAS looks at the castle's blueprints, its user manual, and a summary of how it works. It then writes the rulebook automatically.
- It says: "I see a door (Asset). I know a thief might try to pick the lock (Threat). So, I will write a rule: 'If the lock is picked, sound the alarm immediately.'"
- It translates this into a computer language that a security robot (a tool called JasperGold) can understand perfectly.

5. The "Security Robot" (The Proof)

Finally, ATLAS hands these new rules to the security robot.

The robot runs a simulation. It tries to break the castle using every trick in the book.
If the castle holds: The robot says, "Safe! The rule worked."
If the castle breaks: The robot says, "Busted! Here is exactly how the thief got in."

Why is this a big deal?

Speed: It does in minutes what used to take humans weeks.
Accuracy: It found 39 out of 48 known security flaws in test cases, and for 33 of them, it wrote the perfect rule to catch the flaw.
Scalability: As castles get bigger and more complex, humans can't keep up. ATLAS just gets better.

The Analogy Summary

Think of ATLAS as a super-intelligent insurance adjuster for your digital castle.

It knows every possible way a house can burn down (The Library).
It finds the flammable wood in your specific house (The Assets).
It writes a custom fire-safety code for your house (The Rules).
It sends a robot to try and light a fire to prove the code works (The Verification).

By automating this process, ATLAS helps engineers build "Secure-by-Design" chips, ensuring that our future technology is safe before it even leaves the factory.

1. Problem Statement

The security verification of modern Systems-on-Chip (SoCs) faces critical challenges due to increasing design complexity, the use of untrusted third-party IP, and the lack of standardized security rules.

Limitations of Current Methods: Traditional threat modeling is manual, error-prone, and cannot scale with the growing number of vulnerabilities (over 200,000 in databases like CWE and CVE). Existing formal verification and fuzzing techniques rely heavily on manually crafted constraints, requiring deep domain expertise and failing to generalize across the full spectrum of vulnerabilities.
The Gap: While Large Language Models (LLMs) have shown promise in code generation, current attempts at LLM-assisted security property generation are ad hoc, cover only a small subset of known vulnerabilities, and lack the contextual understanding required to map abstract weaknesses to specific RTL (Register Transfer Level) implementations.
The Core Challenge: How to systematically transform vast, unstructured vulnerability knowledge (CWE/CVE/CAPEC) into actionable, design-specific formal assertions for SoC security verification without manual intervention.

2. Methodology: The ATLAS Framework

ATLAS is a unified, LLM-driven framework that bridges the gap between standardized threat modeling and formal proof. It operates through a four-stage pipeline:

A. Standardized Threat Modeling & Knowledge Base Construction

Threat Model Template: ATLAS introduces a standardized template to ensure consistency. This template defines:
- Adversaries: Capabilities and access levels (e.g., Unprivileged Software, Skilled Hardware, Insider Threat).
- Assets: Sensitive data or logic (e.g., Boot Integrity, State Resources).
- Attack Surfaces: Interfaces used to exploit assets.
- Vulnerabilities & Threats: Distinctly separating the weakness (CWE) from the exploit scenario.
Threat Model Database (TMDB): Using GPT-5, ATLAS generates a comprehensive database of threat models for known hardware CWEs. It leverages public repositories (CWE, CVE, CAPEC) and human feedback to create structured, reusable threat vectors for every known hardware weakness.

B. Asset-Centric Threat Modeling

Asset Detection: ATLAS analyzes buggy SoC RTL code using generic asset definitions (e.g., "Runtime Integrity," "Sensitive Data") to identify specific security-critical signals and modules.
CWE Mapping: The framework matches detected assets against the TMDB. By performing keyword mapping (e.g., matching "FSM" or "State" signals to relevant CWEs), it identifies which specific Common Weakness Enumerations (CWEs) are applicable to the specific design assets.

C. Context-Aware Property Generation

To generate accurate formal properties, ATLAS does not rely solely on RTL code. It synthesizes three complementary context sources to guide the LLM:

Design Documents (DD): Provides high-level intent, interface specifications, privilege rules, and trust boundaries.
Abstract Syntax Tree (AST): Offers topological and structural details (control flow, signal drivers, state encodings) to help the LLM understand the hardware logic.
RTL Summary: A security-centric synopsis generated by the LLM itself to highlight critical assets and guardrails, reducing human bias.

Using these contexts, the LLM translates the identified CWEs and threat models into SystemVerilog Assertions (SVA) and JasperGold verification scripts.

D. Formal Verification

The generated assertions are executed in JasperGold.

Outcome: If a property fails, the tool produces a minimal counterexample trace, proving the vulnerability exists. If it passes, it provides a formal proof of security for that specific threat model.

3. Key Contributions

First Standardized Threat Modeling Template for SoCs: ATLAS proposes a universal template that explicitly separates adversaries, assets, and threats, enabling consistent automation.
Automated TMDB Generation: It creates a scalable, evolving database of threat models for hardware CWEs using LLMs and human-in-the-loop validation, moving beyond static, manual lists.
Context-Driven Property Generation: The paper demonstrates that combining AST, Design Documents, and RTL Summaries is essential for LLMs to generate correct security properties. Ablation studies show that without these contexts, LLMs fail to derive sound constraints.
End-to-End Automation: The framework automates the entire flow from vulnerability knowledge (CWE) $\to$ Asset Identification $\to$ Threat Modeling $\to$ Formal Assertion Generation $\to$ Proof.

4. Experimental Results

The framework was evaluated on three HACK@DAC benchmarks (2018, 2019, 2021) featuring RISC-V based SoCs with known security bugs.

Detection Rate: ATLAS successfully identified 39 out of 48 relevant CWEs across the benchmarks.
Property Generation: Of the 39 detected CWEs, ATLAS generated correct formal properties for 33 cases (>82%), successfully detecting the vulnerabilities via formal proof.
Ablation Study:
- Without TMDB: An LLM-only baseline detected less than 30% of CWEs (e.g., 6/20 in 2018). ATLAS with TMDB improved this to 85% (17/20).
- Without Context: Removing Design Documents, AST, or RTL summaries drastically reduced the accuracy of property generation. ATLAS with full context showed a 3x improvement in accurate property detection compared to using only one context source.
Handling False Negatives: In cases where formal verification failed (inconclusive results), the generated properties often still revealed missing controls or incomplete resets, serving as actionable warnings rather than false alarms.

5. Significance and Impact

Secure-by-Design Paradigm: ATLAS shifts the industry from reactive, post-silicon vulnerability remediation to proactive, automated security verification during the design phase.
Scalability: By automating the mapping of thousands of CWEs to specific RTL designs, ATLAS addresses the scalability bottleneck that prevents manual security verification from keeping pace with modern SoC complexity.
Knowledge-Driven Verification: It effectively leverages the massive existing knowledge base of hardware vulnerabilities (CWE/CVE) to drive formal verification, a capability previously limited to manual expert analysis.
Future Direction: The work establishes a foundation for integrating AI-driven threat modeling into standard EDA flows, potentially reducing the cost and time-to-market for secure hardware while improving national and organizational security resilience.