Realizing that you even have such a question already puts you ahead of the game.
I would also add:
(C) He's not very good at reviewing code, so you'll only get "low hanging fruit"
(D) He's really a pentester, that thinks its "oh so easy" to branch out into code, so you'll get similar results as a pentest, only traced to the actual code.
(E) He's a developer, without much understanding of security, but knows some bad code.
etc...
Point of the matter is, it seems that he's not being very transparent with you - so it doesnt really matter which option it is. Even (A) My code has no problems
is not worth very much, unless he can back it up with proof of which problems your code doesn't have (sic).
And no, running an automated tool does not count as a security code review, as you apparently felt, correctly.
So, to your questions:
1. What should you ask him to do
"Security code review". He should be telling you what he will do, and/or recommend what else you need (this could/should be a pretty long list). Of course, you can/should give him more input, such as what your application does, who has access, how sensitive the data is, etc etc. But even if you don't, he should ask for this information. Without it, it's simply not a professional-level code review.
2. How do I cross-check his work
- I would say that in general, there are 3 possiblities:
- Learn enough about the subject to understand what he claims to be doing, and to ask the hard questions - or get somebody who does (Always true when dealing with provider of a service you don't quite understand...)
- Have another consultant do a competing review - even if only on a subset of the application.
- (And this is the good one) Perform an external blackbox penetration test. This is the best way of validating the code review. Of course, have someone else do the pentest, and compare results. Note that not all vulnerabilities found in pentest are relevant to be found in a code review, and vice versa, but it should give you some indication.