How to ensure a .net system is free from viruses when deploying?

Question

This is kind of on the far scale of possibility, but in the legal world it seems relevant. In a current contract, our future client wants us to agree that our system is free from any kind of virus, worms, and malicious code in general. Obviously our system is, but then you start to think. What if someone broke in somehow and infected the complier to put something in the finished system, or they somehow got to your source and put something in. Again, I get that these are unlikely, but if we have to guarantee our software is free from these things, it seems like it should be thought of for at least a moment. One idea so far is to notice file sizes after compile time, and by knowing that the size never went up, you should be good. Again the compiler issue here again, but probably less of a worry than adding to the source. How do other companies do this, or do other people just not worry about these details?

Added*** Yes they are paranoid, but then again everyone is somewhat paranoid when it comes to that 0.00001% risk. In this case, they're are requiring us to say there is nothing in the system that we're sending them. So rather than the concern being that it might be in the source I guess, it's that something could gain access to the dlls and then that would be shipped them. I think you guys are probably right, we're probably good in the areas of:

• if something is added after they've installed it at their location.
• that we would know if something was in the compiler or the source, and catch it

I guess the main concern is besides checking file sizes, how would we know something was added to our dlls?

I've thought we could just use a virus scan at the time of delivery, but then I've been reading that antivirus tools are less and less reliable, even missing potentially up to 50% of threats?

Answer 1

Normal worms and viruses don't contaminate .NET applications, don't change the code of your source control system and don't change the C# compiler. Although code reviews will help find strange checkins, you would expect an specialized attacker to hack the source control system as well so that these changes keep unnoticed.

So if this happens to you, you are talking about a very specialist and targeted attack to you as a software organization. Chances are that the attacker is highly skilled and probably either payed a lot, or working some government. So this only happens when you or your clients have information that is highly valuable to either their competitors or some government.

Your organization should determine what's the risk, but I would say that for most normal development companies the changes of such a specialized attack are fairly limited. It still is common sense to run anti-virus software and do code reviews of course. But don't forget that your client can't just ignore its own responsibilities. If its business is that valuable and has a reason to expect such targeted attacks, they should run your software through virus scanners before installing, and analyze and review your software for threads.

But under normal circumstances I think it is reasonable for the client to expect that your software is free from any "kind of virus, worms, and malicious code in general". Your company should of course have an insurance that covers these kinds of things.

Answer 2

You do it by having source control that tracks all changes to your codebase so that you can see what was changed where, a automated build process that only builds code from the checked in source control system, and a robust QA process that tests all builds before they are released to the public.