A person has good knowledge of overall security risks, knows what OWASP Top 10 vulnerabilities are, and has certifications like CEH, CISSP, OSCP, etc. which are more black-box testing. And also he has gone through the OWASP Testing Guide, Code Review Guide, etc. and cheat sheets. Will he be able to perform secure code review without knowledge of multiple programming languages and mastery over them?
It depends on what is meant by "secure source code analysis."  One can do anything one pleases.  The issue, I presume, is when someone else has asked for something called "secure source code analysis," and one wonders why one is not qualified for it.

In many cases, such analysis must be done by a Subject Matter Expert (SME).  In the final product, a SME will deliver a statement basically saying "I declare this code to be secure," with an understanding that is a more profound statement than "I looked for a bunch of known patterns, and found no problems."

If you were interested in the authentic translation of a Chinese philosophy, would you trust an individual who knew a great deal about philosophy, and had a bunch of cheat sheets to help decipher it, but did not actually know Chinese?

One great example that comes to mind is a bug that hit a SQL engine.  Forgive me for not having the name of which engine, or which version so you can verify, I have had trouble finding it since.  However, the error was poignant.   The error was in code that looked like this:

int storeDataInCircularBuffer(Buffer* dest, const char* src, size_t length)
{
    if (dest->putPtr + length < dest->putPtr)
        return ERROR; // prevent buffer overflow caused by overflow
    if (dest->putPtr + length > dest->endPtr) {
        ... // write the data in two parts
        return OK;
    } else {
        ... // write the data in one part
        return OK;
    }
}


This code was intended to be part of a circular buffer.  In a circular buffer when you reach the end of the buffer, you wrap around.  Sometimes this forces you to break the incoming message into two parts, which is okay.  However, in this SQL program, they were concerned with the case where length could be large enough to cause dest->putPtr + length to overflow, creating an opportunity for a buffer overflow because the next check wouldn't work right.  So they put in a test: if (dest->putPtr + length < dest->putPtr).  Their logic was that the only way this statement could ever be true is if an overflow occurred, thus we catch the overflow.

This created a security hole that actually got exploited, and had to be patched.  Why?  Well, unbeknownst to the original author, the C++ spec declares that overflow of a pointer is undefined behavior, meaning the compiler can do anything it wants.  As it so happened, when the original author tested it, gcc actually emitted the correct code.  However, a few versions later, gcc did have optimizations to leverage this.  It saw that there was no defined behavior where that if statement could pass its test, and optimized it out!  

Thus, for a few versions, people had SQL servers which had an exploit, even though the code had explicit checks to prevent said exploit!

Fundamentally programming languages are very powerful tools that can bite the developer with ease.  Analyzing whether this will occur does require a solid foundation in the language in question.

(Edit: Greg Bacon was great enough to dig up a CERT warning on this: Vulnerability Note VU#162289 C compilers may silently discard some wraparound checks., and also this related one.  Thanks Greg!)
