Paul E. Black

Mutation operators for specifications

Testing has a vital support role in the software engineering process, but developing tests often takes significant resources. A formal specification is a repository of knowledge about a system, and a recent method uses such specifications to automatically generate complete test suites via mutation analysis. We define an extensive set of mutation operators for use with this method. We report the results of our theoretical and experimental investigation of the relationships between the classes of faults detected by the various operators. Finally, we recommend sets of mutation operators which yield good test coverage at a reduced cost compared to using all proposed operators.

Comparison of fault classes in specification-based testing

Abstract Our results extending Kuhns fault class hierarchy provide a justification for the focus of fault-based testing strategies on detecting particular faults and ignoring others. We develop a novel analytical technique which allows us to elegantly prove that the hierarchy applies to arbitrary expressions, not just those in disjunctive normal form. We also use the technique to extend the hierarchy to a wider range of fault classes. To demonstrate broad applicability, we compare faults in practical situations and analyze previous results. In particular, using our technique, we show that the basic meaningful impact strategy of Weyuker et al. tests for stuck-at faults, not just variable negation faults.

Juliet 1.1 C/C++ and Java Test Suite

Juliet Test Suite 1.1 offers test cases for assessing the effectiveness of static analyzers and other software-assurance tools.

Mutation of model checker specifications for test generation and evaluation

Mutation analysis on model checking specifications is a recent development. This approach mutates a specification, then applies a model checker to compare the mutants with the original specification to automatically generate tests or evaluate coverage. The properties of specification mutation operators have not been explored in depth. We report our work on theoretical and empirical comparison of these operators. Our future plans include studying how the form of a specification influences the results, finding relations between different operators, and validating the method against independent metrics.

Effect of static analysis tools on software security: preliminary investigation

Static analysis tools can handle large-scale software and find thousands of defects. But do they improve software security? We evaluate the effect of static analysis tool use on software security in open source projects. We measure security by vulnerability reports in the National Vulnerability Database.

Quantum Computing and Communication

Abstract A quantum computer, if built, will be to an ordinary computer as a hydrogen bomb is to gunpowder, at least for some types of computations. Today no quantum computer exists, beyond laboratory prototypes capable of solving only tiny problems, and many practical problems remain to be solved. Yet the theory of quantum computing has advanced significantly in the past decade, and is becoming a significant discipline in itself. This article explains the concepts and basic mathematics behind quantum computers and some of the promising approaches for building them. We also discuss quantum communication, an essential component of future quantum information processing, and quantum cryptography, widely expected to be the first practical application for quantum information technology.

Static Analyzers: Seat Belts for Your Code

Just as seat belt use is widespread, static analysis should be part of ethical software development. Because security must be designed in, static analysis should occur early in software development to reduce vulnerabilities or, even better, provide feedback to educate software developers and reinforce good practices, minimizing vulnerable constructs ever getting in the code. Even as industry migrates to languages safer than unconstrained C, thus eliminating many possible weaknesses, static analysis can be even more useful to check annotations, guarantees, conditions, and specifications provided by developers.

The Bugs Framework (BF): A Structured Approach to Express Bugs

To achieve higher levels of assurance for digital systems, we need to answer questions such as does this software have bugs of these critical classes? Do two software assurance tools find the same set of bugs or different, complimentary sets? Can we guarantee that a new technique discovers all problems of this type? To answer such questions, we need a vastly improved way to describe classes of vulnerabilities and chains of failures. We present the Bugs Framework (BF), which raises the current realm of best efforts and useful heuristics. Our BF includes rigorous definitions and (static) attributes of bug classes, along with their related dynamic properties, such as proximate, secondary and tertiary causes, consequences and sites. The paper discusses the buffer overflow class, the injection class and the control of interaction frequency class, and provides examples of applying our BF taxonomy to describe particular vulnerabilities.

Defeating Buffer Overflow: A Trivial but Dangerous Bug

With the C programming language comes buffer overflows. Because it is unlikely that the use of C will stop any time soon, the authors present some ways to deal with buffer overflows--both how to detect and prevent them.

A Software Assurance Reference Dataset: Thousands of Programs With Known Bugs

The Software Assurance Reference Dataset (SARD) [1] is a growing collection of over 170 000 programs with precisely located bugs. The programs are in C, C++, Java1, PHP, and C# and cover more than 150 classes of weaknesses, such as SQL injection, cross-site scripting (XSS), buffer overfow, and use of a broken cryptographic algorithm. Most are automatically generated synthetic programs, each a few pages of code long, but there are also over 7000 full-sized applications. In addition, SARD has production code and has hundreds of cases written by hand. The code is typical quality. It is neither pristine nor obfuscated. Many cases have corresponding “good” cases, in which weaknesses are fxed, to test for false positives. The SARD web interface allows users to browse test cases and test suites or search for test cases by programming language, weakness type, fle name, size, words in the description, and several other criteria. The user can select and download any or all of the resulting cases.