I have been a penetration tester for 8 years. And my most memorable engagement was one I performed for a startup. They welcomed me in the developers’ open space for the duration of the engagement. They only had experienced programmers in the team; They were very eager to learn about security, and the mood was very friendly from the beginning. Penetration testers and developers working together as if we were on the same team.

They showed me the source code, and they walked me through the whole application. They even showed me the parts where they had security issues in the past. And we worked in collaboration to find vulnerabilities and the best solution to fix them. Since I had access to the whole application’s components, I had no excuse to miss any vulnerabilities. I even found vulnerabilities that needed very creative thinking to exploit. I made sure to share all my knowledge with them during this whole engagement. We finished the engagement on very good terms and I gave positive feedback to their boss.

On the other end of a spectrum, I performed a penetration test for another company. This time, the lead developer did not want to be audited. He gave me the least amount of information possible, and tried to slow down my progress. The application would be down for hours for maintenance. He would stall to provide me with any information I needed. When I asked him to provide me credentials to access the application, he replied “aren’t you supposed to be the hacker? Why don’t you find the credentials yourself?”. Needless to say, I only found surface level vulnerabilities on that engagement, and I felt bad about it. I thought I could find more, potentially dangerous vulnerabilities, if they allowed me to dig deeper.

It is in the best interest, for both penetration testers and developers, to be on the same team. They need to collaborate during the audit for better results. I will explain my thinking in this article.

For developers

When it comes to security audits, developers behave in one of two ways. They can either work well with the penetration tester, or hinder their progress and make their job more difficult.

Collaborative Developers

Developers who collaborate with the penetration tester get more from the audit than those who are adversarial.

When you’re on the same team as the penetration tester, you help him understand the context of the application. Maybe you developed a feature in a hurry and didn’t have time to draw out all the possible attack scenarios. You can ask him to look more closely into this feature and identify security flaws in it. Tell him what bugs you had in the past and ask him to check for them on a different page. Ask him to analyze a user flow that you set up, where you’re not sure everything is secure.

At the end of the audit, you will get much more vulnerabilities. And that’s a good thing. Identifying all the possible vulnerabilities is what an audit is all about. If you love the product you are developing, this will help you make it more secure, and thus better. You wouldn’t prefer having security issues hidden under the rug, would you? Malicious hackers could exploit them, putting your product and your customers at risk. It can even end up causing you public humiliation.

Collaborative developers are also much more likely to learn something from the experience. They are curious about how their website resists against a skilled hacker. Thus, they will be much more likely to study the findings of the audit. They will learn how to fix the issues and how to avoid the same pitfalls next time.

Adversarial Developers

On the other hand, the developer with an adversary attitude has his ego involved. He feels ashamed of having vulnerabilities on his website. He interprets it as being incompetent or negligent.

This is a faulty point of view that developers need to change, and I will give 3 reasons why:

• He was optimizing for efficiency: he was creating a product, and focused on efficiency and speed, to deliver new features and fix bugs for customers. That is the core of the business, the breadwinner. So no one will ever blame him for making this choice. But, the efficiency and speed can come with a caveat: he might miss some security checks in the code. This is an expected side effect, and he should take it as such.
• Take it as a learning experience: every vulnerability the penetration tester identifies teaches him something new about cyber security. Discovering additional vulnerabilities increases his knowledge and enhances his cyber security skills. Consider it an investment in your long-term education.
• Detach your ego from your product: we have this association made between our self-worth and the quality of the things we produce. We think that since the application we made is flawed, then so are we. This logic is misleading because we know that experts who make perfect products did not start out that way. The products they made went through iteration upon iteration to become perfect. Your product has to go through iterations as well. But if you stop the process in its infancy, because you refuse to see the imperfections, you will keep having an imperfect product. While you can convince yourself that the product is perfect, your customers can see the flaws. To make a better product, you need to accept the truth and see the flaws as they are and fix them. 

For penetration testers

Developers build applications, they build the technology of tomorrow. As penetration testers, we need to recognize that we have a secondary role in this movie. We are like building inspectors—We check if the application follows security standards. Our job is to point out flaws in the application, so that the developers can fix them and improve the quality of the application.

Sure, you can enjoy the technical challenge such a job provides. But, don’t let that taint you with an adversarial mindset. When you start the job, don’t think of it as competing with the developers or trying to show off.

Try to genuinely help the client. This will put the developers at ease, and gets you more collaboration. It will help you uncover more hidden flaws that you would have otherwise missed.

When you share your findings, be diplomatic and neutral. Don’t blame the developers for the vulnerabilities, just provide facts.

Sometimes, you try your best but don’t find any vulnerabilities. This is a cause of celebration, and not a sad thing. I know how frustrating it is to look for vulnerabilities and fail to find any. But in the grand scheme of things, it means the application is secure, and the developers are respecting security best practices.

So, if you get the chance to talk to the developer at the beginning of the engagement, be open with them. Tell them that you are not here to expose them. You are here to help them find issues and fix them. Tell them to use you during this engagement to find issues that they wouldn’t have the time to find themselves.