[Paper] Can I Check What I Designed? Mapping Security Design DSLs to Code Analyzers

Source: arXiv - 2605.07814v1

Overview

The paper investigates the disconnect between security design specifications (often written in domain‑specific languages, or DSLs) and the low‑level vulnerability checks performed by automated code analyzers. By analysing dozens of design‑time DSLs and hundreds of analyzer rules, the authors expose why security experts struggle to trace a reported flaw back to the original design intent—and propose a unified model (SecLan) to start bridging that gap.

Key Contributions

• Comprehensive empirical study of 66 security‑design DSLs and 559 static‑analysis checks from 36 popular code‑level security tools.
• SecLan meta‑model that captures the overlapping concepts between design‑time DSL constructs and implementation‑time vulnerability patterns, validated by 22 security professionals.
• Quantitative mapping showing the surprisingly low overlap (≈ 15 %) between DSL concepts and analyzer checks.
• Qualitative insights from interviews with 9 security experts, revealing cognitive overload and the prevalence of overly generic weakness descriptions in analyzers.
• Open dataset (DSL specifications, analyzer rules, and the SecLan model) for the research community to reuse and extend.

Methodology

1. Corpus Construction – Collected publicly available security design DSLs (e.g., ADL, SecuriCAD, SecurITree) and extracted their core concepts (authentication, encryption, trust boundaries, etc.).
2. Analyzer Rule Harvesting – From 36 static‑analysis tools (FindSecBugs, SonarQube, CodeQL, etc.) gathered 559 individual security checks, normalising each to a common representation (vulnerability type, required code pattern, severity).
3. Concept Alignment – Used a combination of keyword matching, ontology mapping, and manual expert review to identify which DSL concepts could theoretically be expressed by each analyzer rule.
4. SecLan Model Development – Abstracted the overlapping concepts into a lightweight meta‑model (SecLan) that defines entities such as Asset, Threat, Control, and Violation.
5. Validation – 22 security experts evaluated the model’s completeness and correctness through a structured questionnaire.
6. Expert Interviews – Nine senior security engineers discussed real‑world challenges of mapping design artifacts to analyzer findings, providing qualitative context for the quantitative results.

Results & Findings

• Low Conceptual Overlap: Only about 15 % of DSL concepts had a direct counterpart in the collected analyzer checks, indicating a substantial abstraction gap.
• Generic Weakness Descriptions: Many analyzer rules were phrased in high‑level terms (e.g., “use of weak cryptography”) that could map to numerous DSL constructs, making automated traceability ambiguous.
• Expert Overload: Security professionals reported feeling “overwhelmed” when trying to manually correlate a static‑analysis warning with a design‑level policy, confirming the practical difficulty highlighted by the data.
• SecLan Validation: 86 % of the participating experts agreed that SecLan captured the essential security concepts needed for bridging design and code, though they noted missing domain‑specific nuances (e.g., IoT‑specific threat models).

Practical Implications

• Tool Integration Roadmap: Vendors can use the SecLan model as a common interchange format to expose design‑time policies to static‑analysis engines, enabling “design‑aware” warnings that point directly to violated design constraints.
• Developer Workflow Enhancements: IDE plugins could surface a design‑traceability view, letting developers click a reported issue and instantly see the related DSL element (e.g., “confidential data boundary”).
• Policy‑Driven CI/CD: Organizations can codify security design DSLs into SecLan, then automatically enforce compliance in CI pipelines by matching analyzer findings against the model—reducing false positives and focusing remediation effort.
• Training & Documentation: The empirical data can inform security training curricula, emphasizing the importance of maintaining traceability artifacts (e.g., mapping tables) between design documents and code‑level checks.
• Research Foundations: The released dataset and SecLan model provide a baseline for future work on automated mapping algorithms, machine‑learning classifiers that predict design‑level impact from analyzer output, and standardization efforts for security DSLs.

Limitations & Future Work

• Scope of DSLs & Analyzers: Focused on publicly available DSLs and open‑source/static analysis tools; proprietary or domain‑specific DSLs (e.g., automotive, medical) may exhibit different overlap patterns.
• Manual Mapping Bias: Although expert review mitigated it, the initial concept alignment relied partly on manual judgments, which could introduce subjectivity.
• Dynamic Analyses Excluded: Only static code checks were considered; runtime or fuzzing‑based security tools might map differently to design concepts.
• Future Directions: Extending SecLan to cover dynamic security checks, automating the mapping process with NLP/ML techniques, and conducting longitudinal studies to see how the gap evolves as DSLs and analyzers mature.

Authors

• Sven Peldszus
• Frederik Reiche
• Kevin Hermann
• Sophie Corallo
• Thorsten Berger
• Robert Heinrich

Paper Information

• arXiv ID: 2605.07814v1
• Categories: cs.CR, cs.SE
• Published: May 8, 2026
• PDF: Download PDF