It doesn’t mean you should not follow non-Microsoft best practices – on the contrary – but implementing those may require additional work. If you follow OWASP publications, for example, you are on your own implementing proper rule sets and other activities within Visual Studio boundaries.
This is important observation since Visual Studio – for obvious reasons – supports Microsoft SDL process exclusively. While there are many other standards or sector regulations demanding one or other form of SDL, they are usually technology and methodology agnostic. Obviously, SDL can help you meet this requirement. Take for example Requirement 6: Develop and maintain secure systems and applications from Complianceīefore we delve further into technical details, it is important to note that SDL best practices are becoming a common compliance requirement.
Furthermore, most of this article applies to 2015 release as well, and some VS 2015 exclusive features are also being discussed along the way. The rationale behind this decision is a fact that a lot of developers are still using 2013 version. Since at the time of writing Visual Studio 2015 has been available already one may argue why to deal with the older version. In this article I describe some of the SDL features implemented in Visual Studio 2013 and Windows operating platform. To aid Windows-based developers in secure coding further, some parts of SDL process has been reflected in various Visual Studio release for some time. But their SDL program didn’t stop there they actually implemented those best practices internally. Microsoft deployed secure-by-default stance and introduced a number of best practices for developers. Their Secure Development Lifecycle (SDL) process has been the main factor behind this crucial change. Over the years Microsoft had invested heavily into security, successfully changing market perception of own products from one of most insecure into reliable and secure software.
0 kommentar(er)
