FSTab: Feature–Security Mapping Overview

• FSTab is a formal mapping linking observable software features with corresponding security properties, threats, and vulnerabilities.
• It facilitates systematic auditing and black-box vulnerability prediction by correlating frontend features with backend risks using metrics like PMI and Laplace smoothing.
• FSTab underpins robust security engineering in LLMs, OS kernels, and feature taxonomies, aiding compliance and informed design decisions.

A Feature–Security Table (FSTab) is a formal, systematic mapping between software features and associated security properties, threats, mitigation mechanisms, or vulnerabilities. FSTab provides a bidirectional interface: it allows for the auditing, classification, and prediction of security risks or mechanisms based on observable features, and supports model or system-centric evaluation of vulnerability persistence and compartmentalization. FSTab is employed for program analysis and security engineering, as well as for black-box attacks leveraging knowledge of typical feature–vulnerability pairings in code generated by LLMs, system kernels, or functional security frameworks (Kordonsky et al., 2 Feb 2026, Steffin et al., 10 Oct 2025, Hermann et al., 8 Jan 2025).

1. Formal Models and Instantiations of FSTab

FSTab is formalized as a mapping from features $\mathcal{F}$—concretely observable functional units such as “user_login_with_password,” “upload_file,” or kernel-level memory domains—to an ordered multimap of security-related objects. The codomain depends on the application:

• LLM Code Security: For LLMs, $T_M : \mathcal{F} \to [\mathcal{R}]_{\text{top-}k}$, where $\mathcal{R}$ is a set of vulnerability rule IDs (e.g., CWE, CodeQL rule).
• Operating System Security: In iOS kernel architecture, FSTab pairs features (SPTM, TXM, Exclaves) with security goals, mechanisms, trust boundaries, and inter-process communication (IPC) models.
• Security Taxonomies: In implementation-level feature taxonomies, each row of FSTab cross-references a feature with formal descriptions, standards mappings, supported frameworks, and representative code constructs.

Mathematically, the LLM FSTab approximates the conditional distribution

$$P_M(r\mid f) = \Pr_{P\sim M}(r\ \text{appears in}\ P_B\mid f\in P_F)$$

using Pointwise Mutual Information (PMI) and Laplace-smoothed frequency estimates: $$S_{\mathrm{PMI}}(f,r) = \log\frac{\hat P(r|f)}{\hat P(r)}$$ where

$$\hat P(r|f) = \frac{C(f,r)+\alpha}{C(f)+\alpha|\mathcal{R}|},\quad \hat P(r) = \frac{C(r)+\alpha}{N+\alpha|\mathcal{R}|}.$$

This abstraction supports data-driven FSTabs tailored to LLMs, kernels, or security standards.

2. Construction Methodologies

The construction of an FSTab proceeds in sequential phases, which depend on the target platform and objective:

LLM-Driven FSTab Construction (Kordonsky et al., 2 Feb 2026):

1. Data Generation: Synthesize a corpus $\{P^{(i)}\}$ of programs $(P_F, P_B)$ by sampling the code model $M$ with a suite of prompts, including multiple semantic rephrasings.
2. Automatic Labeling:
   • Frontend Feature Extraction: Employ AST- or regex-based analysis to extract frontend features, heuristically mapping each handler/function to a unique $f \in \mathcal{F}$.
   • Backend Vulnerability Scanning: Use static analyzers (e.g., CodeQL, Semgrep) to identify vulnerabilities, obtaining rule IDs $r \in \mathcal{R}$.
3. Co-occurrence Counting and Scoring: For each $(f, r)$ pair, record counts $C(f, r)$. Compute PMI scores.
4. Diversity-Promoted Selection: Use a greedy algorithm with a penalty factor $\lambda$ to limit selection of over-represented vulnerabilities, ensuring a broad and unambiguous mapping.

System Security FSTab Construction (Steffin et al., 10 Oct 2025):

• For compartmentalized system features (e.g., SPTM, TXM, Exclaves), FSTab is constructed by formalizing each feature’s security goals, corresponding enforcement mechanisms (e.g., memory typing $\tau : F \to T$), explicit trust domains, and the IPC routes used to transfer or isolate authority.

Feature Taxonomy FSTab Construction (Hermann et al., 8 Jan 2025):

• Each feature is given a formal description, standard mappings (ISO/NIST/CC), supporting frameworks, and a canonical code snippet. This is organized as a multi-column tabular resource supporting programmatic queries.

3. Security Contexts and Applications

Black-Box Prediction and Attack (Kordonsky et al., 2 Feb 2026): FSTab enables black-box attacks whereby, given only the set of observable UI features $F_{\mathrm{obs}} \subseteq \mathcal{F}$ and the model identifier $M$, an adversary retrieves top-$k$ expected vulnerabilities per feature from $T_M$. The aggregate, $$V_{\mathrm{pred}} = \bigcup_{f \in F_\mathrm{obs}} T_M[f]$$, prioritizes probable back-end vulnerabilities for exploitation, even without code access. Attack metrics are: $$\mathrm{Success}_P = \mathbf{1}[V_{\mathrm{pred},P}\cap V_{\mathrm{actual},P}\neq\varnothing],\quad \mathrm{Coverage}_P = \frac{|V_{\mathrm{pred},P}\cap V_{\mathrm{actual},P}|}{|V_{\mathrm{actual},P}|}$$ with population averages: $$\mathrm{ASR} =\frac1{|\mathcal{P}|}\sum_{P}\mathrm{Success}_P, \qquad \mathrm{ACR} =\frac1{|\mathcal{P}|}\sum_{P}\mathrm{Coverage}_P$$

OS Kernel Security Layering (Steffin et al., 10 Oct 2025): The FSTab classifies kernel features (SPTM, TXM, Exclaves) and formalizes security layering. SPTM enforces microkernel-style partitioning at the memory management level ($\tau : F \to T$ and policy bitmatrices), while TXM secures code-signing and entitlements, decoupled from kernel privilege, and Exclaves isolate hardware-rich domains (e.g., ANE, sensors) behind an additional boundary.

Feature Location and Standards Mapping (Hermann et al., 8 Jan 2025): FSTab catalogs 68 implementation-level security features with full mapping to ISO/NIST/CC controls, framework support, and code representations, supporting feature location, audit, and secure design decisions.

4. Metrics and Model-Centric Analysis

FSTab provides a foundation for quantifying vulnerability persistence and transfer across code generation models, rephrasings, and application domains (Kordonsky et al., 2 Feb 2026). Four key metrics are defined:

• Feature–Vulnerability Recurrence (FVR): For each $f \in \mathcal{F}$, the fraction of $(f, r)$ pairs recurring in the set of programs containing $f$.

$$FVR_\mathrm{model} = \frac{1}{|\mathcal{F}|}\sum_{f \in \mathcal{F}} \frac{|\{(f, r)\mid \mathrm{freq}_{G_f}(f, r) > 1\}|}{|\{(f, r)\mid \mathrm{freq}_{G_f}(f, r) \ge 1\}|}$$

• Rephrasing Vulnerability Persistence (RVP): Fraction of $(f, r)$ pairs persistent across multiple prompt rephrasings for a given task.

$$RVP_p = \frac{|\mathcal{V}_p^{\cap}|}{|\mathcal{V}_p^{\cup}|},\qquad RVP_\mathrm{model} = \frac1{|\mathcal{P}|}\sum_p RVP_p$$

• Domain Vulnerability Recurrence (DVR): Recurrence of vulnerability patterns within a specific domain $d$.

$$DVR_d = \frac{|\{(f,r)\mid \mathrm{freq}_{G_d}(f,r) > 1\}|}{|\{(f,r)\mid \mathrm{freq}_{G_d}(f,r)\ge 1\}|},\qquad DVR_\mathrm{model} = \frac1{|D|}\sum_d DVR_d$$

• Cross-Domain Transfer (CDT): Proportion of vulnerabilities present both within and outside domain $d$, capturing model-intrinsic vs. domain-specific patterns.

$$CDT_d = \frac{|\mathcal{V}_d \cap \mathcal{V}_{\neg d}|}{|\mathcal{V}_d|},\qquad CDT_\mathrm{model} = \frac1{|D|}\sum_d CDT_d$$

A high CDT-DVR gap (universality gap) implies that vulnerability patterns are model-intrinsic rather than domain-restricted.

5. Empirical Findings and Representative Tables

LLM Vulnerability Prediction

On LLM-generated code, the FSTab-based black-box attack achieves, for Claude-4.5 Opus on Internal Tools, $\mathrm{ASR} = 94\%$, $\mathrm{ACR} = 93\%$. With cross-domain exclusion (training without the target application domain), models such as GPT-5.2 retain $\mathrm{ASR} \approx 81\%$ and $\mathrm{ACR} \approx 79\%$. The universality gap ($CDT-DVR$) is consistently positive, indicating significant cross-domain generalization (Kordonsky et al., 2 Feb 2026).

Persistence metrics for leading models: | Model | FVR (%) | RVP (%) | DVR (%) | CDT (%) | |--------------|---------|---------|---------|------------| | GPT-5.2 | 37.5 | 23.2 | 33.9 | 42.3 | | Composer | — | 35.5 | 46.4 | — | | Grok | — | 12.0 | 27.9 | 57.3 |

This demonstrates that the FSTab abstraction is highly effective for black-box vulnerability inference.

OS Security Layer FSTab

An FSTab for modern iOS security architecture (Steffin et al., 10 Oct 2025):

Feature	Security Goals	Key Mechanisms	Trust Boundary	IPC/Transport Model
SPTM	Prevent arbitrary page-table writes; memory isolation; PRIVATE frame confidentiality	Physical-frame typing $\tau:F\to T$; validity $RT[told, tnew]$; multi-level dispatch	Domains $\in \{$SPTM, XNU, TXM, SK, HIB$\}$	XNU→GXF/GENTER→SPTM; TXM→SVC#0→SPTM; SK→HVC#0→SPTM
TXM	Enforce code-signing/entitlements; code isolation	Domain-limited SPTM calls; SPTM-guarded memory types	Domain = TXM	XNU→GENTER/SPTM(domain=TXM); TXM→SVC(#0/37/38)→SPTM
Exclaves	Protect sensor/ANE pipelines, privacy indicator integrity	SK_DOMAIN memory; per-domain resource tables; Tightbeam IPC	SK_GL1; per-Conclave domains	exclaves_ctl_trap (trap-88)→kernel; Tightbeam; xnuproxy

This table demonstrates explicit trust boundaries and formal compartmentalization, raising the bar against monolithic kernel compromise.

Security Feature Taxonomy FSTab

A machine-readable FSTab catalogs 68 security features (Hermann et al., 8 Jan 2025), each cross-referenced by:

• ISO 27001/2, NIST SP 800-53, NIST CSF, and Common Criteria mappings
• Supported frameworks (e.g., Spring Security, OWASP ESAPI, AppleSec)
• Code/API usage examples

Sample extracted entry:

Feature	Description	Code/API Example
Authentication	Verification of a subject’s claimed identity	securityContext.getAuthentication()
Authorization	Grant/deny access rights to an authenticated subject	@PreAuthorize("hasRole('ROLE_USER')")
Encryption	Transforming plaintext to ciphertext	cipher.doFinal(plainBytes)

This resource enables conformance analysis and aids feature location in large software projects.

6. Significance and Emerging Directions

FSTab frameworks unify disparate efforts in feature-based security reasoning and threat modeling. In the LLM context, the existence of strong cross-domain transfer and persistent $(\text{feature}, \text{vulnerability})$ mappings exposes an underexplored attack surface: black-box adversaries that exploit model-consistent code generation patterns. In layered OS architectures, FSTabs enable rigorous characterization of isolation boundaries, actor privileges, and policy enforcement, thus supporting both system hardening and formal verification. In feature taxonomies, the FSTab abstraction provides an actionable vocabulary for tracking, locating, and auditing security features.

A plausible implication is that as code generation and compartmentalized system designs proliferate, FSTab-like tables will become essential artifacts for robust security architecture, cross-domain vulnerability assessment, and automated compliance analysis.