Let’s talk about the state of AppSec for a minute. We’ve come a long way since the days when security was this cursory ‘feature’ tacked on to a fully developed application just to tick some boxes. It’s not easy being the people who have to tell the other people who are actually building amazing and important things why they’re doing it wrong. AppSec is all about striking a balance between secure operation and time constraints: you’ve got to make sure your apps don’t make it easy to break into them, but you also need to release them on time.
In the past decade, we’ve actually gotten pretty good at doing that. Security has gone from being a last priority item to an integral part of the development process, literally putting the ‘Sec’ in the middle of DevOps. So much so that us marketing folks gave up on trying to rank for DevSecOps as a keyword a long time ago.
The journey of AppSec so far
The last ten or so years have been a pretty exciting time for security of all kinds, including cybersecurity and more recently, cloud security. It was only around 2015-2016 that AppSec automation actually started gaining momentum, and it really helped bring security closer to DevOps. People started seeing real value in taking security tools out of their individual silos and bringing them together.
Instead of compiling separate scan results for each new tool they used, it helped to aggregate the hundreds or even thousands of scan results together. When you look at them from the broader context of securing the application as a whole, instead of remediating individual vulnerabilities one by one, it totally changed the pace at which AppSec could be conducted. Not all vulnerabilities are created equal, and a major, app-breaking bug in your application might just be a minor vulnerability in someone else’s.
It also meant that security and development teams had to work more closely together in order to get the results they need. And as any team leader or project manager will tell you, communication and harmony between two teams or groups could make or break your whole development process.
But there’s still a LOT left to do. AppSec has matured from mere infancy to a somewhat self-sustaining adolescent now. But it’s still a far cry from adulthood. There’s plenty of things we can start doing right now to help it get there, but the journey won’t be without its points of friction. Let’s see what some of those things look like.
Every vulnerability has a story
If there’s one thing that all product engineers, developers and security professionals need to do, it’s to stop looking at vulnerabilities as a statistic. Obviously, no application is perfectly bug-free. But vulnerabilities don’t just form out of thin air, they’re there for a reason. Blindly trying to fix bugs in your apps is like treating the symptoms instead of the cause. You need to understand why the vulnerability is there in the first place, and what that means for your application. Vulnerability metadata can be far more useful than you think.
For example, when you run a vulnerability scan, you might see that the design and architecture of your app contribute to some 100 vulnerabilities, while only 50 come from deployment. These aren’t arbitrary numbers, are they? There’s a clear pattern here. If more bugs are coming out of design, maybe you should start threat modelling your app instead of grilling your developers to write more secure code.
Obviously it’s not always this clear-cut in the real world, and I’m oversimplifying to an extent, but my point still remains. Figuring out where your vulnerabilities are cropping up, and why, will help you a lot more in the long run than simply trying to fix bugs without a premeditated strategy involving all you team members.
Treating security vulnerabilities as defects
The biggest problem with security is not seeing the forest for the trees. Too many product engineering teams think of their applications as a ship, and vulnerabilities as leaks in the body that need to be plugged before the whole thing sinks.
In reality, the app is more like a human body, where the security is the immune system. Sure, it can’t be perfect, and some infections can compromise it quite badly, but by strengthening the body as a whole, the immune system is kept robust and active. You can’t selectively fortify one part of the body and call it healthy, just as much as you can’t remove just one class of vulnerability and consider your app secure.
In the past decade, AppSec practitioners have been relying more and more on automating tools to analyse their apps. Each of these tools are good at their specific niche: source code analysis, dynamic testing, etc. But like I said earlier, you can’t look at vulnerabilities in a vacuum. If a new feature is added to your app, you might see a major change in your vulnerabilities. That’s because vulnerabilities are not set in stone, and our security processes need to acknowledge that.
So how do we go about treating security vulnerabilities as defects in your app as a whole? To begin with, we need to look at integration points more seriously. Rather than operating security tools in silos, we need to get them to work in an interoperable fashion with all the other tools and platforms.
By increasing the level of interactivity and interdependence of all the various tools you use, you’re painting a much more accurate picture of how your application functions in a real-world scenario, rather than the controlled environment you’re testing it in.
At Amazon, before the engineering teams begin working on a new feature, they ask themselves two questions:
Does this feature help my customers get products for a better price on Amazon than anywhere else?
Can this feature help us get products to customers faster than they could from somewhere else?
Cost and speed of delivery are Amazon’s two biggest priorities, and their development process reflects that. In AppSec, the two questions you should be asking yourselves are:
Does this help me find bugs early?
Does this help me fix bugs early?
By prioritising how early and quickly you find bugs (security team) and fix them (dev team), you can create a balance that brings both teams together in a much more cohesive fashion.
Security engineers need to understand code
It’s kind of become a theme in AppSec to expect developers to learn about security. After all, they’re the ones developing software, writing the code, deploying apps and fixing bugs that the security engineers find. But putting the onus of building a secure application purely on the developer is turning a blind eye to half the problem.
Product engineers are never going to have the same level of expertise in security as an AppSec professional. You need to start overlapping some of the security responsibilities across both your teams, and get them to start working in conjunction rather than independently of each other.
What does that mean for your security team? Well, it’s becoming increasingly critical for AppSec engineers to learn and understand code. In the last few years, there’s been a shift from treating security as a separate entity that needs to be retrofitted into your apps, to something that informs the very design and function of the application. And how can security keep up with the rapid pace of development? It’s simple: automation.
Security engineers that know how to code can integrate with tools, write security exploit scripts, automation scripts and lots more. By meeting developers halfway on this, they’d actually be streamlining the process of generating security reports on a regular, scheduled basis.
Developers and security engineers: A love-hate relationship
Let’s be honest, developers and AppSec practitioners don’t exactly have the most healthy working relationship. Whether it’s security teams complaining about the developers not writing secure enough code, or developers fuming over obtuse and poorly translated security reports, there’s a lot of very real tension and conflict between the two sides. There’s also a distinct lack of empathy across teams, where one group doesn’t really understand the limitations of the other, and set the expectations unfairly high.
But the more each team is made to share each other’s responsibilities to an extent, the more they’ll see that they’re all working towards the same end goal: building an application that runs smoothly and securely. When security engineers understand code, they’re more easily able to speak the same language as the developers, and realise that fixing vulnerabilities doesn’t just magically happen when you hand them a security report. Conversely, developers that take the effort to understand security will be able to read those reports more easily and find creative ways of approaching a stubborn security flaw.
Basically, communication. If there’s one thing I’m looking forward to seeing happen in this next decade, it’s this. By being a part of each other’s ’tribes’, security and development teams could bridge the partisan lines that divide them, and learn to be accepting of each other’s workflow and culture in a way that they both benefit equally.