If you ask us to carry out a penetration test (pentest) of an application, we will ask you to share the code to the application up front. A pentest is much more effective when the pentester has the code at hand. In our jargon, this is called a white box test.
In this blog, I will discuss three objections to sharing code that we hear occasionally and how we deal with them. But first, a quick reminder why sharing your code improves the effectiveness of a test.
Access to code makes a test more effective
Testing an application without having the code is nothing but blindly poking around in order to find out what’s wrong. Of course, many common weaknesses will be right there on the surface. For example: direct object references, faulty input and output validation, or file upload vulnerabilities. But some types of weaknesses are not like that. Logic flaws or race conditions, for example, aren’t generally visible on the surface and will take more time to find.
There’s a good chance that an experienced pentester, armed with the right tools, will eventually hunt down most of these vulnerabilities, but with an occasional look at the code we will always find them more quickly. And in more places: once we found a vulnerability, we can easily identify all other occurrences in the code. And with more depth: with blindly poking you see symptoms; in the code we’ll find the root cause. And we’ll give you advise on that.
That is why a pentest is incomplete without access to the code and why we ask for it: that’s how we achieve the quickest results without compromising on quality. In fact: a pentest provider that offers pentests without asking for code is, in our view, a provider to avoid.
But occasionally we get pushback. Below I describe three common objections, and how we deal with them.
“You folks are hackers right? Why should we give you the code?”
The thought behind this objection is that giving us the code would be “cheating”, giving us an unfair advantage and that it would not be a realistic reflection of the real-world in which adversaries don’t have access to the code.
While this is true, it is also true that every exposed application is going to be hammered at by automated scans, scripts and exploit attempts originating from anywhere on the internet, including the occasional manual inspection. No black box pentest with a reasonable price can come close to that.
So, a pentest is not supposed to be an accurate reflection of reality. A pentest is a way to gain insight in an application’s weaknesses and you want to use it effectively to manage risks. With this insight, most people understand that it is better to give our ethical hackers the extra information.
“Our developers don’t want to give the code”
We hear this objection, but fortunately not very often. If developers don’t want to share their code with an external party, it is usually because there is no trust. Perhaps because they were not aware a test was going to happen or were not involved the process leading up to it. They may feel that the test is like an unwanted exam: an external entity is going to rate their work.
It is understandable that developers are somewhat protective of their work and also, a pentest does indeed mean that an external entity is going to point out weaknesses in their code. But it is something you have to work through. Of course, you can force the issue, but in our view, one extra session with lead developers to explain the process, the outcomes and the goals goes a long way to getting their buy-in. We are here to help and you can learn from the outcome of a test, and use it to improve the product.
“This is our / our external developer’s intellectual property”
It is problematic if you commissioned an application and paid for it, but the external developer does not want to share the code for the purpose of a penetration test. Check your contract first. It might explicitly prohibit sharing of code, in which case you would need to address that. Depending on the urgency of the pentest you may have no choice but to go ahead without code sharing. In a future blog, we will address the question of contracts with external developers.
A more likely scenario is that your contract has no mention of code sharing and that your external developer cites IP concerns. Or: you yourself don’t want to share your code, because it is your intellectual property.
Wanting to protect your intellectual property is a valid goal. In most circumstances, a Non Disclosure Agreement is good instrument that thousands of organisations world-wide use on a daily basis to manage the risks associated with sharing confidential information. In our view, there aren’t many situations where an NDA would not suffice, optionally complemented with a description of security measures. Examples could be situations where lives might directly be at risk or when the requirements for the (classified) information simply don’t permit it. In all other cases, an extra session in which we explain this usually helps to take away this objection.
Communication can overcome most objections
We’ve shown you three common objections that we run into when asking for application code, and the way that we deal with them. It won’t come as a surprise that good communication is key to overcoming most objections.
Are you not convinced yet? Then don’t hesitate to contact us if you want to know more about sharing code.