Exploring the Relationship Between Architecture Coupling and Software Vulnerabilities

Robert  Lagerstrom; Carliss Y. Baldwin; Alan   MacCormack; Daniel  J. Sturtevant; Lee  Doolan

Other Article | Proceedings of the International Symposium on Engineering Secure Software and Systems (ESSoS)

Exploring the Relationship Between Architecture Coupling and Software Vulnerabilities

by Robert Lagerstrom, Carliss Y. Baldwin, Alan MacCormack, Daniel J. Sturtevant and Lee Doolan

Abstract

Employing software metrics, such as size and complexity, for predicting defects has been given a lot of attention over the years and proven very useful. However, the few studies looking at software architecture and vulnerabilities are limited in scope and findings. We explore the relationship between software vulnerabilities and component metrics (like code churn and cyclomatic complexity), as well as architecture coupling metrics (direct, indirect, and cyclic coupling). Our case is based on the Google Chromium project, an open source project that has not been studied for this topic yet. Our findings show a strong relationship between vulnerabilities and both component level metrics and architecture coupling metrics. 68% of the files associated with a vulnerability are cyclically coupled, compared to 43% of the non-vulnerable files. Our best regression model is a combination of low commenting, high code churn, high direct fan-out within the main cyclic group, and high direct fan-in outside of the main cyclic group.

Keywords: Security vulnerabilities; Software architecture; metrics; Software; Complexity; Measurement and Metrics;

Format: Print

Find at Harvard Read Now

Citation:

Lagerstrom, Robert, Carliss Y. Baldwin, Alan MacCormack, Daniel J. Sturtevant, and Lee Doolan. "Exploring the Relationship Between Architecture Coupling and Software Vulnerabilities." Proceedings of the International Symposium on Engineering Secure Software and Systems (ESSoS) 9th (2017): 53–69. (Part of Lecture Notes in Computer Science, ISSN 0302-9743.)

Existing application performance management (APM) solutions lack robust anomaly detection capabilities and root cause analysis techniques that do not require manual efforts and domain knowledge. In this paper, we develop a density-based unsupervised machine learning model to detect anomalies within an enterprise application, based upon data from multiple APM systems. The research was conducted in collaboration with a European automotive company, using two months of live application data. We show that our model detects abnormal system behavior more reliably than a commonly used outlier detection technique and provides information for detecting root causes.

Working Paper | HBS Working Paper Series | 2019

Design Rules, Volume 2: How Technology Shapes Organizations: Chapter 13 Platform Systems vs. Step Processes—The Value of Options and the Power of Modularity

Carliss Y. Baldwin

This is the first chapter in Part 3. Its purpose is to contrast the value structure of platform systems with step processes from a technological perspective. I first review the basic technical architecture of computers and argue that every computer is inherently a platform for performing computations as dictated by their programs. I state and prove five propositions about platform systems, which stand in contrast to the propositions derived for step processes in Chapter 8. The propositions suggest that platform systems and step processes call for different forms of organization. Specifically, step processes reward technical integration, unified governance, risk aversion, and the use of direct authority, while platform systems reward modularity, distributed governance, risk taking, and autonomous decision-making. Despite these differences, treating platform systems and step processes as mutually exclusive architectures sets up a false dichotomy. Creating any good requires carrying out a technical recipe, i.e., performing a series of steps. Step processes in turn can be modularized (at the cost of lower efficiency) by creating buffers between steps. I show that the optimal number of modules (and buffers) increases as the underlying rate of technical change goes up. When the underlying technologies are changing rapidly, it makes sense to sacrifice some degree of flow efficiency for options to mix-and-match modular components.

Keywords: platform systems; step processes; computer architecture; modularity; Technology;

Citation:

Baldwin, Carliss Y. "Design Rules, Volume 2: How Technology Shapes Organizations: Chapter 13 Platform Systems vs. Step Processes—The Value of Options and the Power of Modularity." Harvard Business School Working Paper, No. 19-073, January 2019. View Details

Cite View Details SSRN Read Now

The IBM PC was the first digital computer platform that was open by as a matter of strategy, not necessity. The purpose of this chapter is to understand the IBM PC as a technical system and set of organization choices in light of the theory of how technology shapes organizations. In Chapter 7, I argued that sponsors of large technical systems (including platform systems) must manage the modular structure of the system and property rights in a way that solves four inter-related problems: provide all essential functional components, solve system-wide technical bottlenecks wherever they emerge, control and protect one or more strategic bottleneck, and prevent others from gaining control of any system-wide strategic bottleneck. I use this framework to understand how IBM initially succeeded with the PC platform and then lost its position as platform sponsor in the industry it had created.

Faculty & Research

Exploring the Relationship Between Architecture Coupling and Software Vulnerabilities

Abstract

Citation:

About the Authors

More from these Authors