The Future of AppSec Depends on Force Multiplying Talent
Solutions Review’s Expert Insights Series is a collection of contributed articles written by industry experts in enterprise software categories. Peter Morgan of Phylum predicts that the future of AppSec depends on successfully force-multiplying the talent pool.
To plan for the future of Application Security (AppSec), we must rethink our ability to hire and retain talent. Ahead of the economic downturn of 2022, Application Security roles had double-digit negative unemployment rates. These roles were difficult to fill due to the number of roles open, and the challenging experience required by them. These variables caused compensation to skyrocket, and massive tech companies will scoop up more of this small skilled talent pool, leaving gaps for everyone else. This paints a picture of the future reality where application security programs cannot scale as they exist today. There simply is not enough talent to go around for everyone without change. To solve this, we need to consider how AppSec engineers can become force multiplied.
One of the shifts AppSec will need to make is the proper use of tools to enable skilled AppSec engineers to cover many more developers than they currently can. To accomplish this, we’ll need to consider changes in the software development process to assist this effort.
[box style=”3″]
In the market for AppSec solutions? Check out our free Buyer’s Guide!
[/box]
The Future of AppSec
Standardized Development Languages
The shift to microservices changed the landscape for how companies write software, hire developers and manage their infrastructure. Microservices brought the idea that developers can use the best language for the job, as long as the API contract is upheld. This was a tremendous improvement in many ways. Unfortunately for security tooling, this effectively destroyed the Static Analysis Security Testing (SAST) category of tools.
Back in the day, companies had “house languages.” If you worked there, you either wrote in C, C++, Java, or .NET for the most part. House languages were great for SAST tools, because it meant a smaller set of language support to reach that ever-so-critical inflection point of value to customers of SAST. Microservices changed everything. Today’s application from 40,000 feet is spread across many more languages. While there is a benefit to mapping the right language for the job, some of this sprawl comes from developer experience (DX). Developer experience sprawl can be seen in both choice of source code language, and choice of in-language framework. Merits aside, this presents significant difficulties in successfully using SAST and Dynamic Analysis (DAST) security tools.
Effective static analysis is one of the most challenging problems in both computer security and computer science. Most of this stems from the deep analysis required to identify a meaningful amount of vulnerability classes. Yet, if you poll the product satisfaction of a group of engineers forced to use SAST products, you will likely be cleaning yourself off from the vomit of complaints of false positives. This problem might seem more tractable with recent advances, except for the sprawling language requirements most companies now have. SAST products struggle to maintain the breadth of language support while providing the depth analysis capability needed to provide customer value.
Standardized Development Frameworks
Along with the shift to microservices that weakened the value of SAST tools to security teams, DAST has experienced a similar issue, albeit related to software frameworks used to rapidly architect software products. The explosion in the number of frameworks used by companies today means it’s extremely difficult for DAST product vendors to do a good job on a small set that provides lots of value to their customers. This is similar to the depth vs. breadth problem in SAST.
DAST tooling usually needs to understand how data flows through an application and where security boundaries live. DAST is a bit like setting up a debugger on the target software and recording the analysis during runtime to identify violations of security controls but in a highly automated environment. If you must customize for application, it will be untenable to the speed of development. Often in the past, DAST products were/could be developed around development frameworks, such as Python’s Django or Ruby on Rails.
I argue that a significant percentage of the language and framework choices made over the past five years have been more for developer experience (DX) than for the project’s needs. DX-driven choices in the framework became drastically less impactful once microservices had already weakened the utility of the then-current state of SAST capability. We can reign in the framework sprawl through standardization and enable DAST tools to provide additional value to our AppSec engineers.
A Foundation for Solving Modern AppSec Challenges
AppSec approaches will need to evolve in order to solve future challenges. Standardizing to both a reduced set of accepted development languages and a reduced set of accepted frameworks will enable security tools to empower AppSec engineers through force multiplication. Awareness and planning in advance can enable streamlined access to the future state where AppSec is more resilient to staffing challenges and the ever-increasing speed of software development.
- The Future of AppSec Depends on Force Multiplying Talent - July 5, 2023
Peter Morgan
Peter is a security researcher with a long history in research and consulting organizations tied to some of the smartest people imaginable. As an individual contributor, he has audited systems, technologies, and software as targets for both customer and research projects. In his current role, Pete is proud to have helped build a team composed of software developers and vulnerability researchers with over a decade of experience.
