Skip to main content

Currently Skimming:

4 Adopt a Strategic Approach to Software Assurance
Pages 86-111

The Chapter Skim interface presents what we've algorithmically identified as the most significant single chunk of text within every page in the chapter.
Select key terms on the right to highlight them within pages of the chapter.


From page 86...
... , September 2007, Report of the Defense Science Board Task Force on Mission Impact of Foreign Influence on DoD Software, Washington, DC: Office of the Undersecretary of Defense for Acquisition, Technology, and Logistics, at pp.
From page 87...
... In practice, assurance judgments are based on application of a broad range of techniques that include both preventive and evaluative methods and that are applied throughout a software engineering process. Indeed, for modern systems, and not just critical systems, the design of a software process is driven not only by issues related to engineer ing risk and uncertainty, but also, in a fundamental way, by quality considerations.
From page 88...
... operational insiders -- ad versaries gaining access to a DoD software system through inappropriate privileging, compromised physical access, or compromised personnel, and (3) engineering insiders -- adversaries influencing or participating in the engineering process at some point in the supply chain for an overall system.
From page 89...
... 4 See http://www.trustedcomputinggroup.org/. 5 DSB, September 2007, Report of the Defense Science Board Task Force on Mission Impact of Foreign Influence on DoD Software, Washington, DC: Office of the Under Secretary of Defense for Acquisition, Technology, and Logistics.
From page 90...
... One mechanism, embodied in the Common Criteria model, is the use of mutually trusted third parties to support assur ance activities. A key issue is how that evaluation can be done such that two goals are addressed: (1)
From page 91...
... 5 Defense Science Board (DSB) , 2007, Report of the Defense Science Board Task Force on Mission Impact of Foreign Influence on DoD Software, Office of the Under Secretary of Defense for Acquisition, Technology, and Logistics.
From page 92...
... In this case, engineers acted on a false supposition regarding the extent of error containment by a hardware mechanism in operations, resulting in fatal x-ray doses being administered to cancer patients. Underlying both preventive and evaluative methods are the two most critical broad influences on quality: judicious choice of process and practices, and the capability and training of the people involved in the process.
From page 93...
... Its results are usually tightly targeted to very particular attributes and can lead fairly directly to repairs. Heuristic static analysis results, such as from open-source tools PMD and FindBugs, have considerably broader coverage than targeted sound analysis.
From page 94...
... Adopt secure coding practices and more transparent structured coding styles that facilitate the various evaluative methods. • Programming language.
From page 95...
... • Verification of code against specifications. A number of formal "positive verification" capabilities have become practical in recent years for two reasons: First, scalability and usability are more readily achievable when verification is targeted to particular quality attributes.2 Second, new techniques are emerging, based on model checking or sound analysis that support this more targeted verification without excessive requirements for writing formal specifications and assertions in code.
From page 96...
... , static analysis, formal verification and model checking (for code, designs, specifications, and models) , and dynamic analysis and monitoring (for code, design, and models)
From page 97...
... may present formidable barriers to evaluative methods in achieving confident assurance judgments when compared, for example, with well-structured programs in modern languages such as C#, Java, and Ada that have comparable functionality.12 In these latter cases, "well-structured" means two things: First, modular structures can be crafted using modern type systems to replace tangled complexity with organization. Second, intrinsic support for information hiding and encapsulated data simplifies the structure of the various links in the chain of evidence that need to be constructed.
From page 98...
... When development teams see immediate benefits from the evidentiary material, they are naturally led to adopt a broader range of preventive practices to create additional links in the chain of evidence. It is increasingly apparent that modern assurance techniques can provide immediate benefits in the form of direct feedback loops and greater transparency in the processes imple mented by small teams and even by individual developers.
From page 99...
... Software producibility is directly influenced not only by the extent of design-related information that is retained and managed, but also by the means by which this design-related information is rep resented.17 There are four dimensions of representation that are most significant. These are formality, modeling, consistency, and usability.
From page 100...
... These more scalable approaches include model checking, sound static analysis, and some approaches based on assertion-passing verification. Because they focus more narrowly on particular quality or functional attributes, these approaches have achieved success in professional development practice.
From page 101...
... Tools such as model checkers and static analysis tools are informed by formal specification frag ments, which are a kind of model. These are sometimes expressed in self-contained specifications (e.g., linear temporal logic specifications or Alloy specifications for model checkers)
From page 102...
... Success in achieving this "early gratification" is one of the reasons why unit testing has caught on, and model checking and analysis are also emerging into practice.23 Finding 4-2: Assurance is facilitated by advances in diverse aspects of software engineering practice and technology, including modeling, analysis, tools and environments, traceability, programming languages, and process support. Advances focused on simultaneous creation of assurance-related evidence with ongoing development effort have high potential to improve the overall assurance of systems.
From page 103...
... Complexity and Supply Chains An additional complicating factor in software assurance for defense is the changing character of the architecture and supply structure for software systems generally, including defense software sys tems. The changes, which are enabled by advances in the underlying software technologies, particu larly related to languages, tools, and runtime architectures, allow for more complex architectures and richer and more diverse supply chains.
From page 104...
... This is a great success in reuse, but there is also great complexity. Frameworks provide aggregate function alities such as graphical user interaction, application server capability, web services support, mobile device capabilities, software development environments, enterprise resource planning (ERP)
From page 105...
... 26 DSB, 2007, Report of the Defense Science Board Task Force on Mission Impact of Foreign Influence on DoD Software , Washington, DC: Office of the Under Secretary of Defense for Acquisition, Technology, and Logistics. Available online at http://stinet.dtic.
From page 106...
... Because of the diversity of attributes of the models that can trace to the identified failures and hazards, multiple modeling exercises are likely to be undertaken, each focusing on particular attributes. When the models can be rendered formally, then tools for semi-automated analysis can be used for model checking, theorem proving, static analysis (at model level)
From page 107...
... These analyses may involve the construction of vari ous kinds of abstract models that can themselves be analyzed to assess various functional and quality attributes. This activity is facilitated when models can be made more formal -- informally expressed models necessarily require people to make interpretations and assessments.
From page 108...
... A key difference is that the component-level modeling, combined with the supply-chain appraisal, provides an early feedback mechanism regarding engineering risks in the evolving architecture design. Risks can be assessed related not only to quality attributes and technical feasibility, but also to sourcing costs and risks.
From page 109...
... At this stage of the pro cess, that proposal can be considered in the light of how it might influence assurance with respect to quality attributes, interface compliance, correct functionality, and other factors. The decision could be made not to change the programming language, but rather to incentivize the vendor to make the next set of improvements in its compiler technology.
From page 110...
... . Recommendation 4-1: Effective incentives for preventive software assurance practices and produc tion of evidence across the lifecycle should be instituted for prime contractors and throughout the supply chain.
From page 111...
... and analysis tools (such as SLAM, PreFast, and others -- see, for example Thomas Ball, 2008, "The Verified Software Challenge: A Call for a Holistic Approach to Reliability, " pp. 42-48 in Verified Software: Theories, Tools, Experiments, Bertrand Meye and Jim Woodcock, eds.


This material may be derived from roughly machine-read images, and so is provided only to facilitate research.
More information on Chapter Skim is available.