What if your external developer won’t let you share the code of an application with us for a pentest, even though the application was made specifically for you? This is problematic because it forces you to accept a less effective test of your application: one in which we cannot look at the code while we carry out the pentest.
How can you avoid this happening to you?
In this short blog I will discuss three topics that, in the context of pentesting, are relevant when an external party develops your application: ownership, audits and requirements.
The best time for you to think about these topics is, of course, before you commission a project. Any time after that will be more difficult because it could mean changing the terms of a contract. And it goes without saying that you should discuss the points below with your legal advisor first.
Ownership
The best option is to ensure that for any software that you commission you will be the actual owner of the code. Being the owner means that you are in full control. Specifically, you won’t need permission to share the code with a third party.
An objection that you may hear from your external developer is that while some of their code is going to be made specifically for you, other code will be shared code that they use for multiple clients, and therefore you can’t get ownership of it. This could be the case. In response, you could ask for partial ownership. This may be hard though, as it will require someone on your supplier’s side to decide what is “your” code and what isn’t. But worth a try for the rewards. For anything that you really cannot get ownership of, you need rights to audit or insights into audit results.
Note that ownership of the code has more benefits than just being in control of pentests. So even if you get insight in the quality of your application in other ways than getting a pentest yourself, it is still worth securing ownership.
Audits
In case you can’t get ownership of the code, you need to prepare alternative ways of being able to get insight in the quality of your application. One way is to secure the right to have code audited. Having audit rights means that even though you don’t own the application, you will be able to decide to have the application audited. Make sure to discuss beforehand how this will work in practice: will you receive the code from your developer in order to then share it with your pentest provider (under the appropriate non-disclosure agreements) or will your developer share the application code directly with your pentest provider? And in both scenarios, you need to be among the direct recipients of the audit report.
It could be that your developer tells you that all their applications are already being audited. In this case, you may decide the audit rights are not necessary, but you will need to address that the audits should be carried out by a third party, when you expect them to be carried out, and that your application developer shares unedited audit reports with you so that you can get an insight into the quality of your application.
Security requirements
In all cases, do provide the security requirements for your application with your external developer, regardless of the method you use to secure insight into the quality and associated risks of the application that your provider will build for you.
The Application Security Verification Standard (ASVS) (https://owasp.org/www-project-application-security-verification-standard/) is a good starting point for defining your requirements. ASVS is a comprehensive framework of security controls and it predefines three security verification levels to choose from. Setting requirements, you could choose one of the three predefined levels that matches the assurance level that you seek.
Concluding
When you’re having an application built by an external developer, you need to be able to understand the risks associated with the final product. The best way is to let someone audit or test the resulting product with access to the code. At the start of your project, in the contract phase, be sure to discuss the topics of security requirements, audits and ownership with your legal advisor and your purchaser. You will avoid potential frustration at a later stage in the project.