9

I am not familiar with all the steps involved in a full-fledged information security review of an in-house developed application, so I am wondering whether or not the following scenario is commonplace.

A web application is created, and runs on top of Microsoft's .NET framework.

Under the terms of the security review, all third party code, defined here (however rightly or wrongly) as code not written in-house, needs to be reviewed.

Thus, even the .NET stack itself - not just the in-house code written on top of the .NET stack - needs to be audited. So besides the initial audit of the code, any Microsoft updates would have to be audited. For instance, suppose the app is using MVC 5.2, and Microsoft releases MVC 5.3, and the app upgrades to MVC 5.3; in this case, the app could not pass review until (among other tests) the MVC 5.3 codebase itself is run through auditing/review.

Is this part of normal information security reviews?

Is it standard practice to conduct a security review of Microsoft's own code base when you build an app on the Microsoft stack?

How could one assume an internal auditing and review process (using whatever third party tools) would be more sophisticated than the tests Microsoft itself would run?

And where does this cycle stop? Who is to say the third party tools and/or internal tests are up to par? I guess there should be an audit of those processes as well. And then an audit of those audits...etc., etc., etc. At some point, this has to stop and there has to be a level of trust, right?

Improve this question
1
  • 2
    Do you also audit the full operating system and server environment? After all, the system calls are third-party code that your software is using.
    – tylerl
    Commented Jul 31, 2014 at 13:16

2 Answers 2

Reset to default
10

Is it standard practice to conduct a security review of Microsoft's own code base when you build an app on the Microsoft stack?

No. One reason being is that you will not have access to proprietary (Windows, IIS, .Net, patches) code unless you reverse engineer it and the effort of it would outweigh the benefits.

The common approach is to define trusted 3rd parties and accept the risk. If you wanted to cover 100% of 3rd party components, you would have to review not only .Net, Windows, device drivers, firmware, BIOS, but also the hardware as well.

Improve this answer
3
  • 1
    Don't forget compilers :)
    – domen
    Commented Jul 31, 2014 at 16:15
  • 1
    Actually, there was a time when Microsoft made quite a big deal out of making their source code available to selected partners for very high licence costs and very strict NDAs - it was really all just theatre when you'd need to spend at least as much as Microsoft spent writing the code to audit it properly.
    – symcbean
    Commented Feb 24, 2015 at 23:39
  • @symcbean referencesource.microsoft.com
    – Michael come lately
    Commented Dec 18, 2019 at 17:07
1

No, you would not typically do this though you can walk through much of the .net supporting libraries in a debugger if you want to check exactly what a specific piece of code is doing. You may be able to scan some of the libraries using static code analysis that can operate on binaries but with large reputable vendors they will have already done this or similar testing - smaller vendors may not have.

Ultimately you need to look at the certifications, white papers, contract, reputation, and secure development practices of the vendor in order to determine the risk associated with the use of the code. For example you may choose a certain operating system over another based on the risk posed by each, but you wouldn't review all the source code of either!

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .