Although this is generally a concern, I think the issue is non-existent due to the setup.
The applicant sent you some source code. How or why did that happen?
Well obviously there are only three possibilities:
- You gave the applicant an assignment to solve a particular (well-defined) problem to assess his skills.
- The applicant wants to show off something cool he wrote.
- The applicant is a jerk or a spy or an otherwise malicious person and not actually interested in being hired. All he hopes for is you being stupid enough to run his code.
About 2) and 3)
The main risk is distinguishing between 2) and 3). Chances are high that if whatever he wrote is worth looking at, it's something that you can either get the source code for online (from a "neutral" source) and that you may even be familiar with already, or it's something that you actually don't want to look at because you would infringe a competitor's (former employer's) intellectual property. The latter would mean that you wouldn't want to hire that person anyway.
If you can get the source online, do so. If you can verify the applicant's contribution to a well-known software (including proprietary software) by his name somewhere in the credits, do so.
In every other case, simply ignore whatever he sent you. It's either not worth looking at, or illegal, or high risk.
The applicant sent you something because you gave him an assignment. If you have any competence (which I assume you do!), then for a typical programming assignment (...that you even chose yourself!), you will be able to tell whether it's a plausible solution that looks as if it might work by looking at the source code for less than 30 seconds (more likely 10 seconds).
If you cannot tell that the program will probably work (or what it's doing at all) within 30 seconds, the one who wrote it not the kind of person you want to hire, fullstop. You want people who write code that other humans can understand and maintain. You do not want someone who is trying to get smart at you, nor someone who regularly wins the obfuscated C contest. It doesn't even matter whether the program works. As soon as another person cannot understand the code, it never "works".
If the program looks like it will probably work, but you find anything that looks "weird" (say, Java unicode escape sequences, C++ raw string literals, stuff that looks like trigraphs, whatever), treat the assignment as "fail", move on to the next applicant. It's not necessary to include anything the like in 99% of all programs (and, sure enough, not in your assignment -- I should hope). So if you find anything "weird" like that, the applicant is not someone you will want to hire.
If the code passes that first triage, you may want to spend another 2-3 minutes looking at it more thoroughly. If you are still pleased with what you see after that, you may run it through a static analyzer and compile it in a virtual machine at a high warning level.
That should bring up issues that you may have missed while reading the source (such as invoking undefined behavior or narrowing conversion).
Compiling will first and foremost tell you whether the applicant has the necessary diligence and attention to detail, not so much whether he has programming skill. Much like writing the employer's name correctly on your application and spellchecking your CV before handing it in, it is best practice that you make sure whatever source code you hand in compiles without errors (and preferrably without warnings). If someone fails to do that, you do not want to hire him.
The risk of evil things happening at this point (exploiting the compiler and breaking out of the VM) is neglegible, seeing how you have already run a plausibility check over the code. Not going to happen.