Software Component Certification: 10 Useful Distinctions

Abstract

Using software components to develop mission-critical systems poses a number of technical, organizational, and economic challenges. One persistent and largely unaddressed challenge is how the consumers of software components—that is, the developers of mission-critical systems—can obtain a meaningful level of trust in the runtime behavior of software components. The most frequently cited concerns are centered on issues of security; for example, trust that a component does not contain malicious code or exhibit vulnerabilities that can be exploited by malicious code. There are, however, other concerns about software component behavior that can be just as important. For example, in an embedded weapon system, it may be crucial to trust that a component will always execute a function within a particular time bound or never introduce unbounded priority inversion. Certification is a practical, proven means of establishing trust in various sorts of things in other disciplines and is, therefore, a natural contender for developing trust in software components. This technical note does not propose a particular certification regimen for components. Rather, it introduces a series of 10 distinctions that can help in understanding different aspects of certification in the context of software components