Securing Your SDLC with Continuous Penetration Testing

Last Updated on 7 June 2023 by Alastair Digby

Agile methodologies and DevOps practices characterize today’s fast-paced development world with most companies focusing on accelerated application delivery, shorter development cycles, and more frequent releases. These features enable businesses to leverage software as a competitive advantage, whether that means building in-house applications that drastically improve productivity or releasing an app that solves important problems for customers or other organizations.

A major problem is that application vulnerabilities remain a primary cause of data breaches. Underpinning this issue is the use of legacy application security tools and approaches in the software development lifecycle (SDLC) that don’t keep sufficient pace with development. This article explores how securing your SDLC with continuous penetration testing removes bottlenecks, improves your security posture, and aligns with the kind of shift-left testing approach that facilitates releasing secure software using modern, fast-paced development practices.

What is Continuous Penetration Testing?

Continuous penetration testing is a different kind of pen test that departs from the traditional snapshot, point-in-time test, and attempts to reflect continual changes in the security posture or attack surface of an environment. This is not a cost-prohibitive approach because it doesn’t require dedicated pen testers to test your environment 24/7.

The way continuous pen testing works is that your web applications are security tested as your software is developed giving you the assurance that every release is secure. Integration with bug tracking products, continuous development platforms, and other tools helps to feed relevant information to your scanning capability and trigger an in-depth security assessment by pen testers to focus on the features that you’re developing.

For a much more in-depth look check out our previous article on continuous penetration testing.

What is Shift-Left Security Testing?

Shift-left security testing is an effort to include software security testing as early as feasible within the SDLC lifecycle. This contrasts with the traditional way of testing application security, which is typically annual and could be at any time in the calendar year. This traditional approach is risky and can lead to bottlenecks as code gets sent back to developers to fix defects identified during testing. Since the time spent fixing these defects late in the development cycle conflicts with the aims of DevOps practices, shift-left testing helps to discover issues earlier, avoid lengthy development delays, and ultimately release more secure code into production.

Software engineer Larry Smith coined the maxim to “test early and often” as far back as 2001. This was at a time when Waterfall was the prevailing development model. Today’s DevOps teams often use eight-step CI/CD pipelines to automate software delivery, and the 4th step in these pipelines is to test. Shift-left security testing tries to embed testing at earlier steps in this pipeline, during the Build and Code phases.

By embedding security so early into development, you start to change the approach from DevOps to DevSecOps, with obvious benefits in reducing cyber risk exposure. Some examples of shift-left testing types include:

• Static application security testing (SAST) tools that scan source code for known weaknesses and vulnerabilities and are often integrated into developer environments for rapid detection and remediation of security issues in code.
• Software composition analysis tools that focus on third-party app components, such as libraries and frameworks upon which an application’s functionality depends but for which vulnerabilities aren’t detectable in source code scans.
• Tools that scan container images for vulnerabilities or risky components.
• Tools that scan cloud infrastructure for the kinds of misconfigurations that can easily lead to sensitive data exposure or open up an attack vector against cloud-hosted apps.

Importance of Shift-Left Security Testing

One statistic that demonstrates the value of shift-left testing is that 85 percent of code defects get introduced during the Code and Build phases of the development pipeline. From a security testing standpoint, testing earlier reduces the costs of finding and fixing security vulnerabilities later on while also ensuring project delivery schedules aren’t bottlenecked.

Shift-left security testing also helps to build a culture of secure coding practices among developers which ultimately benefits organizations in the long run. As security tests make their way into earlier phases of the SDLC, developers, and engineers start to become more adept at recognizing the types of security shortcomings that stem from various risky coding practices.

Implementing Continuous Penetration Testing into Your CI/CD Pipeline

While the importance of shift-left security testing is indisputable, there are still ways for security weaknesses to make it into production where threat actors will use their full range of technical skills to try and exploit such weaknesses. Part of the problem is the CI/CD pipeline’s focus on speed over security.

Another difficulty is the broadened attack surface. Along with a lengthy list of components and dependencies for any app, you’ve got repositories, servers, containers, virtual machines, and cloud infrastructure constantly being spun up. There are a lot of moving parts in these pipelines, and a lack of full visibility into the evolving application attack surface or any security validation of changes can feasibly lead to the kind of breaches that keep CISOs awake at night.

By integrating continuous penetration testing into your CI/CD pipeline, you start to plug the gaps that existing shift-left security testing tools and types just don’t cover sufficiently. The high levels of automation provided by asset discovery give you a single pane of glass into your evolving application attack surface. This continuous security monitoring coupled with on-demand pen testing in response to environmental changes or flagged risks makes pen testing far more agile and capable of handling a large, complex attack surface.

Informer’s Approach to Continuous Penetration Testing

Informer’s approach to continuous penetration testing reflects the dynamic and constantly evolving application attack surface in modern development methodologies. With weekly or even daily releases, potential attack surface changes can easily fall outside the scope of a pen test. Developers continue to code and tweak infrastructure after this scope has been set, and any impacts on the attack surface won’t be reflected in the quickly outdated scoping document.

Instead of this static and inflexible way of doing things, we advocate for considering penetration testing as a part of the development life cycle. Think of continuous penetration testing as a living document that automatically updates and reflects real-time changes streaming in from your application’s attack surface.

By coupling continuous pen testing with Informer’s with automated asset discovery, integration, and vulnerability scanning capabilities, important application changes can be automatically fed into the system and trigger real-time pen testing to validate security. Whether it’s a Jira ticket indicating a deployment or a CI notification about a new release, a focus on automation ensures the most important attack surface changes are presented quickly to pen testers. This approach inherently shifts pen testing back to the left in the SDLC cycle, which means results get quickly fed back to teams and fixes are more cost-effective.

An added bonus is that your cyber risk posture reduces because malicious outsiders won’t have time to probe at application attack surfaces that haven’t been properly validated and tested. Rather than assigning fix-up tasks to a team that may never have worked on the feature, (as the original team has now moved on), the short cycle times between changes found to be vulnerable by continuous pen testing and feeding that information back to DevOps teams will enable a new definition of done—done and sec tested!

Securing Your SDLC Helps Improve Your Application’s Security Posture

Start to improve your security posture today by implementing shift-left testing with Informer’s attack surface management platform, which comes with automated asset discovery, continuous monitoring, Jira integration, and a modern pen testing approach directly accessible from within the platform. Coupled with other shift-left security testing tools, you can take control of your application attack surface, fix security issues earlier, and ensure Agile SDLC and DevOps workflows flourish.