Software development and quality assurance

* An essential component of security

Software quality assurance (SQA) isn't usually considered part of information assurance, but it can potentially affect all six elements of the Parkerian Hexad. In particular, SQA usually protects integrity, availability and utility of information. The Risks Forum Digest moderated by Peter G. Neumann since 1985 contains thousands of examples of security risks caused by poor SQA.

SQA must aim to uncover all program problems even though in practice, that's not possible for most programs. At best, we are reducing the likelihood that defective programs will enter production. Since the cost of rectifying errors grows by about ten times with each stage of development, it's sensible to incorporate SQA at every step of the system development life cycle.

One of the questions that arise when planning to implement SQA is where the head of that function should report. It's always seemed to me that the director of SQA should be reporting at the same management level as the director of software development – much as I always recommend that the chief information security officer should report at the same level as the chief information officer. The reasoning is that, just as the head of Financial Audit should not be reporting to the chief financial officer, the SQA chief shouldn't be reporting to the person in charge of development: there's a potential conflict of interest in having the development director exerting control over the equivalent of an audit function.

One of the categories of SQA tools that practitioners find immensely helpful is test-coverage monitors. These packages report – usually using graphical output – on how many times every single line of source code has been used in the test batteries applied during testing. Blank areas indicate untested code, which in turn could indicate:Easter eggs – unauthorized code inserted by employees or others.

• Inadequate test suites.

• Incorrect coding that renders sections of code logically impossible to access.

• Logic bombs and

Another method for SQA is seeding: inserting known errors in the program under test. If the SQA process doesn't catch all the inserted bugs, there's a problem. If you have inserted a large number of known bugs (e.g., 100), you may even be able to estimate the approximate proportion of unknown bugs remaining to be found in the code; e.g., if you found 90% of the 100 inserted bugs (i.e., you missed 10%) and you have found 2,459 bugs in your code so far, then perhaps there are roughly 246 bugs (10% of 2,459) left to find. These estimates are not precise because there is no guarantee that the kinds of errors introduced are equivalent to the types of errors remaining, but the estimate is better than nothing.

* * *

Today's column is based on Chapter 39, "Software Development and Quality Assurance," from the Computer Security Handbook, 5th Edition by Diane E. Levine, John Mason, Jennifer Hadley. The chapter contains more information, including discussions of types of programming errors to look out for. A 48-slide PowerPoint lecture and an eight-page PDF file of notes are freely available for download from my Norwich University IS342 "Management of IA" lecture notes Web page.

Learn more about this topic

Mandatory certification & licensing for IA professionals

Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.

Copyright © 2010 IDG Communications, Inc.

IT Salary Survey 2021: The results are in