Risks Relating to System Compositions

The challenge of developing systems with complex sets of requirements seems to be inherently complicated, despite persistent advice to keep it simple. However, consider the goal of building trustworthy systems using predictably sound compositions of well-designed components along with analysis of the properties that are preserved or transformed, or that emerge, from the compositions. Conceptually, that should considerably simplify and improve development, especially if we follow the paths of David Parnas, Edsger Dijkstra, and others. Unfortunately, there is a huge gap between theory and common practice: system compositions at present are typically ad hoc, based on the intersection of potentially incompatible component properties, and dependent on untrustworthy components that were not designed for interoperability—often resulting in unexpected results and risks.

Composition is meaningful with respect to many entities such as requirements, specifications, protocols, hardware/software implementations, and evaluations. The ability to predict the effects of such compositions analytically might follow simply from a proactive combination including good system architecture, system design, sound software engineering, sensible programming languages, compilers, and supporting tools, with attention to assurance throughout development. However, various difficulties can hinder predictable composition:

Inadequate requirements and architectures. "If a program has not been specified, it cannot be incorrect; it can only be surprising." (Young, Boebert, and Kain). Its composability with other programs is also likely to be surprising. Unfortunately, system specifications are always inherently incomplete, even though we desire that they completely and correctly define the relationships among modules and their interfaces, inputs, state transitions, internal state information, outputs, and exception conditions.

Poor software engineering. The absence of sensible abstraction, modular encapsulation, information hiding, and other sound principles (for example, Saltzer-Schroeder) can seriously impede composability, as can riskful programming languages, undisciplined programming practices, and unwary use of analysis tools.

Multiparty incompatibilities. If proactively designed, heterogeneous systems could mix and match alternative components, enabling interoperability among disparate developers. However, incompatibilities among interface assumptions, the existence of proprietary internal and external interfaces, and extreme performance degradations resulting from the inability to optimize across components can result in compositional snafus.

Scalability issues. Composability can create scalability problems. Performance may degrade badly or nonpredictably as subsystems are conjoined. Further degradations can result—for example, from design flaws, software bugs, and indirect effects of the composition. Other aspects of composability also are relevant.

Policy composability. Policies for security, integrity, privacy, and safety components (especially when incomplete) often cannot compose without contradictions and unrecognized emergent properties.

Protocol composability. Network and cryptographic protocols are a source of risks. Compositions often introduce security flaws and performance problems. For example, end-to-end solutions often ignore denial-of-service attacks.

Assurance composability. Ideally, we should be able to reason about entire systems based on the properties of their components, perhaps even with provably sound combinations of provably sound components. That is, analytic techniques should be composable. However, if the properties are not composable, the analysis results probably aren’t either.

Certification composability. Deriving system certifications from the components is also fraught with hidden problems. For example, John Rushby has characterized the main issues relating to certification of aircraft based on certifications of their components (see www.csl.sri.com/rushby/abstracts/modcert).

Various approaches to achieving predictable composability are noted at www.csl.sri.com/neumann/chats4.html. Dramatic improvements are needed in system development and particularly in design for evolvability. More research is needed to establish unified theories and practices to enable predictable compositions, and these concepts must be brought into the development and education mainstreams. In any event, composability represents a very difficult problem, especially in legacy software.

Back to Top