The More Access, the Better

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.

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.

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."

To limit the time available for penetration testing is to limit its depth. This is an activity that must be carried out continuously. Unlike ethical hackers who were forced to do so, threat actors may not abandon their search for vulnerabilities. They can, for example, look for authorization bypasses and privilege escalation vulnerabilities, which, alas, are pretty common in applications nowadays, to reach admin accounts. From there, they may identify vulnerabilities, for instance, in the restrictions for uploading and downloading files, and achieve access to the source code. The worst may come from there, according to the vulnerabilities present in the code.

Given that, whoever it is, someone will likely access the code of your applications or infrastructure, isn't it better to save time and go immediately to evaluate it to find and remediate its security issues and thus prevent damage to your data (including those of your users) and operations? It is understandable that your hesitation is linked to protecting the privacy of your intellectual property. But you can safeguard this with the help of a company that is genuinely committed to cybersecurity, from which you can easily verify its good reputation and integrity, and from which you would receive legal assurances of confidentiality such as a non-disclosure agreement. You should request white-box pentesting or, better, "code-assisted pentesting" from that company.

You may ask us, "If I give you access to my source code, would it still be penetration testing what you offer?" The answer is "yes." In code-assisted pentest, the attacker's point of view is not set aside. Simply put, as the name suggests, pentesters rely on your source code for assistance. It ends up being a collaborative effort in which the interaction between security and development teams can be critical to understanding the product and its security issues.

The code visibility gives security experts maximum scope for their assessment. It allows them to perform a broader, deeper and more accurate analysis in which they can easily link their findings to specific locations in the code. In addition, they can report types of vulnerabilities and misconfigurations that can be seen only in the code, or that would hardly be noticeable in the functionality or logic of the application under evaluation. However, it should be clarified that it is not always necessary to have access to all the code in a repository and that, in fact, pen testing is not the same as secure code review. In the latter, the aim is to perform a complete analysis of the source code, while in the former, more emphasis is placed on priority objectives (e.g., critical application components) and risks defined in conjunction with the client.

It is important to note that code-assisted pentesting allows pentesters to save time in the reconnaissance and enumeration phases. That is, they can more quickly find access paths and weaknesses and define appropriate attack vectors, such as those related to the injection of specific commands, according to the security controls present in the code. Also, this form of penetration testing allows remediation recommendations and guidelines to be more accurate, not resorting to assumptions. Identifying and reporting specific vulnerability locations within the source code facilitates the remediation process for your developers.

At Fluid Attacks, when it comes to penetration testing (because we also offer automated testing such as SAST, DAST and SCA and manual testing such as secure code review), we focus on providing continuous code-assisted pentesting. Within our company, we recognize this methodology's enormous value for broad recognition of an application or infrastructure's attack surface and for fortifying an organization's cybersecurity posture. We are aware that not reviewing the source code usually represents a very high exposure to cybersecurity risks.

We want to remind you of something we have noted before. The fact that your code is not publicly visible does not mean that it is secure. Its security depends mainly on the good practices followed throughout its development. Again, it is clear that with the privacy of your code, you can seek to protect your intellectual property. Still, we guarantee you can establish a relationship of mutual trust with us. With our tools and ethical hackers, we will pursue keeping the risk exposure of that information and your software products, in general, to a minimum.

Do you want to start with a free trial where primarily our tools can access your code? Take advantage of our 21-day free trial right now. Want to start with the whole package, including our AI and ethical hackers? Contact us, let's talk, get to know each other, and establish a long-term business relationship on behalf of your cybersecurity.