Application security penetration testing has stagnated. AppSec hasn't had any developments that compare in breadth and scope to red teaming, the more holistic approach to network pentesting. Yes, we continue to work around the margins of the common vulnerabilities that are inherent to web and mobile applications, and new vulnerabilities will continue to impact server software and middleware. But we have not evolved our testing methodology alongside the development methodologies we have informed. And no, duct taping generative AI onto our existing tools in the vain hope a use case or two will fall out doesn't count. At (Re)clarative, we believe it is time to pursue new AppSec testing strategies through the development of new tools.

The Story So Far

Penetration testing has broadly organized around the management consulting model under which businesses outsource their network penetration testing (netsec) to consulting firms. This model took hold because organizations need to understand the risk their IT infrastructure exposes them to, but maintaining a full time staff of cybersecurity specialist isn't cost effective. Application security penetration testing, or AppSec, is a natural outgrowth of the netsec model because web and mobile applications are logical targets for attackers since they are a business's public face in the digital world. They present attack surfaces that are relatively easy to probe for weaknesses while exposing attackers to minimal risk. If an attacker can compromise a web app, they have foothold for mounting attacks further into the hosting network or targeting the users.

While netsec pentests often find and exploit vulnerabilities in applications, this is in service of the larger goal of assessing the network's overall security. They do not systematically test applications. Enter application security pentesting. Because web and mobile apps, by necessity, present such tempting targets to attackers, it is essential that they be rigorously and extensively tested beyond a standard pentest or even a red team. The infrastructure supporting and servicing these apps needs to be secure, yes, but the apps themselves must also be as resistant to compromise as possible.

Diminishing Returns

Because AppSec organically developed as a specialization in the broader netsec space, most of our methodologies are extensions or modifications of netsec methodologies. While this has been quite successful in the past, its inherent limitations are becoming more and more apparent. Developers have become more cognizant of application security best practices, and frameworks have become central to web and mobile development. Traditional application pentests are yielding fewer and fewer findings in aggregate.

Simply giving an application a clean bill of health, or rather security, is not perceived as valuable, and neither are pentests that yield few if any results. This counterproductive attitude is leading to complacency. As the security of applications continues to improve, AppSec will come to be erroneously perceived as a "solved problem" and thus a cost that can safely be eliminated. But application security, just like development, never really ends. Active testing and validation of applications is valuable work even when it doesn't yield attention grabbing vulnerabilities like SQL injection or remote code execution. We need to remember that penetration testing, in general, is about vigilance.

Changing Course

With that in mind, AppSec needs to adapt to this new landscape we've helped create. We need to move beyond the monolithic, timeboxed assessments to a more incremental process. As successful as the traditional consulting model has been at producing results in the past, it very much clashes with modern software development lifecycles. There is a dissonance between the two which, in the computer science realm, we might call an impedance mismatch (a term borrowed from electrical engineering). This mismatch is because we are trying to couple two very dissimilar models. Normally, we think of impedance mismatches as occurring between two software models (e.g., object oriented programming and relational databases) where compatibility is achieved through the careful development of a software layer. But, when it comes to AppSec pentesting, the interoperability is borne entirely by people. Not only is it an inefficient use of person hours, it also lacks the reproducibility which is central to software development.

Software lifecycles are built around flexible, responsive tools like version control, bug tracking, CI/CD (continuous integration/continuous delivery), and unit testing. The traditional consulting approach of delivering finalized, formal reports is directly at odds with all of these tools. It is actually quite remarkable just how crudely software pentesting integrates with development. The impedance mismatch becomes all too apparent when you compare pentesting to pretty much any other form of software testing. There is a whole discipline called test-driven development that AppSec simply cannot participate in. AppSec testing shouldn't wait for the annual pentest. It needs to directly integrate into development lifecycles. AppSec should result in more robust CI/CD pipelines and more bugs filed.

Stepping up the AppSec game is our mission here at (Re)clarative. Our goal is to develop and implement new AppSec testing paradigms that harmonize with the iterative, incremental approach of modern software development.