White box testing basics: Identifying security risks early in the SDLC

When it comes to software security, 85% of users believe it’s the responsibility of those who are closest to the code—the developers and engineers. This is no surprise, considering that the majority of vulnerabilities are created early in the software development life cycle, even before the software is deployed to production. For someone without insider knowledge of the systems or software being tested, many of these vulnerabilities can also be very difficult to discover.

This is where white box testing comes into play. In this article, we’ll explore the white box application security testing method, how to perform it, and its benefits and drawbacks.

Explaining white box testing

White box testing diagram

The main defining characteristic of white box testing is its "see-through" nature; hence, it is also known as glass-box testing, clear-box testing, transparent-box testing, and open-box testing. Because the tester or tool is familiar with the software’s internal working structure and knows what the code is supposed to do, the security of the software can be tested by examining how well it resists attacks.

White box testing is the opposite of black-box testing. With black-box testing, just as the name implies, the security tester does not have access to the software or networks and therefore knows little or nothing known about the target. The pen tester tests the application to uncover vulnerabilities in the same way an external attacker would.

The purpose of white box testing

Why should software be white box tested? Why is white box testing important? The answer is twofold:

1. It uncovers security risks.

According to the State of the cloud native application security report, over 56% of users experienced a misconfiguration or known unpatched vulnerability incident involving their cloud-native applications. Application security is crucial, and overlooking it could lead to disaster. Timely knowledge of security bugs can help eliminate risks and prevent the high cost of security breaches, which can erode the customer’s trust in your ability to handle their data (and may even lead to lawsuits).

Many security vulnerabilities–such as insecure deserialization, misconfiguration, exposure of secrets, and broken access control–result from programming errors in code. The risks posed by these vulnerabilities are difficult to rectify without white box testing.

2. It uncovers bugs and improves quality.

Software teams are agile and frequently deliver updates based on user feedback and changing markets. Regular updates and changes should be made without ruining existing features. Nothing annoys users more than an update that hampers popular existing features. White box testing is crucial for timely detection of bugs and breaking changes in software.

To summarize, white box testing is essential for detecting bugs, potential security loopholes, and performance problems early on.

Types of white box testing

There are many different types of white box testing:

• Execution/unit testing: This type of white box testing is conducted by running a portion of code and comparing the output to the desired outcome. If the expected outcome is not produced, it means a defect exists and must be corrected. Execution testing is done on a continuous basis.

• Static testing/structural analysis: This involves carefully analyzing a codebase for bugs and vulnerabilities without actually executing the code. For example, a tester might analyze a codebase with static application security tools (SAST) to identify vulnerabilities. With SAST, the application is thoroughly analyzed based on specific findings, such as configuration analysis, semantic analysis, data flow analysis, and more in order to keep the source code secure.

• Mutation testing: This is normally done as the last stage. It entails a general bug check as well as analysis to determine the optimal coding strategies for program expansion.

What does it test?

First, to perform white box testing, you need to understand the software you’re testing and know the code and its expected behavior. The next step is to create test cases by writing additional code to verify where execution could go wrong and where vulnerabilities could be exploited.

Generally, white box testing covers:

• Internal security holes

• Flow of specific inputs through code

• Expected and unexpected output

• Broken or poorly structured code paths

• Logic of a conditional loop

• Behavior of each of the functions and classes

• How the software handles specific inputs

White box testing techniques

White box penetration testing is a crucial part of security testing, since it provides a full analysis of both internal and external vulnerabilities. Collaboration between security testers and developers lends a high level of system understanding and possible ways a system may be exploited. An example of a white box testing technique could be verifying the security and reliability of a banking app and ensuring there are no loopholes in the business logic.

Common techniques used in white box testing include:

• Condition coverage: A technique used to test the variables in a substatement through logical conditions

• Statement coverage: This technique involves executing a set of tests on statements in the code, often known as line coverage. Every statement is tested at least once.

• Branch coverage: Testers use this technique to ascertain that code branches are tested at least once.

• Path coverage: Usually carried out to test each individual path in an application.

• Data flow testing: Used for examining the flow of data in software with reference to the variables in the code.

White box vs. black box testing

White box and black box testing are methods for detecting flaws in software. While they are both prominent testing techniques, they are markedly different. The table below lists the key distinctions between them.

Black box testing diagram

White box and black-box tests are therefore not interchangeable. It is not enough to carry out only one or the other. Rather, these two testing techniques complement each other to help deliver better software. When white box and black-box techniques are used in combination to test software, the resulting technique is known as gray-box testing.

The pros and cons of white box testing

White box testing has its own advantages and disadvantages.

Pros:

• Tester has prior knowledge of the system being tested, drastically saving the time it would take to obtain information or conduct reconnaissance.

• More thorough tests and the discovery of more security risks than with any other testing technique.

• Can be integrated with CI pipelines with the help of automated security tools such as SonarQube, thanks to its low-level nature.

• Technique is closer to the code, allowing developers to easily remediate vulnerabilities discovered.

Cons:

• Due to its thoroughness, it’s the most time-consuming and expensive testing technique.

• Requires deeper knowledge of the system under test.

Conclusion

Due to its very nature, white box testing is a crucial part of embracing DevOps culture in the secure software development life cycle. Because white box tests can be automated, they are usually executed in CI pipelines to provide developers with fast feedback as they check their code.

White box security testing tools like Snyk Code bring static application security testing into the DevSecOps pipeline, providing developers with the highest level of test coverage required to identify security risks early enough in the development process.