The More Access, the Better

It's about time you relied on code-assisted pentesting

The critical question is, would you like your applications or IT infrastructure to continue to have security vulnerabilities that you would have the opportunity to identify and eliminate? In your right mind, the crystal clear answer would be a categorical "no." So why not grant security experts access to your source code for meticulous assessment?

Distrust. This is the answer that some organizations tend to give. In this post, we encourage you to put that feeling aside, at least with Fluid Attacks, by explaining that the more access we have to your code, the better your cybersecurity posture can be.

Black-box vs. white-box testing

Software security testing is usually divided, among other classifications, into two groups: "black-box" and "white-box" testing. Although some may find this classification erroneous and even offensive today because of the use of the words "black" and "white" —something we do not intend to discuss here— so much so that replacement words such as "opaque" and "transparent" have been offered, what is intended to denote is an analogy with the absence and presence of light to see what is inside the "box": the source code. Therefore, in black-box testing, security experts are not granted access to the software's source code to be evaluated, while in white-box testing, they are.

In black-box testing, the security assessment starts from what the end user may experience and focuses on the risks associated with the inputs and outputs of the running product. While in white-box testing, the evaluation concentrates on the internal structure and workings of the system at the code level.

When it comes to pentesting

When what we intend to do is penetration testing in black-box mode (a method that we can associate with the term "red teaming"), it is as if we were working from the perspective of malicious attackers on the Internet. Although we do not receive initial permission to see the source code, we could manage to do this with vulnerability analysis and exploitation skills.

So, assuming we prove to you that we can get to a part of your code without you having allowed us to do so, we could then ask you the following question: "Do you then want us to proceed to do a thorough evaluation of your code to see what other vulnerabilities we can detect there?" By that time, your reluctance to white box testing may have already been minimized or even disappeared, recognizing that your code is exposed to threat actors.

However, supposing that in a given period doing black-box pen-testing, we have not managed to penetrate your code, you might ask us the following: "If you have not succeeded, then does this mean that my product code is safe from malicious hackers?" Worse, you might not even ask us this question but immediately assume it to be true and give up on the security testing. But the most sensible answer to that question would be, "We don't know, but chances are it's not."

If you want to know more about this, you can read our weekly blog post here: https://fluidattacks.com/blog/rely-on-code-assisted-pentesting/