Frankly Speaking 6/22/22 - AppSec is dead!
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.
Thanks for all the new signups, especially those who signed up for the paid version of Frankly Speaking! This week is the first week of premium content, so if you want to view the whole post, please subscribe.
LET’S BE FRANK
Ok, the title of the newsletter is a bit dramatic, but it’s hard to capture so many nuances in a Substack email header.
To be clear, I’m not saying that application security (appsec) is no longer relevant. Rather, I believe appsec as we know it is changing, so the current market will evolve and/or slowly shrink. The main assumption here is that most companies will trend toward an agile-style of application development and a cloud-based deployment model for that application. This isn’t so hard to believe because engineering resources are limited and having them spent on maintaining physical infrastructure is not strategic for a large majority of software-focused companies. With the cloud and SaaS, it is easier than ever to start and grow a software company!
The evolution and/or death of appsec is part of a bigger security paradigm shift created by organizational shifts to the cloud. I’ve written in the past that datacenter security is dead, and why smart VCs, i.e. ones that want to make money, shouldn’t invest in network security.
In this post, I’ll discuss a few topics:
How the cloud is changing appsec and why appsec as a role is confusing but evolving
Why current appsec tools are outdated and the “next-gen” tools won’t solve the problem
Finally, where I believe appsec market is going
For those VCs who don’t want to sign up for the paid subscription for whatever reason, the conclusion is that you shouldn’t invest in appsec companies!
Why appsec is changing?
The shift in appsec draws a lot of parallels to the emergence of the security engineer, which I wrote about in my last newsletter. It’s really about an organization’s shift to the cloud. I don’t want to talk about this more because plenty of my previous newsletters explain why this is happening and its implications, so I encourage you to read those.
The cloud has given companies access to essentially unlimited computing power and storage. This shift has allowed companies to no longer be limited by their infrastructure. As a result, they can deploy and update applications at a much more rapid pace and deliver features to their customers much quicker, which has created value for the subscription model.
Gone are the days of sending a CD and hopelessly trying to send updates and battling license avoidance. Today, we live in a world of SaaS and regularly updated desktop apps downloaded directly from the internet.
How does this change appsec tools?
Given the value proposition of more frequent deployments for a company, most engineering teams have shifted to an agile method of development away from the somewhat clunky and outdated waterfall model. With such fast deployments, the old models and appsec tools that scan applications regularly no longer work.
Static application security testing (SAST) tools are too slow. Sometimes, multiple deployments need to happen in a day, and engineering teams simply can’t wait for these tools to finish and report out. They are killing engineering velocity.
Let’s take a step back. What are the main purposes of SAST tools? There are two main purposes in my mind. First, they are meant to find vulnerabilities in code. Second, in a world where software engineers use more open source code, they check whether open source licenses on libraries are valid.
Unfortunately, in the agile and SaaS world, this has to be done fast. Newer tools like Snyk solve some of these issues by plugging into the CI/CD process and providing feedback directly in the pull request. That way, on each code change, developers don’t have to coordinate with security to get a scan and see the results. Snyk is very developer-friendly in this way, and that’s why it has seen widespread adoption. It has made it easier for developers to do security and allowed developers to keep their engineering velocity.
Similarly, it seems that DAST is more important than ever because SAST needs to be faster and as a result, might miss some vulnerabilities, especially with code bases growing so rapidly. Moreover, with complex code bases, it’s possible to miss code executions that only appear at runtime. With that said, it seems like there will be a consolidation of SAST tools, i.e. there won’t be a tool for just dependency checking or just for binaries. But, the problem here is that like other appsec tools, DASTs are noisy because code scanning is hard. There have been years of research done, but it comes down to a tradeoff of scanning speed and accuracy.
There are a couple of other issues. First, if the appsec engineer is just scanning and maintaining the tool, where is his/her value? Before, where IT owned infrastructure, they would communicate with IT to fix problems in software that was deployed on premises. Now, they are just surfacing vulnerabilities found in these tools to development to fix with little to no context. Especially, with a tool like Snyk, this obviates the role of the appsec engineer even more, in the context of tools. Snyk puts the scan results automatically in the pull request for the developer to triage and handle. Similarly, it can create JIRA tickets for high-risk vulnerabilities. Thus, the appsec engineer’s role with appsec tooling is substantially diminished, but it does make the process more efficient. In the eyes of agile programming, this is a good tradeoff. We substantially increase engineering velocity for a little added risk (not having dedicated people to directly manage the tool and outputs).
So, does this make the appsec engineer position irrelevant? Well, kind of. It evolves the appsec engineer role. It looks a lot more like a security engineer, i.e. a software engineer that does security. They are no longer involved in tooling, but their role will be closer to product security.
Application security will be mostly product security
Why will this happen? Well, it is already happening. If you look at the OWASP Top 10, which many security organizations use as a guideline for their application security priorities. If you look closely, most of these problems cannot be easily caught with tools, so even having “next-gen cloud-based” appsec tools (whatever that means) won’t solve these problems. For example, maybe a tool will catch a cryptographic failure, but usually, those are subtle. Definitely, it would be very difficult to catch insecure designs and authentication problems with tools. As a result, an organization needs a combination of software engineering and security skills.
Given the criticality of authentication, I can see more application security teams focusing on that in the future. It is the first experience that a customer/user sees, and all other security features/controls don’t really matter if a malicious user can bypass the authentication layer and behave like a legitimate user.
Other than application security teams being filled with security engineers, I see security engineers on this team or adjacent teams managing more of the security tools that impact development, e.g. SAST, CSPM, etc. Given these tools are inherently noisy, they have more context to triage these issues to the right teams and decide which issues to ignore.
What does this mean for the appsec market?
The current market and tools will still be around for compliance reasons. Customers and users still want companies to have these, but outside of compliance, there won’t be much value. So, it’s a race to the bottom. Companies will buy products just to have them, not because they create any value. I know I said in the past that I’ve talked about compliance driving value. Well… there are some nuances. I believe that compliance can help create markets and create value, but it ultimately cannot be the only value proposition. This is a prime example of that.
But, what about the vulnerabilities! Yes, there are vulnerabilities, and current app sec tools surface them. However, like I said above, these tools are so noisy, and many vulnerabilities aren’t actually that risky. Even if there are risky ones, it’s likely they get lost in the noise. Moreover, if you configure the tool to be less noisy, you might even miss a critical vulnerability!
When looking at the biggest risks in an application, they are really the ones that can’t be found by tools like I said above. They are the product security-related risks like authentication bugs and insecure systems design.
Since application security tools will mainly be used for compliance, the market for that won’t grow substantially. Competitive pressures will drive spending down and reduce the size of the market. We are already starting to see consolidation as companies as Synopsys has bought WhiteHat, Coverity, Tinfoil Security, Black Duck, etc.
This doesn’t seem like a promising market for VCs unless there’s a next-gen Snyk that can try to capture a large portion of it with a new innovative approach, or a new software infrastructure and/or application paradigm that drives a need for a new type of tool.
However, this is another example of where security engineers (and software engineers) are playing a bigger role in the future of security.
Open Questions
There are still some open questions here:
Any imminent changes that will create the need for a next-gen appsec tool? DevOps drove the need for a tool like Snyk, but what’s next?
Will the market shrink even more and at a faster pace, as customers/users no longer require companies to have appsec tools because they realize they aren’t providing value and many times, acting as shelfware?
Other than consolidation like Synopsys and Snyk, are there any other ways for appsec tools to drive value?
Are there other dev tools that appsec will start using to help with product security? For example, will there be additional use cases of tools like Retool that will create more value for product security?
As a follow-up, what tools can be created for product security?