I don't think there is a tool, or ever will be, that can provide certainty. You do not state if you are looking for accidental or intentionally malicious code. Accidental mistakes are easier to catch, intentional "back doors" impossible, at the tool level, to distinguish from valid code.

I would start with (as you have already mentioned) static checks, and dynamic checks (valgrind).

Internal code review/audit will be required, and depending on importance and project budgets, external code review/audit by specialists would be money well spent. 150kLOC is a pretty average size project, an audit of that should be able to be performed.

Testing the interfaces (blackbox) is essential. Use a security consultant if you do not have experts inhouse.

If you are looking for intentional code, that's a really big problem, as it's pretty easy to hide an intentional vulnerably (e.g. an intentional buffer overflow hidden behind cast to hide the compiler warning), and it's too big code base to be certain of identifying every one. Assume you won't find them all, and deploy accordingly.

and welcome to Security.SE. This question doesn't really fit the StackExchange format, and will likely be closed. Questions like this typically end up just being a list of books, which could potentially get out of date very rapidly.

To answer your question, I would recommend a couple of things:

1. Pick an area that you would like to study (i.e. web vulnerabilites vs. C source code).
2. Find applications which fit your choice which are open source and have had security vulnerabilities which have been discovered in the past. There are also plenty of purpose made vulnerable applications such as Owasp's WebGoat you could look at.
3. Download an old version of the source code which still contains the vulnerability, and read through the code to see if you can understand how the vulnerability presents itself.

As far as books go, there are plenty available, but as @multithr3at3d mentioned, it's kind of a broad topic.

You can also try running some static analysis tools against some open source projects, and review the results to find other potential vulnerabilities.

On the lower layers, manually examining memory can be very revealing. You can certainly view memory with a tool like Visual Studio, and I would imagine that someone has even written a tool to crudely reconstruct an application based on the instructions it executes and the data structures it places into memory.

On the web, I have found many sequence-related exploits by simply reversing the order in which an operation occurs (for example, an online transaction). Because the server is stateful but the client is stateless, you can rapidly exploit a poorly-designed process by emulating a different sequence.

As to the speed of discovery: I think quantity often trumps brilliance...put a piece of software, even a good one, in the hands of a million bored/curious/motivated people, and vulnerabilities are bound to be discovered. There is a tremendous rush to get products out the door.

How can I find vulnerabilities in this code?

With experience, a good set of compiler options, a static source code analyzer, a dynamic analyzer, ... anything you know how to use. If you don't know how to use such, I'm afraid that you have to learn.

You can find the worst problems by raising the warning level of your compiler to the max and even give option like -pedantic for GCC. The same applies to the analyzers of which the static kind is quite simple to use.

Then you can build tables of possible control and data flows. For instance scanf() can do anything of these:

1. Read nothing at all into t1 leaving it completely uninitialized, perhaps because of I/O errors.
2. Read a zero length string; just one character, '\0', will be stored in t1.
3. Read anything between the previous and the next length.
4. Read a string filling t1 up to the last character, but not overflowing it.
5. Read a string longer than t1 provides space for.
6. Read a string very much longer than t1 provides space for.

Some of these might have the same effect, beware. Then think about what will happen further down the control flow.

Do this for every function call, every assignment, and every instruction. Some instructions are simple and don't do any harm, others are quite tricky. You have to read the documentation of the functions carefully, and the C standard, may be more than one version of it.

There are some traps to distract you from the real errors, too.

Does anyone know how to find them?

Yes, a lot of people know this.

Well, you didn't ask for the vulnerabilities. And from your comment you didn't want to, perfect. ;-)