Security tools will not make your software secure...

Be sure to read Howard's article, and pay attention to this section. Here's an excerpt from Michael's" A Look Inside the Security Development Lifecycle at Microsoft"....


Security tools will not make your software secure. They will help, but tools alone do not make code resilient to attack. There is simply no replacement for having a knowledgeable work force that will use the tools to enforce policy. The new version of Visual Studio® 2005 Team System Developer's Edition includes some very, very useful security tools:

PREfast PREfast is a static analysis tool for C/C++ code. It can find some pretty subtle security defects, and some egregious bugs, too. This is lint on security steroids.

Standard Annotation Language (SAL) Of all the tools we have added to Visual Studio 2005, this is the technology that excites me the most because it can help find some hard to spot bugs. Imagine you have a function like this:

Copy Code

 void *function(
    char *buffer, 
    DWORD cbBufferLength);

You know that buffer and dwBufferLength are tied at the hip; buffer is cbBufferLength bytes long. But the compiler does not know that—all it sees is a pointer and a 32-bit unsigned integer. Using SAL, you can link the two. So the header that includes this function prototype might look like the following:

Copy Code

 void *function(
    _in_bytecount(cbBufferLength) char *buffer, 
    DWORD cbBufferLength);

Please note the final syntax used for SAL may change before Visual Studio 2005 ships.

FxCop You may already know of FxCop—it's a tool to find defects, including security defects in managed code. It's available as a download from, but the version in Visual Studio 2005 is fully integrated, and includes some new issues to watch out for.

Application Verifier AppVerifier is a runtime tool that operates on a running application. It can be used to trap memory-related issues at run time, including heap-based buffer overruns.

Other tools and requirement at Microsoft include:

  • All unmanaged C/C++ code must be compiled with the /GS stack overrun detection capability.
  • All unmanaged C/C++ code must be linked using the /SafeSEH option.
  • All RPC code must be compiled with the MIDL /robust flag.
  • Security issues flagged by FxCop and PREfast must be fixed.
  • The functions shown in Figure 4 are banned for new code, and should be removed over time for legacy code.

Figure 4 Sample Banned Functions

Banned API

Strsafe Replacement

Safe C and C++ Libraries

strcpy, wcscpy, _tcscpy, _mbscpy, lstrcpy, lstrcpyA, lstrcpyW, strcpyA, strcpyW

String*Copy or String*CopyEx


strcat, wcscat

String*Cat or String*CatEx


wnsprintf, wnsprintfA, wnsprintfW

String*Printf or String*PrintfEx


_snwprintf, _snprintf

String*Printf or String*PrintfEx

_snprintf_s or _snwprintf_s

wvsprintf, wvsprintfA, wvsprintfW, vsprintf

String*VPrintf or String*VPrintfEx


_vsnprintf, _vsnwprintf

String*VPrintf or String*VPrintfEx


strncpy, wcsncpy

String*CopyN or String*CopyNEx


strncat, wcsncat

String*CatN or String*CatNEx


scanf, wscanf



strlen, wcslen, _mbslen, _mbstrlen



You can read about the Strsafe string replacement code in "Strsafe.h: Safer String Handling in C". The Safe C library is the new C runtime library replacement built into Visual Studio 2005. You can read about it at "Safe! Repel Attacks on Your Code with the Visual Studio 2005 Safe C and C++ Libraries".