意识到你甚至有这样的问题已经让你领先于游戏。
我还要补充：

(C) 他不是很擅长审查代码，所以你只会得到“唾手可得的果实”
(D) 他真的是个渗透测试者，认为分支代码“哦，太容易了”，所以你会得到类似的结果结果作为渗透测试，只追踪到实际代码。
(E) 他是一名开发人员，对安全性了解不多，但知道一些糟糕的代码。
等等...

问题的关键是，他似乎对你不是很透明——所以它是哪个选项并不重要。Even(A) My code has no problems不值多少钱，除非他能证明你的代码没有哪些问题（原文如此）。
不，运行自动化工具并不能算作安全代码审查，正如您显然正确地感觉到的那样。

所以，对于你的问题：

1. What should you ask him to do“安全代码审查”。他应该告诉你他会做什么，和/或推荐你还需要什么（这可能/应该是一个很长的清单）。当然，你可以/应该给他更多的输入，比如你的应用程序做什么，谁可以访问，数据有多敏感等等。但即使你不这样做，他也应该要求这些信息。没有它，它根本就不是专业级别的代码审查。

2. How do I cross-check his work - 我想说，一般来说，有 3 种可能性：

• 充分了解该主题以了解他声称在做什么，并提出棘手的问题 - 或找一个这样做的人（在与您不太了解的服务提供商打交道时总是如此......）
• 让另一位顾问进行竞争性审查——即使只是针对应用程序的一个子集。
• （这是一个很好的）执行外部黑盒渗透测试。这是验证代码审查的最佳方式。当然，让别人做渗透测试，然后比较结果。请注意，并非所有在 pentest 中发现的漏洞都与在代码审查中发现相关，反之亦然，但它应该为您提供一些指示。

我是从执行安全代码审查的人的位置上来的（尽管我没有做你的;-)。所以你想知道的是代码是否可以以低风险部署，如果不能，那么风险是什么。因此你应该问你的顾问，而不是问“你能在我的代码中找到一些漏洞吗”。风险相关问题的答案应包括：

• 他为识别风险所做的尝试
• 他考虑了哪些攻击（我假设 PHP 应用程序将基于 Web，在这种情况下，OWASP 前 10 名列表适合作为入门者）
• 为什么他考虑这些攻击（换句话说，他使用了什么威胁模型）
• 剩余风险是多少

您需要考虑审查的广度和深度。所谓广度，我的意思是审查将涵盖哪些范围的风险/攻击/威胁。您应该从 OWASP 应用程序安全验证标准开始了解这里应该涵盖的内容。所谓深度，我的意思是顾问将在多大程度上验证每个区域都得到了充分的保护。在低端，自动工具扫描几乎没有保证。在高端，手动检查或实际测试用例应该基本上证明正确的防御措施已经到位，设计正确，并且可以在需要的任何地方使用。