Pith. sign in

REVIEW 2 major objections 4 minor 32 references

Extensible DFD analysis framework with constraint DSL and 26-model catalog

Reviewed by Pith at T0; open to challenge. T0 means a machine referee read the full paper against a public rubric. the ladder, T0–T4 →

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

T0 review · glm-5.2

2026-07-08 20:39 UTC pith:N6FXEO6O

load-bearing objection Solid tool paper with shipped artifacts; the one external validation point is thin but the paper is honest about being a tool/dataset contribution. the 2 major comments →

arxiv 2607.05913 v1 pith:N6FXEO6O submitted 2026-07-07 cs.SE cs.CR

xDECAF: An Extensible Data Flow Diagram Analysis Framework for Information Security

Benjamin Arp , Felix Schwickerath , Alexander Vogt , Tom H\"uller , Nils Niehues , Nicolas Boltz This is my paper
classification cs.SE cs.CR
keywords flowtoolanalysisdataxdecafdatasetdiagrameditor
verification ladder T0 review T1 audit T2 compute T3 formal T4 reserved

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper presents xDECAF, an open-source framework for architecture-based data flow analysis oriented toward information security. The central claim is that a combination of three design choices — an extended DFD metamodel with labels, pins, and assignments; a domain-specific constraint language with first-order-logic flow verbs; and a browser-based editor with a swappable backend — yields a foundation reusable across a broad range of security and compliance research problems, rather than a single-purpose tool. The paper substantiates this claim by cataloging 26 example models (7–923 nodes, 4–72 labels) with documented constraints and expected violations, and by surveying five downstream research lines (uncertainty-aware confidentiality, automated violation repair, compliance-driven interdisciplinary modeling, Zero Trust analysis, and analysis composition) that extend xDECAF in different directions. The paper positions xDECAF against existing tools (Microsoft Threat Modeling Tool, OWASP Threat Dragon, UMLsec, CORAS, SecDFD) by arguing that decoupling label types and labels from the analysis logic is the key structural difference enabling generality. External validation is attempted by applying xDECAF to the microSecEnD dataset of 132 DFD variants; 115 produced expected results and the 17 divergences are attributed to faults in the dataset rather than in xDECAF.

Core claim

The core technical contribution is the decoupling of label semantics from the analysis engine. In xDECAF, labels are arbitrary discrete values annotating nodes or data, assignments on output pins define conditional propagation logic, and constraints are expressed in a DSL with four flow verbs mapping to existential and universal quantifiers over the set of flows between matched source and destination selectors. This separation means the same engine can analyze role-based access control, Zero Trust compliance, legal compliance, or uncertainty propagation without changes to the analysis core — only the labels, assignments, and constraints differ. The framework also provides explicit builder-­­

What carries the argument

Extended DFD metamodel (nodes, flows, labels, pins, assignments); constraint DSL with four flow verbs (flows, alwaysFlows, neverFlows, notAlwaysFlows) mapping to first-order quantifiers; label propagation logic with cycle heuristics; builder-pattern analysis interface; browser-based editor with Sprotty frontend and WebSocket-connected backend; PCM-to-DFD transformation for Palladio Component Model instances.

Load-bearing premise

The paper's claim of utility rests primarily on adoption by research lines that share authors with the xDECAF team, and the one external validation (microSecEnD) produced 17 divergent results out of 132 cases attributed to dataset faults rather than framework errors. The load-bearing premise is that internal adoption constitutes concrete evidence of extensibility and correctness, rather than evidence of a single research group's sustained investment in a shared tool.

What would settle it

If an independent research team attempted to encode a novel security property in xDECAF's constraint DSL and found that the label-propagation model or the four-verb constraint language could not express the property without modifying the analysis engine itself, the central claim of domain-general extensibility would be undermined.

Watch this falsifier. Get emailed when new claim-graph text bears on it.

If this is right

  • If the decoupling of label semantics from the analysis engine is as clean as described, the framework could serve as a standard oracle for confidentiality analysis, enabling direct comparison of different mitigation or repair strategies on a shared analytical basis.
  • The 26-model catalog with documented expected violations could become a benchmark dataset for evaluating new data-flow-based security analysis techniques, similar to how standard datasets function in machine learning.
  • The constraint DSL's mapping to first-order logic quantifiers means constraint satisfiability and complexity bounds could in principle be characterized formally, giving users guarantees about analysis termination and soundness for specific constraint classes.
  • Current work on LLM-driven DFD and constraint derivation from natural language, mentioned in the conclusion, could lower the barrier to adoption for practitioners who are not security modeling experts.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • The claim of extensibility would be most directly testable by an independent team building a novel analysis concern (e.g., safety, reliability, or privacy budget tracking) on top of xDECAF without consulting the original authors; the paper's cited downstream work shares significant author overlap.
  • The 17 divergent results on the microSecEnD dataset, attributed to dataset faults, could be independently re-examined: if the divergences are genuinely dataset errors, a corrected microSecEnD should produce 132/132 agreement, which would be a stronger validation than the paper currently provides.
  • The constraint DSL's expressiveness boundary — what class of security properties can and cannot be encoded — is not formally characterized in the paper. Identifying this boundary would clarify whether the framework's generality has structural limits or is genuinely Turing-complete in its constraint expressiveness.
  • The cycle-resolution heuristics for cyclic DFDs are a potential soundness concern: if the heuristics approximate rather than precisely compute label propagation through cycles, there may be security-relevant flows that are missed, which would be important to characterize for safety-critical applications.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit.

Referee Report

2 major / 4 minor

Summary. This tool paper presents xDECAF, an extensible framework for architecture-based data flow analysis focused on information security. The framework combines an extended Data Flow Diagram (DFD) metamodel featuring labels, pins, and assignments, a domain-specific constraint language (DSL) with quantified flow operations, a browser-based editor with a backend analysis engine, and a curated catalog of 26 example models. The paper positions xDECAF as a reusable foundation for the research community and supports this claim by citing several downstream research lines (ABUNAI, ARCoViA, COLJA, Zero Trust analysis) and an external validation against the microSecEnD dataset.

Significance. The paper ships a publicly available, open-source tool library, a hosted online editor, and a curated catalog of 26 documented example models with expected violations, which is a tangible contribution to the community. The provision of a reusable dataset and a screencast enhances reproducibility and accessibility. The constraint DSL, mapping flow verbs to first-order logic quantifiers, provides a clear and formal foundation for specifying data flow constraints. The integration of externally authored DFDs from the microSecEnD dataset serves as a concrete, external validation point, which is a notable strength for a tool paper.

major comments (2)
  1. §5, External Validation: The paper states that 17 of 132 microSecEnD variants produced diverging results and that 'manual inspection' traced all discrepancies to 'faults in the manually created microSecEnD variants.' This is the sole piece of external validation evidence and is load-bearing for the claim of utility. However, no breakdown or characterization of these 17 faults is provided. Without at least a summary of the nature of these faults (e.g., a table or appendix listing the discrepancy type), the reader cannot independently assess whether the attribution to dataset faults rather than xDECAF interpretation issues is sound. A concrete breakdown is needed to substantiate the claim that 'none of the discrepancies stemmed from the transformation from PlantUML or the constraint formalization in xDECAF.'
  2. §1 and §5: The paper claims that downstream research adoption provides 'concrete evidence of its utility.' However, the majority of the cited downstream works (e.g., [5, 6, 7, 9, 10, 16, 17, 18, 19, 22]) share coauthors with the xDECAF paper (Arp, Boltz, Hahner, Heinrich, Hüller, Niehues). While internal adoption demonstrates extensibility, framing it as independent evidence of utility is an overstatement. The paper should explicitly acknowledge the authorship overlap and clarify that these applications demonstrate extensibility and integration capability rather than independent community validation.
minor comments (4)
  1. §3: The text states 'over 20 example models' while the abstract says 'over 20' and the body later specifies '26 models.' For consistency, the abstract and §1 could be updated to reflect the precise count.
  2. §3: The performance statement 'For smaller models (e.g., > 20 nodes), xDECAF takes > 1 second' is slightly ambiguous; it would be clearer to say 'models with more than 20 nodes' or provide a more precise characterization of the performance curve.
  3. Figure 1: The figure is referenced but the resolution and labeling in the provided text are difficult to parse. Ensure that labels, pins, and assignments are clearly legible in the final version.
  4. §2: The DSL wiki link (footnote 1) is dated '11.05.2026.' Ensure that all external links and references are accessible and up-to-date at the time of publication.

Simulated Author's Rebuttal

2 responses · 0 unresolved

We thank the referee for the constructive assessment and the positive recommendation. Both major comments are well-taken, and we will revise the manuscript accordingly.

read point-by-point responses

  1. Referee: §5, External Validation: The paper states that 17 of 132 microSecEnD variants produced diverging results and that 'manual inspection' traced all discrepancies to 'faults in the manually created microSecEnD variants.' No breakdown or characterization of these 17 faults is provided. A concrete breakdown is needed to substantiate the claim that none of the discrepancies stemmed from the transformation from PlantUML or the constraint formalization in xDECAF.

    Authors: The referee is correct that the current manuscript does not provide sufficient detail for a reader to independently assess the attribution of the 17 discrepancies. We will add a table to §5 (or an appendix, space permitting) that categorizes each of the 17 diverging variants by discrepancy type. Based on our manual inspection, the faults fall into categories such as: (a) repair variants that do not actually resolve the intended data flow violation (i.e., the DFD still contains a violating flow), (b) repair variants that introduce new unintended flows, (c) incorrect or incomplete label annotations in the manually created variants, and (d) structural inconsistencies between the original DFD and its repair variant (e.g., removed nodes that break intended flows). For each category, we will note the number of affected variants and briefly describe a representative example. We will also clarify the inspection methodology: each diverging variant was checked by comparing the xDECAF analysis result against the expected result documented in microSecEnD, and the root cause was traced to the model rather than the PlantUML-to-DFD transformation or the constraint evaluation. This additional detail will allow readers to judge the soundness of the attribution. revision: yes

  2. Referee: §1 and §5: The paper claims that downstream research adoption provides 'concrete evidence of its utility.' However, the majority of the cited downstream works share coauthors with the xDECAF paper. The paper should explicitly acknowledge the authorship overlap and clarify that these applications demonstrate extensibility and integration capability rather than independent community validation.

    Authors: The referee raises a valid point. We agree that the current framing overstates the independence of the adoption evidence. Most of the cited downstream works [5, 6, 7, 9, 10, 16, 17, 18, 19, 22] do share coauthors with this paper, and we should be transparent about this. We will revise §1 and §5 to explicitly acknowledge the authorship overlap and reframe the claim. Specifically, we will change the language from 'concrete evidence of its utility' to language that accurately characterizes these works as demonstrating extensibility, integration capability, and applicability to diverse analysis problems. We will note that independent community adoption remains a goal for the future and that the current evidence is primarily from within our own research group and collaborators. The microSecEnD integration [17, 24] does represent an external dataset, but we will be careful not to conflate external data with independent adoption of the tool itself. revision: yes

Circularity Check

0 steps flagged

No formal circularity; the paper is a tool description, not a derivation chain. Heavy self-citation in adoption evidence is a validation weakness, not circularity.

full rationale

This is a tool paper, not a paper claiming first-principles derivations or predictions. The central technical content — the extended DFD metamodel (labels, pins, assignments), the constraint DSL with flow verbs, and the propagation logic — is described self-contained in §2. The paper defers detailed evaluation to prior work [4] (Boltz et al., ECSA 2023, sharing coauthor Boltz), but this is standard incremental building on one's own prior publication, not a circular definition where the output equals the input by construction. The 'concrete evidence of utility' claim (§1, §5) rests on downstream adoption citations, many of which share coauthors with this paper ([5,6,7,9,10,12,16,17,18,19]). However, the framework is not defined by its adoption, nor are the adoption claims tautological — the downstream works apply xDECAF to new problems (Zero Trust, uncertainty, legal compliance, repair). The microSecEnD 'external validation' (§5) is self-assessed by xDECAF coauthors [17], who attribute all 17/132 divergences to dataset faults rather than tool errors. This is a legitimate confirmation-bias and validation-strength concern, but it is not formal circularity: the tool's behavior on external models is not defined to be correct by construction. No equation, definition, or prediction in the paper reduces to its own inputs. Score 2 reflects the presence of load-bearing self-citation ([4] for core validation, [17] for external validation) that is not independently verified, but the paper's claims about extensibility and tool capabilities are self-contained and externally falsifiable (the tool and dataset are open-source).

Axiom & Free-Parameter Ledger

0 free parameters · 4 axioms · 3 invented entities

No free parameters are fitted — this is a tool paper, not an empirical model. The axioms are domain assumptions standard to DFD-based security analysis. The 'invented entities' are metamodel extensions (Pins, Assignments, flow verbs) that are modeling constructs rather than physical postulates; each has demonstrated utility through the example catalog and downstream research. The cycle-resolution heuristic [3] is the most fragile axiom since it is cited from a workshop paper with overlapping authorship.

axioms (4)
  • domain assumption DFDs are an adequate notation for representing system structure relevant to information security analysis (§1, citing [20, 27])
    Standard assumption in the DFD-based security analysis literature; not novel to this paper.
  • domain assumption Label propagation along data flows correctly models how security-relevant metainformation traverses a system (§2, deferring to [4])
    Core assumption of the xDECAF framework; validated in prior ECSA publication but assumed here.
  • domain assumption Heuristics for resolving cycles in data flows produce sound analysis results (§2, citing [3])
    Cyclic DFDs are common; the heuristic approach is cited from a Softwaretechnik-Trends workshop paper by overlapping authors. Soundness of this heuristic is not independently verified in this paper.
  • ad hoc to paper Downstream research adoption constitutes evidence of framework utility (§1, §5)
    The paper's validation strategy treats adoption by research lines (many with shared coauthors) as evidence. This is a reasonable but not rigorous validation criterion for a tool paper.
invented entities (3)
  • Pins (Input/Output interfaces on DFD nodes) independent evidence
    purpose: Enable fine-grained modeling of multiple independent data paths into a node and parallel flows out of a node
    Pins are a metamodel extension over standard DFDs; their utility is demonstrated in the example catalog and downstream research. Not a physical entity but a modeling construct.
  • Assignments (on Output Pins) independent evidence
    purpose: Define conditional logical statements controlling how labels are propagated along connected flows
    Modeling construct; demonstrated in Fig. 1 and Listing 1. Utility shown through 26-model catalog.
  • Flow verbs (flows, alwaysFlows, neverFlows, notAlwaysFlows) independent evidence
    purpose: Map constraint language to first-order logic quantifiers over the set of flows between matched sources and destinations
    DSL construct with formal semantics defined in §2. Not a postulated entity but a language design choice.

pith-pipeline@v1.1.0-glm · 11123 in / 3108 out tokens · 424547 ms · 2026-07-08T20:39:26.111657+00:00 · methodology

0 comments
read the original abstract

xDECAF is an extensible tool for architecture-based data flow analysis with a focus on information security. It combines an extended data flow diagram metamodel of labeled flows and nodes, a domain-specific constraint language with different flow operations, and a browser-based editor backed by an analysis engine. In this paper, we present the xDECAF tool library and a curated catalog of over 20 example models with documented constraints and expected violations, intended as a reusable dataset for the community. The tool has already been adopted by several research lines, providing concrete evidence of its utility. The tool, dataset, and a hosted online editor are publicly available.

Figures

Figures reproduced from arXiv: 2607.05913 by Alexander Vogt, Benjamin Arp, Felix Schwickerath, Nicolas Boltz, Nils Niehues, Tom H\"uller.

Figure 1
Figure 1. Figure 1: Extended DFD Example in xDECAF online editor. [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

32 extracted references · 32 canonical work pages · 1 internal anchor

  1. [1]

    Hanaa Alshareef, Katja Tuma, Sandro Stucki, et al. 2022. Precise analysis of pur- pose limitation in data flow diagrams. InInternational Conference on A vailability, Reliability and Security (ARES). ACM, 1–11. doi:10.1145/3538969.3539010

    work page doi:10.1145/3538969.3539010 2022

  2. [2]

    Benjamin Arp et al. 2026. Dataset. doi:10.5281/zenodo.20083877

    work page doi:10.5281/zenodo.20083877 2026

  3. [3]

    Benjamin Arp, Nils Niehues, Tom Hüller, et al. 2024. Analyzing Cyclic Data Flow Diagrams Regarding Information Security. InSoftwaretechnik-Trends. Gesellschaft für Informatik eV

    work page 2024

  4. [4]

    Nicolas Boltz, Sebastian Hahner, Christopher Gerking, et al. 2023. An extensible framework for architecture-based data flow analysis for information security. In European Conference on Software Architecture (ECSA). Springer, 342–358. doi:10. 1007/978-3-031-66326-0_21

    work page 2023

  5. [5]

    Nicolas Boltz, Larissa Schmid, Bahareh Taghavi, et al. 2024. Modeling and Analyz- ing Zero Trust Architectures Regarding Performance and Security. InEuropean Conference on Software Architecture (ECSA). Springer, 253–269. doi:10.1007/978- 3-031-70797-1_17

    work page doi:10.1007/978- 2024

  6. [6]

    Nicolas Boltz, Leonie Sterz, Oliver Raabe, et al. 2026. Enabling a model-driven workflow for ongoing interdisciplinary collaboration in legal threat modeling. Information and Software Technology (IST)195 (2026), 108121. doi:10.1016/j.infsof. 2026.108121

    work page doi:10.1016/j.infsof 2026

  7. [7]

    Nicolas Boltz, Leonie Sterz, Oliver Raabe, et al. 2026. Towards Legal Knowledge Transfer Based on Software Architecture. InEuropean Conference on Software Architecture (ECSA). Springer, 332–340. doi:10.1007/978-3-032-02138-0_22

    work page doi:10.1007/978-3-032-02138-0_22 2026

  8. [8]

    Sophie Corallo, Debora Grupp, Dominik Fuchß, et al . 2026. The EVerest Dataset for Secure Software Engineering. InInternational Conference on Automated Soft- ware Engineering (ASE). IEEE/ACM. doi:10.48550/arXiv.2606.23197 (to appear)

    work page internal anchor Pith review Pith/arXiv arXiv doi:10.48550/arxiv.2606.23197 2026

  9. [9]

    Sebastian Hahner, Tizian Bitschi, et al. 2023. Model-based confidentiality analysis under uncertainty. InInternational Conference on Software Architecture Companion (ICSA-C). IEEE, 256–263. doi:10.1109/ICSA-C57050.2023.00062

    work page doi:10.1109/icsa-c57050.2023.00062 2023

  10. [10]

    Sebastian Hahner, Robert Heinrich, and Ralf Reussner. 2023. Architecture-Based Uncertainty Impact Analysis to Ensure Confidentiality. InSymposium on Software Engineering for Adaptive and Self-Managing Systems (SEAMS). IEEE, 126–132. doi:10.1109/SEAMS59076.2023.00026

    work page doi:10.1109/seams59076.2023.00026 2023

  11. [11]

    Marc Heinrich, Maximilian Zipfl, Marc Uecker, et al . 2024. CoCar NextGen: A Multi-Purpose Platform for Connected Autonomous Driving Research. In International Conference on Intelligent Transportation Systems (ITSC). IEEE, 482–

    work page 2024

  12. [12]

    doi:10.1109/ITSC58415.2024.10920249

    work page doi:10.1109/itsc58415.2024.10920249 2024

  13. [13]

    Tom Hüller, Felix Schwickerath, Benjamin Arp, et al. 2024. Towards a Data Flow Diagram-Centric Confidentiality Analysis in Palladio. InSoftwaretechnik-Trends. Gesellschaft für Informatik eV

    work page 2024

  14. [14]

    Jan Jürjens. 2002. UMLsec: Extending UML for secure systems development. In International Conference on The Unified Modeling Language. Springer, 412–425. doi:10.1007/3-540-45800-X_32

    work page doi:10.1007/3-540-45800-x_32 2002

  15. [15]

    2010.Model-driven risk analysis: the CORAS approach

    Mass Soldal Lund, Bjørnar Solhaug, and Ketil Stølen. 2010.Model-driven risk analysis: the CORAS approach. Springer Science & Business Media

    work page 2010

  16. [16]

    2024.Wir wissen, wo dein Auto steht

    Linus Neumann. 2024.Wir wissen, wo dein Auto steht. https://www.ccc.de/de/ updates/2024/wir-wissen-wo-dein-auto-steht

    work page 2024

  17. [17]

    Nils Niehues, Benjamin Arp, and Robert Heinrich. 2026. Efficient Repair of Confidentiality Violations in Software Architectures. InInternational Conference on Software Architecture (ICSA). IEEE. (to appear)

    work page 2026

  18. [18]

    Nils Niehues, Benjamin Arp, Tom Hüller, et al . 2024. Integrating Security- Enriched Data Flow Diagrams Into Architecture-Based Confidentiality Analysis. InSoftwaretechnik-Trends. Gesellschaft für Informatik eV

    work page 2024

  19. [19]

    Nils Niehues, Sebastian Hahner, et al. 2025. Mitigation Strategies for Confiden- tiality Violations in Software Architecture Using Ranked Feature Importance. Journal of Systems and Software (JSS)(2025), 112761. doi:10.1016/j.jss.2025.112761

    work page doi:10.1016/j.jss.2025.112761 2025

  20. [20]

    Nils Niehues, Sebastian Hahner, and Robert Heinrich. 2025. An Architecture- Based Approach to Mitigate Confidentiality Violations Using Machine Learning. InInternational Conference on Software Architecture (ICSA). IEEE, 107–118. doi:10. 1109/ICSA65012.2025.00020

    work page arXiv 2025

  21. [21]

    OWASP Foundation. 2024. OWASP Threat Dragon. https://owasp.org/www- project-threat-dragon/. accessed: 2026-04-27

    work page 2024

  22. [22]

    Sven Peldszus, Katja Tuma, Daniel Strüber, et al. 2019. Secure Data-Flow Com- pliance Checks between Models and Code Based on Automated Mappings. In International Conference on Model Driven Engineering Languages and Systems (MODELS). IEEE, 23–33. doi:10.1109/MODELS.2019.00-18

    work page doi:10.1109/models.2019.00-18 2019

  23. [23]

    Frederik Reiche, Ralf Reussner, and Robert Heinrich. 2025. Detecting Information Flow Security Vulnerabilities by Analysis Coupling.IEEE Transactions on Software Engineering (TSE)51, 10 (2025), 2710–2743. doi:10.1109/TSE.2025.3589647

    work page doi:10.1109/tse.2025.3589647 2025

  24. [24]

    2016.Modeling and Simulating Software Architectures – The Palladio Approach

    Ralf H Reussner, Steffen Becker, Jens Happe, et al. 2016.Modeling and Simulating Software Architectures – The Palladio Approach. MIT Press. 377 pages

    work page 2016

  25. [25]

    Simon Schneider, Tufan Özen, Michael Chen, et al. 2023. microSecEnD: A Dataset of Security-Enriched Dataflow Diagrams for Microservice Applications. InIn- ternational Conference on Mining Software Repositories (MSR). IEEE, 125–129. doi:10.1109/MSR59073.2023.00030

    work page doi:10.1109/msr59073.2023.00030 2023

  26. [26]

    Stephan Seifermann, Robert Heinrich, et al. 2022. Detecting violations of access control and information flow policies in data flow diagrams.Journal of Systems and Software (JSS)184 (2022), 111138. doi:10.1016/j.jss.2021.111138

    work page doi:10.1016/j.jss.2021.111138 2022

  27. [27]

    Stephan Seifermann, Robert Heinrich, and Ralf Reussner. 2019. Data-Driven Software Architecture for Analyzing Confidentiality. InInternational Conference on Software Architecture (ICSA). IEEE, 1–10. doi:10.1109/ICSA.2019.00009

    work page doi:10.1109/icsa.2019.00009 2019

  28. [28]

    Adam Shostack. 2008. Experiences Threat Modeling at Microsoft. InModel- ing Security Workshop. https://shostack.org/files/papers/modsec08/Shostack- ModSec08-Experiences-Threat-Modeling-At-Microsoft.pdf

    work page 2008

  29. [29]

    Laurens Sion, Koen Yskout, Dimitri Van Landuyt, et al. 2018. Solution-aware data flow diagrams for security threat modeling. InSymposium on Applied Computing (SAC). ACM, 1425–1432. doi:10.1145/3167132.3167285

    work page doi:10.1145/3167132.3167285 2018

  30. [30]

    Katja Tuma, Christian Sandberg, Urban Thorsson, et al. 2021. Finding security threats that matter: Two industrial case studies.Journal of Systems and Software (JSS)179 (2021), 111003. doi:10.1016/j.jss.2021.111003

    work page doi:10.1016/j.jss.2021.111003 2021

  31. [31]

    Katja Tuma, Riccardo Scandariato, and Musard Balliu. 2019. Flaws in Flows: Un- veiling Design Flaws via Information Flow Analysis. InInternational Conference on Software Architecture (ICSA). IEEE, 191–200. doi:10.1109/ICSA.2019.00028

    work page doi:10.1109/icsa.2019.00028 2019

  32. [32]

    Dimitri Van Landuyt. 2025. Privacy Impact Tree Analysis (PITA): A Tree-Based Privacy Threat Modeling Approach.IEEE Transactions on Software Engineering (TSE)51, 7 (2025), 2102–2124. doi:10.1109/TSE.2025.3573380

    work page doi:10.1109/tse.2025.3573380 2025