Application security as we know it today is broken.
You commit your code and push features into production, only to get a high priority Jira ticket from security months later with little context. At this point, a security bug has been in production for months and you are pulled into an inefficient fix process.
There is a better way.
tl;dr
- Modern AppSec is Broken. Agile, Cloud, DevOps, CI/CD, and open source have changed everything for engineers, but security processes struggle to keep up.
- AppSec’s Future is in Engineering Teams. Traditional IT Operations was replaced by DevOps; shouldn’t engineering own the security of the code they write?
- A New Breed of Security Tools are Coming. We are part of a small but powerful group of security tools that are built for the developers who do the actual fixing of security bugs.
Application Security is Broken
Applications are being pushed into the world faster than ever before. Cloud deployments, DevOps teams, and CI/CD have enabled engineering teams to produce high quality software with incredible efficiency. As these applications are pushed to production, often multiple times per week or day, the current security model can’t keep up.
Below are some of the ways that AppSec is no longer working for modern software teams:
- Doesn’t Match Modern Workflows. Development has shifted to continuous delivery, with endless tools to support you in your work. You deploy software quickly and count on test suites to catch bugs. Your application security tools, however, are built for a waterfall era and exist in isolation from the rest of your workflow.
- Not Built for Automation. Security bug testing should be automated throughout the delivery pipeline, starting as close to local dev as possible. Solutions that center on testing once an app hits production just don’t cut it in this day and age.
- Finding > Fixing. Existing application security tools (and, in some cases, teams) engage in a contest of finding the most things and you get an ever increasing backlog. Fixing easily exploitable, easily fixed bugs should be prioritized over finding the most obscure vulnerability.
- Built for InfoSec. It only takes a few minutes on the RSA trade show floor to know that the security products of old are built for the suit-wearing Fortune 500 CISOs. Built for Developers is a marketing tagline, not a product reality. Jump into any of the market leading security tools and it is quickly apparent that they are not, in fact, built for developers.
- Training > Tooling. Security teams invest time and effort training developers on how to write secure code. While a noble pursuit, the reality is that you are pushed toward feature delivery and don’t retain enough of their secure coding workshops. Good tooling will always win out over another training day.
Engineers Will Own the AppSec of the Future
The tide is beginning to shift, with engineers taking hold of the security of their applications. Modern engineering teams know that to ship secure apps, they need to own it themselves. We are in the early days of that shift, with a day soon on the horizon where inefficient InfoSec models for application security will become a relic of the past.
As we talk to the developers who are on the cutting edge of this shift, we are seeing the following trends:
- Finding Security Bugs is Shifting Left. As with any bug, it is best to find and fix earlier in the development process. Finding a bug in local dev and hammering away on a quick fix is easy. When a bug breaks a build or is found in production, that is a different story. The best engineering teams are adding application security checks at commit and merge and equipping their developers with the tools to troubleshoot quickly when a bug is found.
- Triage and Fix Lives with Those Best Equipped. If you wrote the code, you are typically the best equipped to make a call on the security risk of a particular bug and to instrument a fix. Even better is when the fix is so simple that it erases the cognitive load of defining the risk, but the bug can be found and fixed while still in local dev.
- Fixing While in Context Drives Speed. No more getting alerted on security bugs for code you wrote months ago. Fixing a bug while you have the context of the part of the code base you are working on drives simplicity and efficiency.
- Security == Quality, and Engineering knows Quality. Your engineering team knows how to ship high quality applications with speed and efficiency. In the same way that teams would not push UI bugs into production, security bugs can be fixed before the latest release goes live. Secure code is quality code.
The New Breed of Security Tooling
The application security shift has already begun. There has been incredible progress on what makes a best-in-class engineering program over the past two decades. Engineers own the end to end building, delivery, operation, and quality of their applications, and the time has arrived for you to own the security as well.
This shift, however, requires a new breed of security tooling. The tools that aim to serve the CISO first, to the detriment of engineers, will no longer cut it. The products that carry outrageous price tags but have not kept up with the shift in how software is created and delivered will have to be phased out. Here at StackHawk, we say, “This is not security for security people.” As long as application security tools are built for InfoSec teams, they will lack the features that are needed to truly serve you, the modern software engineer.
We created StackHawk to simplify the process of building and delivering secure code. We are dead set on creating the best security focused dev tool out there, ensuring that the same people who write the code are equipped to ensure it is secure. We are excited about what we have built already and we are just getting started.
Top comments (0)