Rendersi conto che anche tu hai una domanda del genere ti mette già in vantaggio.
Aggiungerei anche:

(C) Non è molto bravo a rivedere il codice, quindi tu otterrà solo "frutti bassi"
(D) È davvero un pentester, che pensa che sia " oh così facile " espandersi in codice, quindi otterrai risultati simili come pentest, tracciato solo nel codice effettivo.
(E) È uno sviluppatore, senza molta conoscenza della sicurezza, ma conosce un codice errato.
ecc ...

Punto della questione è che sembra che non sia molto trasparente con te, quindi non importa quale sia l'opzione. Anche (A) Il mio codice non ha problemi non vale molto, a meno che non possa eseguirne il backup con la prova di quali problemi il tuo codice non ha (sic).
E no, in esecuzione uno strumento automatico non conta come revisione del codice di sicurezza, come apparentemente hai sentito, correttamente.

Quindi, alle tue domande:

1. Cosa dovresti chiedergli di fare "Revisione del codice di sicurezza". Lui dovrebbe dirti te cosa farà e / o consigliarti cos'altro hai bisogno (questo potrebbe / dovrebbe essere un elenco piuttosto lungo). Ovviamente puoi / dovresti dargli più input, come cosa fa la tua applicazione, chi ha accesso, quanto sono sensibili i dati, ecc. Ecc. Ma anche se non lo fai, dovrebbe chiedere queste informazioni. Senza di esso, semplicemente non è una revisione del codice a livello professionale.

2. Come faccio a controllare il suo lavoro ? Direi che in generale ci sono 3 possibilità:

• Impara abbastanza sull'argomento per capire cosa afferma di fare, e per porre le domande difficili - o chiamare qualcuno che lo fa (sempre vero quando si tratta di un fornitore di un servizio che non capisci bene ...)
• Chiedi a un altro consulente di fare una revisione concorrente, anche se solo su un sottoinsieme dell'applicazione.
• (E questo è quello buono) Esegui un test di penetrazione della scatola nera esterna. Questo è il modo migliore per convalidare la revisione del codice. Ovviamente, chiedi a qualcun altro di eseguire il pentest e confrontare i risultati. Nota che non tutte le vulnerabilità trovate in pentest sono rilevanti per essere trovate in una revisione del codice e viceversa, ma dovrebbe darti qualche indicazione.

Sto arrivando dalla posizione di essere il ragazzo che esegue la revisione del codice di sicurezza (anche se non ho fatto la tua ;-). Quindi quello che vuoi scoprire è se il codice può essere distribuito a basso rischio e, in caso contrario, quali sono i rischi. Pertanto dovresti chiedere al tuo consulente che, invece di chiedere "puoi trovare alcune vulnerabilità nel mio codice". La risposta alla domanda relativa al rischio dovrebbe includere:

• cosa ha provato per identificare i rischi
• quali attacchi ha considerato (presumo che un'app PHP sarà basato sul web, nel qual caso la top 10 di OWASP è appropriata come inizio)
• perché ha considerato quegli attacchi (in altre parole, quale modello di minaccia ha utilizzato)
• quale rischio residuo rimane

Devi considerare sia l'ampiezza che la profondità della recensione. Per ampiezza, intendo quale gamma di rischi / attacchi / minacce verrà trattata nella recensione. Dovresti iniziare con lo standard di verifica della sicurezza dell'applicazione OWASP per avere un'idea di cosa dovrebbe essere trattato qui. Per profondità intendo quanto bene il consulente verificherà che ogni area sia stata adeguatamente difesa. Nella fascia bassa, una scansione automatica degli strumenti fornisce poche garanzie. Nella fascia alta, un'ispezione manuale o un vero e proprio caso di test dovrebbe essenzialmente dimostrare che le difese corrette sono in atto, sono state progettate correttamente e vengono utilizzate ovunque sia necessario.