ource code reviews and inspections have long been considered economical methods for rooting out functional and design flaws in code even before applications make their way to testing. As security has grown in importance, and with the advent of web applications and professional hackers, source code reviews have evolved to focus on potential security vulnerabilities. However, manual code reviews for security are difficult for most developers because they may not have the proper system-wide context to understand a complex security problem, or they may lack the security experience necessary to recognize potential problems.

The idea of conducting security code reviews has picked up further momentum with the latest version of the Payment Card Industry (PCI) Data Security Standard (DSS), a broadly used industry standard for protecting customer payment information. The PCI standard prescribes requirements for securing and protecting customer payment data by specifying processes and countermeasures for assuring secure systems. The sixth requirement of that standard is the most relevant to development teams, because it calls for secure “review of custom code prior to release to production or customers in order to identify any potential coding vulnerability.” In other words, failure to prove that your developers are performing the security code reviews could lead to noncompliance with the standard and potential loss of business.

The PCI standard has been a boon for automated source code review tools, which have evolved over the past few years to perform security code reviews. Most of these tools were initially created to attempt to identify functional flaws in systems or to examine compliance with coding standards, but many have added security code review features to help automate the new requirements for security code reviews. However, these tools are expensive, difficult for untrained developers to use, and often not terribly accurate.

Source Code Analysis
Most source code review tools that focus on security belong to a slightly different product category: source code analysis tools. The term “source code analysis” is a nuanced misnomer, because the products do not typically review the source code itself; instead, they compile the code into an intermediate representation, such as Microsoft Intermediate Language (MSIL) for .NET, and then statically analyze call graphs and data flows using the compiled code. Commercial security products from vendors such as Coverity, Fortify Software, and Ounce Labs all approach source code analysis in this way.

Microsoft Visual Studio 2005 introduced a new code analysis feature for .NET developers that implements source code reviews via static analysis using this same technique. The Visual Studio code analysis feature is based on the FxCop tool that Microsoft developed years ago for internal code review. FxCop is still available separately as a command-line tool, but Microsoft bundles its capabilities with Visual Studio Team System. The bundled Visual Studio version provides enhanced usability, control through the user interface, and integration with the build process.

Even though Visual Studio 2005 Team System’s (VSTS) code analysis capabilities provide powerful automated code review features for developers, those features focus mostly on checking code for adherence to coding standards and best practices. VSTS includes a few security rules, but they’re largely generic, which tends to produce false positives and sometimes makes it difficult to decipher the exact problems to which the included rules apply. The usability is compounded by poor documentation for the included code review rules, meaning that developers are sometimes left guessing whether flagged items in their code are really worth worrying about. However, the VSTS code analysis rules are inherently integrated into the build process, and you can easily configure the rules to run as part of on-demand or scheduled builds.

Fortunately, Microsoft recognized some of the code analysis limitations, and now provides an API that you can use to implement your own custom security rules and improve the code analysis process. Unfortunately, that API is both officially unsupported and largely undocumented, but the VSTS developers responsible for the code analysis feature provide a good bit of guidance, samples, and advice through blog postings and forums. This article walks you through a simple example that shows how to write a custom security rule and points you to some resources for branching out and writing your own security code review rules.

Writing Custom Code Analysis Rules
In this demonstration, you’ll see how to build a custom code analysis rule in VSTS?a simple security rule that looks for potential password disclosure by identifying any fields in the application that appear to be password values. The rule shows the process by which you can extend the base rules to implement whatever logic you desire.

Your best friend in understanding VSTS code analysis rules is Lutz Roeder’s Reflector for .NET. Because the code analysis rules and their extensibility are not documented, your best examples are the rules that ship with VSTS. After you’ve reviewed the basics here, you’ll be able to use Reflector to review the source for bundled rules, and that will help you to understand more complex rules. The bundled rules are located at C:Program FilesMicrosoft Visual Studio 8Team ToolsStatic Analysis ToolsFxCopRules. For example, to review the security rules in Reflector, open the SecurityRules.dll file, and examine the source code and resources bundled in the assembly.

The first step in creating a custom rule is to inherit the BaseIntrospectionRule class so you can access the interfaces to the code analysis introspection engine. Instead of inheriting directly from the base class for every rule you write, I recommend you create a base class that inherits from the BaseIntrospectionRule class and then inherit your subclasses from that. You must provide three arguments to the base class constructor: the name of the custom rule, the name of the XML file containing rule data, and a reference to the rule assembly type. By using a common base class that “knows” the last two parameters, you need to supply only the rule name with each new custom rule. The file BaseRule.cs contains such a base class:

   using System;   using Microsoft.Cci;   using Microsoft.FxCop.Sdk;   using Microsoft.FxCop.Sdk.Introspection;      namespace CustomSecurityRule   {       public abstract class BaseRule : BaseIntrospectionRule       {          protected BaseRule(string name)             : base(name, "CustomSecurityRule.Rules",            typeof(BaseRule).Assembly) {}       }   }

Note the references to two key Microsoft libraries in the base class: Microsoft.Cci and Microsoft.FxCop.Sdk. The Microsoft.Cci assembly, known as Common Compiler Infrastructure, includes compiler-level classes for examining low-level programming constructs in the target code, such as methods, fields and classes. The Microsoft.FxCop.Sdk assembly contains the mechanism for running code analysis rules and displaying results natively in VSTS.

To create the sample rule called “Possible Password Disclosure,” create a class named PossiblePasswordDisclosure that extends the base rule. In the rule constructor, provide the name of the rule as the only argument. You’ll find the class in the downloadable source in the CustomSecurityRule.cs file, but here’s the code:

   public class PossiblePasswordDisclosure : BaseRule   {      public PossiblePasswordDisclosure() :          base("PossiblePasswordDisclosure") { }         public override ProblemCollection  Check(Member m)      {         Field field = m as Field;                        if (field != null)         {            string name = field.Name.Name;            string uppername = name.ToUpper();            if (uppername.IndexOf("PASS") != -1 )            {               Problems.Add(new Problem(GetResolution(name)));               return Problems;            }            else            {               return null;            }         }            return null;                 }   }

The overridden Check method in the rule class does all the work. The method overloads the Check method in the BaseIntrospectionRule interface, and it’s intended to be called repeatedly while iterating over each member of the classes on which you’re performing code analysis. This example searches every member in the class for fields that contain “pass” in the name, and flags these as potentially disclosing password values. The code first tries to convert the member to a field; if that does not succeed, then the member is not a field, so the method skips it. If it is a field, then you examine name. If the field name might be a password field, then you create a new Problem instance and add it to the Problems collection provided by the BaseIntrospectionClass. The GetResolution method lets you look up rule-resolution messages from the XML rules data file so you can display them to the developer in VSTS.

The XML file containing rules data is the final piece in the puzzle for putting together a custom rule. The example below, contained in a Rules.xml file, provides the friendly name, the rule description shown in VSTS, and the rule-resolution information that users see after a rule has flagged a problem.

                     Possible Password Disclosure         The field '{0}' in your application may be a             password field and could be vulnerable to password             disclosure if the value is visible and             unencrypted.                  If the field "'{0}'" is a             password field, it should be protected through             encryption and obfuscation.         Error         NonBreaking                           

You include the rules file in your class library project. Mark it as an embedded resource so that it gets embedded in the assembly during compilation.

Integrating Rules with Visual Studio
After you build the custom rule and compile it into a class library containing BaseRule.cs, CustomSecurityRule.cs, and Rules.xml, you need only copy the compiled assembly into the right directory to integrate it with VSTS code analysis. Copy the DLL (CustomSecurityRule.dll in this example) from your project to the rules location at C:Program FilesMicrosoft Visual Studio 8Team ToolsStatic Analysis ToolsFxCopRules. When you place your custom rule DLL in this location along with the embedded rules description file, VSTS will display the custom rule in the same dialog as the built-in rules (see Figure 1).

	?
Figure 1. Custom Security Rule: Your custom security rule shows up in the same dialog as other code analysis rules and can be controlled in the same manner.

Because the custom rule now behaves like any other VSTS code analysis rule, you can run the rule by selecting it and enabling code analysis. You can then run code analysis manually on any project by selecting Build ? Run Code Analysis, or you can configure code analysis to run automatically as part of your build. Whenever the custom rule flags a problem in your code, you’ll see a code analysis warning in the Error List as shown in Figure 2.

	?
Figure 2. Error List View: Custom security rules report violations in the Visual Studio Error List.

Code Analysis in Visual Studio “Orcas”
Developers familiar with code analysis and writing custom rules have been hoping that the next version of Visual Studio would offer more robust rule customization capabilities. The Microsoft team originally planned to release a supported rule-writing API with full documentation, but unfortunately the feature was cut during the release for scheduling reasons.

Despite that cut, the Visual Studio team has been able to make some minor improvements to the code analysis interfaces to clean them up and prevent developers from making some common mistakes. However, code analysis rules customization is still technically unsupported, which means the team members will provide support only through forums and blog postings outlined in the references section. In addition, it’s highly likely that future releases will break custom rules as the Visual Studio team moves toward the eventual goal of offering a fully-baked and supported custom rules API; however, the team leads promise to keep backward compatibility in mind to minimize such problems.

Remember! Free Code Reviews!
Source code reviews can be great for identifying security vulnerabilities, but they’re expensive and time consuming. Fortunately, you may have the advantage of already owning the code analysis feature built into the VSTS 2005 IDE. While the security rules included with VSTS are fairly limited, you can write and integrate custom security rules, which can help your code analyses remain relatively free of the false positives inherent in generic catch-all rules.