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.
Keep reading with a 7-day free trial
Subscribe to Frankly Speaking to keep reading this post and get 7 days of free access to the full post archives.