FSM Security Knowledge Graph

• FSKG is a curated, directed, and labeled knowledge graph that encodes security vulnerabilities, mitigations, and FSM code patterns for secure hardware design.
• It leverages a formal schema to map vulnerabilities, states, transitions, and checks, ensuring actionable security insights and deterministic prompt augmentation for LLMs.
• The graph enables programmatic retrieval of security knowledge, enhancing automated verification and mitigation in SoC designs while reducing LLM-generated vulnerabilities.

The FSM Security Knowledge Graph (FSKG) is a curated, directed, and labeled knowledge graph that systematizes security vulnerabilities, mitigations, and code patterns relevant to finite state machines (FSMs) in hardware design, particularly for use in automated secure Verilog code generation via LLMs. FSKG serves as a structured intermediary layer that encodes security-centric domain knowledge and programmatically injects design-time security constraints into LLM prompt construction, addressing the persistent issue of security vulnerabilities in LLM-generated hardware control logic for systems-on-chip (SoC) (Hu et al., 18 Aug 2025).

1. Formal Structure and Schema of FSKG

FSKG is defined mathematically as a tuple $\mathrm{FSKG} = (V, E, R, T, \varphi)$, incorporating a finite set of nodes $V$, directed labeled edges $E \subseteq V \times V$, relation types $R$, node types $\mathcal{T}$ assigned via $T: V \to \mathcal{T}$, and a labeling function $\varphi: E \to R$. The schema consists of the following node and relation types:

• Node Types:
  • Vulnerability (attributes: id—e.g., CWE-362, severity $\in \{1...10\}$, description)
  • State (attributes: name, isProtected $\in \{\mathrm{True}, \mathrm{False}\}$, resetValue)
  • Transition (attributes: fromState, toState, condition)
  • Mitigation (attributes: pattern, applicability)
  • Check (attributes: testName, requiredPrecondition)
  • Example (attributes: codeSnippet, isGoodExample)
• Edge (Relation) Types:
  • hasType (Node $\rightarrow$ Type)
  • triggers (Vulnerability $V$0 Vulnerability)
  • mitigates (Mitigation $V$1 Vulnerability)
  • requiresCheck (Vulnerability $V$2 Check)
  • hasConsequence (Vulnerability $V$3 textual node)
  • goodExample, badExample (Vulnerability $V$4 Example)
  • suggestion (Vulnerability $V$5 Mitigation)
  • confirmPositive/confirmNegative (Vulnerability $V$6 Example)

Each edge can carry additional metadata (e.g., confidence $V$7, precondition as a Boolean formula). The FSKG is manually curated for internal consistency and to avoid conflicting definitions.

2. Node and Relation Semantics

Node attributes are designed to encode actionable security information:

• Vulnerability nodes encapsulate threats, identified by CWE IDs, with severity and textual description.
• Mitigation nodes provide code-level patterns suitable for automating defense mechanisms, always attached with those patterns.
• State and Transition nodes abstract FSM elements with security-relevant flags (e.g., isProtected).
• Check nodes reference formal design-time or runtime tests required for vulnerability mitigation.
• Example nodes deliver minimal code snippets, labeled by effectiveness (goodExample/badExample).

Edge semantics specify both logical relations ("mitigates," "triggers") and process constraints ("requiresCheck," "suggestion"), enabling traceable mapping from abstract vulnerability to concrete code pattern and design check.

3. Automated Vulnerability Mapping and Knowledge Retrieval

FSKG supports programmatic extraction of all security knowledge relevant to a given set of flagged vulnerabilities post-requirements analysis. For a requirements-driven set $V$8, FSKG enables subgraph retrieval $V$9, where $E \subseteq V \times V$0 returns the induced subgraph accessible within two hops via specific relations such as requiresCheck, suggestion, goodExample, and badExample.

Pseudocode for subgraph retrieval formally specifies this as:

$E \subseteq V \times V$7

This structure enables comprehensive knowledge harvesting relevant to a specific vulnerability, mapping each flagged risk to required checks, mitigation patterns, and empirical code illustrations, all retrieved from within the curated knowledge space.

4. Prompt Integration for Secure Code Generation

Knowledge retrieved from FSKG is split into code-centric (mitigation patterns and examples, $E \subseteq V \times V$1) and reporting-oriented items ($E \subseteq V \times V$2). Automated prompt assembly for LLM-driven Verilog code generation interleaves three components:

1. User's functional requirement $E \subseteq V \times V$3.
2. FSM architectural outline $E \subseteq V \times V$4 (e.g., few-shot code templates).
3. Security pattern list $E \subseteq V \times V$5.

The assembled LLM prompt explicitly instructs the model to apply and document relevant mitigations: $E \subseteq V \times V$8 This structured prompt composition draws directly on FSKG knowledge to align LLM code generation with security best practices associated with user-specified requirements (Hu et al., 18 Aug 2025).

5. Illustrative Example: Race-Condition Vulnerability

To concretely demonstrate FSKG’s operation, consider the case where a pre-analysis pipeline identifies a ‘RaceCondition’ vulnerability (CWE-362). FSKG retrieval yields the following triples:

1. (RaceCondition, requiresCheck, CheckSequentialArbiter)
2. (RaceCondition, suggestion, ArbiterLockPattern)
3. (ArbiterLockPattern, mitigates, RaceCondition)
4. (RaceCondition, goodExample, ExampleNode)

Corresponding node attributes include:

• ArbiterLockPattern.pattern: “Use a one-hot grant register with handshake.”
• ExampleNode.codeSnippet: always @(posedge clk) if (grant_lock==0) begin … end

This information is injected into $E \subseteq V \times V$6 and embedded in the LLM prompt, resulting in code with explicit, commented race-condition mitigations.

6. Security Curation and Validation Principles

Underlying FSKG construction is rigorous manual curation to enforce a coherent, non-redundant vocabulary of vulnerabilities (e.g., CWE series), mitigation mechanisms, and code exemplars. Each vulnerability node captures unique, disjoint entities, all mitigation patterns are reviewed for applicability, and the overall structure is routinely validated for consistency. This ensures that design-time knowledge retrieval for code generation is deterministic and verifiable.

7. Significance, Applications, and Implications

FSKG, as integrated in SecFSM, operationalizes security-by-construction in LLM-driven FSM code generation. By programmatically extracting, contextualizing, and enforcing tailored mitigations based on vulnerability analysis, FSKG directly addresses the known limitations of neural code synthesis in security-critical hardware domains. A plausible implication is the broader applicability of this paradigm to other domains where code synthesis faces systemic security gaps. Empirically, SecFSM achieves a 21/25 pass rate on a benchmark of 25 security test cases, demonstrating the practical impact of FSKG-guided prompt augmentation (Hu et al., 18 Aug 2025).