Get on-the-go access to the latest insights featured on our Trustworthy Computing blogs.
Hi, Michael here.
It gives me great pleasure to introduce Tim Burrell from our team based in Cheltenham, England. Amongst other things, Tim works on static analysis and compiler security improvements, but more on that work in a later post!
As I have mentioned many times, I’m a huge fan of anything that reduces friction for software developers; anything that makes it easier to design, build and test code that’s more secure is a huge win in my book.
Now, over to Tim to see how a tool he created can help reduce coding friction and help you be more SDL-compliant!
In a previous post we mentioned that our team had worked with the Visual C/C++ compiler team to make significant enhancements to /GS buffer overrun detection in Visual Studio 2010.
While working on /GS – and navigating the unfamiliar corridors of the Visual Studio buildings – I got talking to Boris Jabes, Program Manager Lead in the Visual Studio IDE team. He told me how they were making the IDE easier to extend in Visual Studio 2010.
This piqued my interest because one of the challenges we face when enforcing compiler warnings is that teams write their code, and then get notified of the errors and warnings later on. There are some downsides to this process:
1. By the time the developer gets notified of the error or warning that needs fixing, the context is lost: i.e. the developer has to remind himself of what the line of code in question was doing.
2. Typically there may be multiple errors or warnings to resolve: the approach is naturally to go and fix all of them as quickly as possible to avoid any further delays to development. This can lead to errors.
3. The code that immediately follows the fixed code may also need updating as a result of the fix, and this can be time-consuming.
By flagging an issue in the editor itself, as the code is being written, the developer can immediately correct the issue knowing the code’s context.
With all the benefits of flagging coding issues early in mind, I decided to create an SDL Banned API extension for Visual Studio.
The extension is very simple: at the moment a developer types the name of a banned function, such as strcpy Visual Studio highlights the offending code using a squiggly line, much like a spelling error in Microsoft Word:
Visual Studio extensions can also differentiate between C and C++ language elements. For instance, we can ensure that we don’t underline occurrences of banned API function names that occur in comments or string literals:
We can also add tooltip information pointing to the SDL required coding practice.
Let us know what you think or how you extend this extension to your own purposes.
Thanks to Boris Jabes and Noah Richards in the Visual Studio IDE team for coding this up!
The code for the SDL Banned API IDE Visual Studio extension is available in SDLBanned.zip.
There are two folders in the ZIP file: src and bin. The source code folder includes the necessary C# code and VS2010 project to tweak the code. The binary code folder includes a single file: BannedAPIextension.vsix.
Double-clicking this file will install it into Visual Studio 2010. You can enable, disable and uninstall extensions from the Visual Studio Tools | Extension Manager menu.
Finally, if you want to tweak the code you need to install the Visual Studio 2010 SDK, the link is below.
Security Development Lifecycle (SDL) Banned Function Calls, MSDN, May 2007.
MSF Agile + SDL process template for Visual Studio Team System
Microsoft SDL process template for Visual Studio Team System
Visual Studio 2010 SDK
Visual Studio on MSDN
Extending the editor, MSDN.
VSX home on code gallery, samples, documentation and more, MSDN.
Noah Richards’ blog, lots of examples and discussion from Noah Richards on the IDE team.
Why is this extension not available through Visual Studio 2010 Extension Manager itself, instead of having this manual process to locate and install this extension?
That's a good idea - we can look at that if we decide to update the tool! thanks