Where Should Pen Testing and Source Code Review Fit Into Your Dev Lifecycle?


You want to create an attention-grabbing app. Armed with strong core concepts and a functional sense of purpose, you set out to capture user attention, win market share or do whatever else drives you.

You’ve got motivation, but you’ll need more than that if you want people to rely on your app. You’ll have to ensure that they can use it safely.

Pen testing and source code review are integral to strengthening your application’s security backbone. Here’s a quick breakdown of why and where they might fit into the lifecycle.

Why Test?

Testing is the best way to verify the correct operation of a system. In applications and other software systems, many different functions, libraries, routines and components work together to accomplish some task. Testing verifies that they do what you intended.

Security testing takes many forms. The general goal is usually to ensure that the application does its job without creating too many vulnerabilities that expose your software to

  • Cybercrime,
  • Hacking, or
  • Internal Errors.

Critical Security Practices in Action

Imagine you want to let people sign into your web application or smartphone app. Most of your users are on social media, so you decide to have them sign in with those accounts. Adding this feature could raise possible vulnerabilities, such as whether you’re

  • Transmitting private data safely between users’ web browsers or devices and your servers,
  • Using third-party tools, such as user account credential APIs or open-source encryption libraries, that have known risks,
  • Preventing your servers from being hacked,
  • Assigning the correct administrative permissions to different users, and
  • Protecting personally identifiable information, or PII, such as names and addresses.

It’s possible to mitigate these and many other risks with two key security testing processes: source code review and pen testing.

Source Code Review Simplified:

The source code of your application is its brain. Source code review reads it line-by-line for logical and other errors.

By scanning the code programmatically, common mistakes and vulnerabilities can be exposed. From there, professional penetration testers can review potential problems.

A Pen Testing Primer:

Your live deployed application exemplifies your software’s behavior. Penetration, or pen, testing attacks it in a controlled environment to understand how it responds. This automated and human-guided process highlights weaknesses and vulnerabilities that might occur in the real world.

The Practical Distinctions

Source code review and penetration testing involve different techniques. At the same time, they accomplish similar ends. They improve app security and heighten user or stakeholder confidence.

For many developers, the question isn’t whether to use both. It’s when to leverage each. To understand the answer, just think about how each works:

Pen testing is done on operational systems. It needs to happen when you have live deployments, but before you’ve pushed something to users.

In most cases, you’ll pen test before you deploy elsewhere. You’ll need a sandboxed, known-safe server or environment that you control and a version of the software ready to go.

Source code review should also happen before live deployments. It usually takes place after you’ve done your own internal testing.

Source code review features line-by-line scans instead of a potentially long-running stress-test. Thanks to software tools, you can use automation more than you can with pen testing, so it’s a quicker procedure.

This speed difference generally holds true even with thousands of lines of code, so you might wait longer between pen tests. For instance, if you stick to semantic versioning, then you could

  • Review source right before deploying every major version,
  • Pen test after finalizing every major and minor version, and
  • Do both after critical bug fixes or patches.

Are these guidelines iron-clad?

Each development lifecycle has its unique distinctions, so these are just rules of thumb. Project budget limitations and timetable constraints may make it advisable to switch things up, but both processes are must-haves.

Originally Published on infosecurity-magazine