This is typically due to two facts:
First of all, the function call is a complex process, and often a function calls another function in the file. When a code audit tool finds sensitive functions such as the eval(), tracing the call path is usually very hard.
Second, if the program uses a complex framework, which the code audit tool often lacks support for, a large number of false-positives and omissions will occur.
Automated code auditing tool is another solution, which finds all possible input from the user, and then tracks variable transmission to see if the variables are capable of performing any dangerous functions [such as eval()]. This approach is easier to implement than tracing back the process of the function call, but there will still be many false-positives.
There is no perfect automated code auditing tool, so a manual process is still needed to obtain results from code auditing tools.
Automated code auditing is hard, and semiautomatic code auditing still requires a lot of manpower. So, is there any opportunistic way?
In fact, a company that is party A can completely customize code audit tool according to its development specifications. The idea is not to directly check whether the code is safe, but whether developers have complied with the development specification.
So the problem of complex “automated code audit” changes to “code is in line with the development specification.” The development specification at the first stage of development should correspond to the audit specification. If there is no problem in the development of a security plan, output of the code should be safe when developers strictly abide by the development specification.
This is practiced in Internet companies specializing in web development.