Providing access to the source code during a pentest has mainly advantages or disadvantages, depending on the point of view!
Here is our feedback, which relates in particular to web application pentests.
What does source code analysis consist of during a pentest?
Before getting to the heart of the matter, let’s clarify what we mean by giving access to source code, in the context of penetration testing.
A pentest is a security audit from an attacker’s perspective. In fact, most attackers do not have access to the source code of the web application to be audited.
If access to the source code is provided, can we still talk about a pentest?
It is then a slightly hybrid approach that allows taking further certain aspects. Providing access to the source code during a pentest means that it will consist in carrying out tests from the point of view of an attacker (black box or grey box penetration test). Nevertheless, pentesters will have the possibility to consult the source code if they judge that it is useful to facilitate or deepen their research.
In this case, there will be no question of performing a complete analysis of the source code, as this is not the objective of a pentest. A source code audit involves analysing the code in depth to identify vulnerabilities or security improvements. It is no longer a pentest as such.
What are the disadvantages of providing access to source code during a pentest?
Do not bias the attacker’s approach
This is the first reason, which typically concerns companies wishing to assess or prove a level of risk in case of a cyberattack.
If the objective of the penetration test is to assess the risk in case of an external attack, black box tests (without any information provided to the pentesters) are perfectly suitable. To assess the risk from a malicious user, grey box testing (with user access) will provide realistic feedback. Typically, a SaaS solution provider will need to know the risk of external attacks as well as the risks toward its other customers if one of its customer accounts is compromised. A black box and grey box pentest is perfectly suited for this.
If the source code is provided to the pentesters, they will have access to elements not visible to most attackers, which amounts to giving a maximum level of information beyond the perimeter exposed to attacks. The security feedback will be potentially very interesting, but it might go further than what is considered a priority, as it will go beyond the publicly exposed perimeter. In some cases, there is a possibility that developers downplay the security feedback by saying “yes, but it’s too easy because they had the source code”. That’s why it is necessary to clearly define the objectives of the pentest and the expectations of the client’s technical team.
It should be noted, however, that in practice, the fact that the pentesters have access to the source code will not prevent them from also conducting realistic external attacks, and from giving feedback on the risks in order of priority.
Confidentiality and trust
Trust is a central aspect when it comes to finding a pentest provider, and even more so if source code is to be shared. Indeed, source code is the intellectual property of the company, and a significant part of the value of a software editor or a startup.
The pentest contract will include confidentiality clauses to protect the client. It is also in the client’s interest to question the reliability of the service provider, the company’s profile and that of the security auditors.
Secure transfer
In addition to trust itself, and respect for the confidentiality of the information exchanged, there is the question of transferring the source code securely.
This issue is usually solved in the following way:
- If the client’s source code is on Github (or an equivalent), temporary external access will be opened for the pentesting team
- Otherwise, the client can provide an encrypted archive containing a copy of all source code files, via a secure file exchange platform.
Psychological factors
Finally, some resistance may be of a more psychological nature. We sometimes hear from clients: “we already know that in some places our code is not very clean, so we prefer to tidy our room before letting other people in”. Indeed, for developers, there may be an uncomfortable feeling of having to show everything, which may contribute to a desire to focus on external risks, at least initially. However, the objective of penetration testing is not to judge the quality of the code, but to focus on the aspects that impact on security.
What are the advantages of providing access to source code during a pentest?
Mapping and scope identification
During a penetration test, the mapping phase enables to identify the scope of the attack surface. In concrete terms, this involves a lot of enumeration, in order to identify the application’s paths, which consumes time and resources. As this phase is necessary, but does not represent much added value, having access to the source code saves time on mapping and allows more time to be spent on finding vulnerabilities.
It is worth keepin in mind that this phase can have an impact on the scope of the pentest, in the event that new exposed portions are discovered. Depending on the project, the scope may be extended accordingly, or the new exposed portions may be reported in the audit report without being included in the penetration test.
Vulnerability discovery and exploitation
Having access to the source code also makes it easier to work on the discovery and exploitation phases, to redeploy part of the effort on the most complex searches requiring a high level of expertise.
For example, reading the source code makes it possible to check directly the updates of the various components of the application (libraries and other components), to identify this type of vulnerability. Reading the source code also makes it possible to validate certain hypotheses more quickly, particularly regarding access control tests, which are usually time-consuming.
In terms of exploitation, a typical example concerns XSS flaws: seeing directly in the source code what control rules have been put in place makes it easier to bypass XSS filters. This ultimately allows a better assessment of the impact of XSS flaws in case of successful exploitation by an external attacker.
Exhaustivity of the tests
In a pentest, the question of exhaustivity may arise, if this is an objective that has been defined beforehand with the client.
Certain types of flaws can be massively present in an application: we regularly see this case for XSS flaws. A code assisted pentest allows the pentesters to understand the origin of the problem and to show where the flaws are systematically present, without the risk of forgetting certain URLs.
Guidance for correction
This aspect is related to the remarks on exhaustivity. Identifying the errors in the source code allows identifying all the places where certain types of flaws are present. And therefore to provide suitable recommendations for fixing the flaws in the web application.
In general, by having access to the source code, pentesters can make more relevant recommendations, as there are fewer assumptions or guesses about how the code is built.
Directing and prioritising certain tests
Moreover, consulting the source code, without analysing it completely, can help to orientate the research during a penetration test.
Especially in the case of a non-exhaustive pentest, with limited time to search for the main vulnerabilities present in an application: consulting the source code allows an experienced pentester to have an understanding of its quality level and to prioritise certain tests accordingly.
For or against providing the source code to pentesters?
As mentioned at the very beginning of this article, this question must be decided according to the objectives that the client’s team has set for the pentest.
Some CTOs conducting penetration testing will be sensitive to a strict black box or grey-box approach, others will be sensitive to sharing source code to go further.
From our point of view, code assisted penetration test has advantages, since it allows the pentest to be optimised without obstructing external testing or testing from the point of view of a standard user. It should be noted that for the same scope, providing access to the source code will have little impact on the service budget, since the time saved on certain tasks can be reinvested in other tests.
What our experience shows is that as pentests are repeated, the security level of a web application increases, as developers pass on the feedback from previous pentests to new developments. In some cases, the results of the pentests can be used to establish a real internal security culture and a security roadmap for the development team.
This is why we recommend, after several black box and grey box pentests on the same scope, to systematically provide the source code for the next pentests in order to push the analysis further and allow security recommendations complementary to what can be detected by a classic pentest.