by Douglas Berdeaux

Determining where in your software development lifecycle (SDLC) to have a penetration test carried out can be tricky. This article aims to guide new development shops at a high level on when the best time to have a red team assess your applications for potential security vulnerabilities and touch upon why penetration testing in the SDLC is important.

After laboring away for many years as a developer, and speaking with developers throughout my time as a penetration tester, I can’t help but feel that security can be an annoying hurdle to those who build the applications and services that we all use every day in almost every aspect of our lives. Believe me when I say that I have heard some pretty funny horror stories about overbearing cybersecurity and cyber risk teams. That being said, I have also heard even more gruesome horror stories of developer workstations being compromised and intellectual property and user data stolen by threat actors. My goal as a penetration tester always aligns with my clients; ensure that their user’s data is as secure as possible while also ensuring developers can freely write code and build out functionality in applications.

Secure code writing courses are a fundamental step in developer’s career paths, but they’re definitely not the end-all-be-all security requirement for developing secure applications. Some development teams don’t talk about security at all during the planning and coding phases of the SDLC and leave a lot of the heavy lifting of security up to frameworks. This frees the development teams from added work, planning, and possibly false limitations so that they can focus on designing the best applications they can.

Some clients have DevSecOps teams that deploy security control solutions that allow developers to continuously work together while doing their best to ensure that the code is free of bugs and vulnerabilities. These controls may include checks such as static code analysis and library and component version reviews that occur locally on developer machines in pre-commit hooks before code is uploaded for peer review into the client’s repositories. There’s also the “shift left” movement within DevSecOps that ensures security and review are considered earlier on in the development process to avoid heavy restructuring of the application’s architecture or design as the client gets closer to the planned release date. This shift may include asset management processes, vulnerability scanning, threat modelling, and may catch security misconfiguration issues of hosts and containers, networking equipment, and obviously the services that provide the applications to the client’s users. One more check that clients may do is to aim a top-of-the-line vulnerability scanning tool that hunts for potential vulnerabilities at applications already deployed in staging or testing environments.

While these processes advance progress and innovation while lowering the risk of a breach, we have to consider penetration testing. Penetration testing goes beyond vulnerability scans by allowing a team of testers to simulate real world threat actors using novel attack tools, tactics, techniques and procedures. In doing so, they often uncover undefined behavior and business logic flaws in applications and demonstrate the impact of any identified vulnerabilities by seeing how far they can take the testers into your environment and databases. Let’s begin by taking a look at the current standard software development lifecycle in continuous integration and development and deployment (CICD) loop diagram as shown in the image below.

In this workflow diagram, developers typically start at the plan phase and follow the remaining steps in the order that the diagram shows. So, where does penetration testing fit into the diagram above? Well, let’s consider the fact that business logic testing is actually part of the penetration testing process. This means that the safest bet for planting a penetration test into this flow may be at the end of the test phase. Once all code has passed the local and remote checks, the application is thoroughly tested by a user simulation testing team, and all issues identified are remediated, then, the applications should be ready for a penetration test. I mostly encounter this scenario as a consultant; I am usually provided access into my clients’ staging environments where newly deployed applications await thorough penetration tests. Once the report is delivered any remediation recommendations of identified issues might backtrack the client’s developer or DevSecOps teams back into the plan phase to reassess the application, components, and possibly its technology stack.

There have been a few times over the years in which I begin a web application penetration test and cannot help but feel like the application just wasn’t ready for the assessment. The client may have scheduled the penetration test too early on in the application’s SDLC. In these cases a large volume of security issues, ranging from low to critical risk, were uncovered just after preliminary testing. The higher risk issues were typically simple user input handling flaws exploited to gain access to the back end systems and databases that could have been identified earlier on using vulnerability scanning software. Now, if we consider the time-box nature of web application security assessments and how red teams spend time reporting during the test, a large volume of issues that should have been caught early on in the SDLC can only limit the thoroughness of the web application penetration test.

In conclusion, deciding where to integrate penetration testing into your SDLC will take time and planning. Obviously, this decision will be hinged upon whether you have an internal penetration testing or red team. Otherwise, performing a full penetration test by a third-party consultant firm upon each test phase in the SDLC will obviously not make sense financially and from a planned release schedule perspective. What clients can do however is have the penetration testers come back in to validate the client’s remediation efforts during the next test phase. Another way clients can get the best bang for their buck is to provide the testers with results from vulnerability scanning software or a granular scope to narrow in on specific areas to test. This can speed up the penetration testing process as the pentesters won’t have to spend so much time hunting and reporting low-hanging fruit and focus more on identifying vulnerabilities that pose more risk.

---

About Douglas Berdeaux, Senior Security Consultant

Douglas was a manager of a Red Team for a consulting company and has performed penetration testing for clients with high security maturity on internal networks, internal and externally facing web applications, and desktop applications. Douglas was a full-stack enterprise-class web developer for close to a decade building, securing, and testing the security of business-critical web and mobile applications. He has taught cybersecurity as an adjunct professor for Duquesne University and has published multiple books and articles about penetration testing, hardware hacking, and programming.

Certifications:

OSWP, OSCP