To whom it may concern…

Imagine having legitimate concerns (or being a good citizen and having security policies that require regular security audits to be performed against the software and infrastructure your company uses). You get in contact with a security company and task them with performing a penetration test against Software XYZ, provided by Software Engineering LLC. You contact Software Engineering LLC and ask them for temporal access to source code in order to perform a white box penetration test. However, the Software development company refuses to provide access to the source code. You, as the customer, do not have much of a say in this; after all, it’s their legal right to refuse to lay open their source code.

Without access to Software XYZ’s source code, the penetration testing company is tasked to perform a gray- or blackbox audit with the goal of identifying security-relevant flaws. Although it is possible to perform these types of audits and uncover vulnerabilities, the resources invested in understanding, identifying, and exploiting them skyrockets. On the other hand, having access to documentation and source code (the beating heart of the very thing you would like to confirm is healthy), the correct functioning of the software under test can be understood both more quickly and more accurately. You no longer force the testers to wear an artificial blindfold while performing the surgery.

The fact that you, a customer of Software Engineering LLC, pay a security company to audit their software for weaknesses should be both welcomed and supported by Software Engineering LLC by granting temporal access to source code and documentation. After all, one of their customers (you) is paying a security company to make their software better ultimately. This is especially the case when Software Engineering LLC. benefits from the identified flaws (reported back to them through a joined meeting). As you finance such an audit, the developers of this software and their customers reap the benefits of the identified flaws for “free”, they should, without a doubt, cooperate with you and the security company.

Withholding source code (and or documentation), which I consider being uncooperative, leads to less accurate testing, makes testing harder in general, and is neither cost nor time-effective. If Software Engineering LLC fails to understand this; it may be time to look for alternative software providers (give open-source software a try). They are not concerned about providing you with secure software, and they for sure as hell are not interested in offering security engineers with a chance to perform a formal/scientific review of the written code.

The year is 207724; there’s no single good reason to refuse to cooperate in the joint effort and goal of making software more robust and secure.

We’re not the fucking enemy, show us the damn code.