Choose around uncertainty rather than the label
A code audit and a penetration test can overlap, but their names do not define identical deliverables across providers. Ask what access the reviewer receives, what they will attempt and what the report will establish. If your uncertainty concerns maintainability and deployment ownership, a narrowly scoped external security test will not settle it. If you need evidence of an exposed live attack path, source commentary alone may be insufficient.
Compare the perspectives
Source access can help explain how business rules, dependencies and error handling are implemented. Testing a running application examines behaviour reachable through its interfaces in a particular environment. Either approach can miss something outside its scope. Instead of assuming one replaces the other, map your important questions to the proposed method. Request examples of evidence rather than relying on a long list of tools in the proposal.
An invoice workflow illustrates the distinction
Suppose the API returns invoices using an identifier supplied by the client. A source reviewer can inspect the ownership decision and nearby export paths. An authorised tester can demonstrate whether a second test account can retrieve the invoice in the deployed environment. Those observations reinforce each other. Neither observation alone establishes that every resource or every environment has the same behaviour. The report should keep that boundary clear.
Ask about safe execution and retesting
Agree environments, synthetic accounts, permitted techniques, timing and escalation contacts. Avoid discovering that the production test conflicts with a critical customer event. Clarify whether the reviewer will stop after finding a serious issue and how evidence will be handled. Retesting should refer to the original finding and affected revision. A second generic scan does not necessarily demonstrate that the original behaviour is corrected.
Write a combined brief when necessary
For a high-consequence launch, ask providers to explain how source inspection and behavioural verification work together. For a small internal tool, a narrower review may answer the actual question. Select the work based on exposure and decision value, not a claim that every team needs every service. The useful comparison is which uncertainties remain after each proposed engagement and who will own those remaining risks.
Sources & further reading
Reference material for the guidance and examples above. Where included, community discussions provide context rather than verified incident evidence.
Retrospective weekly fieldnote, prepared with AI assistance and published on 12 September 2026. Examples are illustrative; this is not a client case study or a claim about events in the assigned week.