Coding standards help developers avoid introducing flaws that can lead to security vulnerabilities. Testing standards and best practices help to ensure that testing focuses on detecting potential security vulnerabilities rather than concentrating only on correct operation of software functions and features. "Fuzzing" supplies structured but invalid inputs to software application programming interfaces (APIs) and network interfaces so as to maximize the likelihood of detecting errors that may lead to software vulnerabilities.

Apply static-analysis code scanning tools and code reviews

Tools can detect some kinds of coding flaws that result in vulnerabilities, including buffer overruns, integer overruns, and uninitialized variables. Microsoft has made a major investment in the development of such tools (the two that have been in longest use are known as PREfix and PREfast) and continually enhances those tools as new kinds of coding flaws and software vulnerabilities are discovered. Code reviews supplement automated tools and tests by applying the efforts of trained developers to examine source code and detect and remove potential security vulnerabilities. They are a crucial step in the process of removing security vulnerabilities from software during the development process.

Separate code reviews as a way to enhance security

Both PCI DSS and SDL mention separate code reviews as a way to enhance security. In addition SDL mentions the use of static-analysis code scanning tools. Such tools often assists during code reviews, but may also be applied during normal development.

Static/dynamic analysis and other definitions

There are two principal types of program analysis. Static, or compile-time, analysis is aimed to investigate a program’s run-time properties without actually executing it. Normally this is performed by source code inspection, but binaries may also be used. Dynamic, or run-time, analysis is performed when observing the program at execution. Testing, debugging and performance monitoring are examples of dynamic analysis.

Example of a very simple static analysis

An example of a very simple static analysis would be searching for specific words like strcpy using a file-search utility like grep. The goal would be to identify where unsafe functions are used.

A search for strcpy will however also list values like strcpy_s. If strcpy is part of a comment, this will also be presented as a valid occurrence. Such output is called a false positive, i e something reported as a vulnerability though not. False positives are a big issue in static analysis since they give the user more data to evaluate than necessary. Each program construction reported as a vulnerability must be considered and reviewed.

Suppose strcpy is renamed to something else, for instance with a macro like ‘#define mycopy strcpy’.

In this case a word search for strcpy won’t list any occurrence of mycopy, though strcpy really is used. This is called a false negative, i e a real vulnerability that hasn’t been presented.