The emergence of DevOps is accompanied by an increased use of Infrastructure as Code (IaC) to specify and manage deployment configurations, infrastructure, and associated resources. Terraform is one such IaC solution. However, improper configurations can lead to serious security threats. This paper introduces an approach, implemented as TerrARA, that provides a systematic and structured way for automatically eliciting security threats based on Terraform configuration files. Specifically, TerrARA: (1) automates the construction of an abstract model-an enriched Data Flow Diagram (DFD)-from Terraform configuration files for Amazon Web Services (AWS), and it can be extended to other resources and cloud providers via profiles; (2) encodes cloud computing threat patterns, which are utilized by the SPARTA threat modeling engine to automatically identify security threats; and (3) demonstrates its capability in accurately extracting DFDs from Terraform projects and eliciting relevant cloud computing security threats, achieving high accuracy and reasonable performance compared to existing tools and approaches like StartLeft and GPT-4o. By integrating it into CI/CD pipelines, the automated reconstruction and analysis enable continuous security assessments that systematically incorporate cloud infrastructure artifacts into the threat modeling process.

Security by design is a key principle for realizing secure software systems and it is advised to hunt for security flaws from the very early stages of development. At design-time, security analysis is often performed manually by means of either threat modeling or expert-based design inspections. However, when leveraging the wide range of established knowledge bases on security design flaws (e.g., CWE, CAWE), these manual assessments become too time consuming, error-prone, and infeasible in the context of contemporary development practices with frequent iterations. This paper focuses on design inspection and explores the potential for automating the application of inspection rules to speed up the security analysis.

Data Protection by Design (DPbD) is a truly interdisciplinary effort that involves many stakeholders such as legal experts, requirements engineers, software architects, developers, and system operators. Building software-intensive systems that respect the fundamental rights to privacy and data protection is the result of intensive dialogue and careful trade-off decisions. In practice however, there is a dichotomy between the legal reasoning which is conducted in Data Protection Impact Assessments (DPIA) and software engineering approaches, such as threat modeling, aimed at identifying privacy requirements and privacy risks. These activities are commonly performed in total isolation, which negatively impacts (i) the compliance exercise, (ii) the ability to evolve the system over time, and (iii) the architectural trade-offs made during system design. In this article, we present an architectural viewpoint for describing software architectures from a legal, data protection perspective whose core modeling abstractions are based on an in-depth legal analysis of the EU General Data Protection Regulation. This viewpoint is tied to Data Flow Diagrams-commonly used in threat modeling-through correspondence rules. The proposed viewpoint supports the automation of a number of data protection impact assessment steps through (i) meta-model constraints, (ii) model analysis, and (iii) interaction with the involved stakeholders. This enables a streamlined compliance exercise, reconciling legal privacy and data protection notions with architecture-driven software engineering practices. We validate our approach in the context of a realistic e-health application for a number of complementary development scenarios.

Software product line engineering is a compelling methodology that accomplishes systematic reuse in families of systems by relying on two key principles: (i) the decomposition of complex systems into composable and reusable building blocks (often logical units called features), and (ii) on-demand construction of products and product variants by composing these building blocks.

With the increasingly pervasive role of software in society, security is becoming an important quality concern, emphasizing security by design, but it requires intensive specialization.

Security decisions are an important part of software architecture design, and thus deserve to be explicitly represented in the design documentation. While UML is the best-known language for creating such documentation, it lacks security specific notations, which makes it difficult to represent the effect of the security decisions. Several security extensions for UML exist in the literature, but they represent security concerns at a lower level of abstraction, or only support a limited subset of security concerns. We propose a new notation, MASC, to model security concerns at the architectural level. It has been designed as an extension of UML, and is based on recurring security concepts that have been distilled from well-known security principles, goals, and patterns. By using our notation, a designer obtains a technique to express security concerns more explicitly in the architectural design documentation.