The changing reality of appsec
How all appsec companies fail?
Disclaimer: Opinions expressed are solely my own and do not express the views or opinions of my employer or any other entities with which I am affiliated.
In the past, I’ve talked about a range of topics in application security. Here’s a sample:
Application security has been around since development existed. However, it’s evolved rapidly as development practices have changed. In specific, development cycles have gotten shorter and faster, especially with the rise of SaaS, which has substantially changed the means of distribution.
Changes in development practices are nothing new, and application security has managed to adapt to or at least survive these changes. Unfortunately (or fortunately depending on your perspective), we’re at a pivotal moment where application security is likely going to make a fundamental shift. This will likely cause a lot of pain for security organizations, who will be forced to adopt these new methods or be considered ineffective. In this newsletter, I’ll talk a bit about how application security has changed over the years, how we got to where we are, and where do we go from here.
Application security used to be less competitive
To set the context, application development cycles used to be slow. Software creation was done on scales of months and years rather than days and weeks. For a long time, companies even had to first procure the proper hardware to be able to support an application before it was even developed. It took years to develop the next version of a piece of software. Microsoft Office was a great example of this. For many years, they had a major release every 2-3 years. As a result, planning for this type of development required substantial planning, and “production” code would only be shipped every 2-3 years.
In this case, there were different parts of the software development lifecycle, and each part would last several months. This is commonly known as the waterfall model. Security reviews and checks were performed at each part, but the benefit was that security didn’t need to be efficient because each part took so long. There was always something else blocking, or at the very least, security wasn’t the only blocking item. The benefit is that security tooling (and engineers) had time, so it could be relatively comprehensive in what it scanned.
As a result, each part of the lifecycle had an application security tool. There was a tool to scan the static code, another tool for binaries, another tool for post-production code, another tool for licenses and open source, etc. There was enough of a market so that each application security product could have a good market share without having to compete with the other products. Since development was slow, application security engineers cared more about the quality of the product. That is, it would find vulnerabilities that they had time to sort through and triage. So, as a product, it was a competitive advantage to spend all your resources on a single product and ensure it remained the best.
Although this was great for companies, it was problematic for application security. It was costly because they needed to buy multiple tools, and as development cycles gradually accelerated, these tools weren’t able to keep up because scanning times would become a blocker.
Enter the cloud and agile
Like most modern development problems, the cloud created application security headaches. It made it easier for companies to start development because they essentially had access to unlimited infrastructure that was also elastic. It also made hosting easier, so it paved the way for SaaS products. This resulted in more and faster releases. However, these releases were smaller, but application security products with long runtimes had to adapt. Now, security was becoming a blocker. Fortunately, cloud adoption was not as fast as people imagined, but application security didn’t adapt quickly. Instead, they focused on the customers who still had slower development models.
In the past few years, we have reached a turning point with sufficient tooling that has made faster releases and cloud-native development easier for companies to adopt. As a result, the way we handle application security has reached a tipping point.
According to the Checkmarx “The Future of Application Security 2024” report,
Application development has changed. It has moved from waterfall development with infrequent releases, to agile development and continuous delivery. Software is deployed multiple times per day, development is complex, and it is increasingly cloud-native. This has dramatically changed how organizations need to secure their applications. […] There is more software deployed in more environments, and less time available to secure it.
If anything, the wide adoption of Snyk and the increased focus on developer security as part of application security is evidence of this shift. I believe that our current model of application security no longer works.
Application security is developer security
As stated above, logically, application security was part of security, meaning that application security managers and engineers handled it. These are not developers but dedicated security professionals who scanned and audited the code. It is likely dawning on executives that this is an operational role that doesn’t scale well as releases become more frequent and development becomes more complex, i.e. a company has to hire more application security engineers to keep up with this shift. In addition, application security engineers tend to handle the problems later in the software development lifecycle.
This has resulted in a movement to “shift left,” where application security engineers enable developers to discover and remediate security issues in development where they are “cheaper” to remediate (compared to remediating them in production). This change leads to the next question: “What’s the purpose of application security engineers?” In other words, why can’t developers just discover and remediate security issues and own application security decisions? In some way, this is an interesting paradox. Application security is scaling with developers, but it’s scaling so aggressively that it might make application security less relevant in the future.
This graph shows that developers are increasingly becoming more directly involved in application security, but this shouldn’t come as a surprise as more security work is being done in the earlier part of the development cycle. Moreover, developers have different preferences for tooling compared to security, so they are also more involved in application security solutions. Also, there seems to be increased frustration with security and their processes.
Of course, this graph doesn’t tell the whole story because it’s a snapshot of current concerns. There’s no signal of how this has trended, so it would be interesting to know how this looked when development happened mostly in the waterfall model. It is illuminating, nonetheless, because these concerns tend to be magnified and less tolerated in faster release cycles. That is, people tend to feel more friction when they have less time available and are forced to operate under tighter timelines.
Application security products need to adapt to stay relevant
Current application security products are still marketed to the CISO and application security manager. As shown above, it’s becoming clear that developers will start taking security into their own hands, and they will likely start to be key decision-makers in these solutions. This is because they tend to have more context for prioritization and remediation, especially if they are involved earlier and more frequently. Thus, these products need to adapt to developer preferences.
The problem has always been that there isn’t a budget for developer-marketed tools, and typically, security is the ultimate buyer. I do imagine this will start changing as developers will be asking for more tooling to help workflows they are less familiar with, such as security. From my experience, developers just don’t have the muscle to purchase products like security traditionally does, but I believe this is changing as they become more empowered and learn. This is something that application security should be aware of.
What happens next?
I think the reality of application security is changing. Developers feel frustrated with the way application security is currently and want a more active voice in how application security is done. I can imagine developers taking more ownership of application security and making dedicated application security engineers less relevant. It’s also possible that application security will slowly start to move under engineering at companies as it moves the feedback loop closer to the actual “consumer.” With that shift, application security engineers will likely have software development backgrounds, and we are starting to see this profile change at several companies.
It’ll be interesting to see what evolves over the next decade, but I can imagine the application security role going away and just having dedicated software engineers who work on security and are responsible for application security. As many know, I’m a big fan of security being part of engineering at tech-focused companies, and application security seems like an obvious place to start this move. Overall, I believe this is positive for the security and engineering community because it will lead to more secure software.