The Importance of Adopting Modern AppSec Practices
Security is an increasingly critical aspect of application development. As the volume of applications rapidly expands, so does the volume of source code, components, and dependencies used to create them. With them comes a growth in the potential attack surface and an escalation in the variety of threats to your application security.
Mend.io CEO Rami Sass, Jeff Martin, VP of product management, and CMO Arabella Hallawell recently sat down for a panel discussion on AppSec today to discuss the growing significance of AppSec, why traditional approaches fall short, and how to create a modern, effective AppSec program.
Why is AppSec such a hot topic?
Arabella Hallawell: The threat landscape has morphed over the past two decades. Threats have leaped to the application layers. Forrester did a report recently, which showed that software exploits within code and supply chain attacks are the number one source for attacks and breaches.
A decade ago, or even less, the major concerns tended to be about web apps and network security and then the desktop endpoint. It’s no longer just about phishing attacks and even standard web exploits, so I think that’s why it’s such a hot topic.
A case of customer demand . . .
Jeff Martin: I’ll take the product viewpoint to this. You respond to what your customers want. The biggest reason companies have focused so much on cybersecurity, especially application security, is quite simply the people who buy their applications are demanding it. And we’re all in the business of meeting our customer’s demands. So, when they demand a secure application, we have to provide that and we have to prove that. And that’s one of the bigger drivers.
. . . And the fear of what happens when security is breached
Rami Sass: Security breaches can cause reputational damage, the loss of data and control of systems, privacy breaches, and theft of intellectual property. Sometimes security breaches can result in the direct theft of money, Bitcoin, or whatever currency is being handled by those systems. And many times, you’ll see people steal data and then hold it for ransom. So, there’s a lot of direct damage that can be done on top of reputational damage.
An imperative to be preventive, backed by governments
JM: And I’ll add that governments and customers are holding companies more accountable for the data that they protect. And the main way you protect your data is through the applications that use them. So, your applications have to be secure or your data is not secure.
RS: The whole notion of application security stems from being preventive and not waiting to react. Because if something has gone wrong, then the price is already too high. Securing an application while it’s being developed prevents these problems from happening and not just mitigating them when they do.
JM: Absolutely. Application security done correctly is prevention by design, not insurance. It doesn’t just mitigate errors or issues. It stops them from happening. It’s not reactive and it’s not by accident.
The problem with compliance-led AppSec
AH: If you look at a lot of application security to date, there has been a lot of box-checking. Auditors say companies have to do it and it’s compliance led. And I think that’s why many organizations haven’t really focused on how to build a modern AppSec program. One issue has been the way that application security tooling has evolved. It has often been very manual and very time-consuming. I think many organizations, even mature ones, struggle with how to build an effective AppSec program, particularly when they rely on their development engineering teams to scan all their code and deal with it proactively.
JM: Modernization is a problem, especially with big companies, and AppSec tends to lag behind other areas. We do a lot of education about just what’s possible now because these companies haven’t really modernized. One of the things forcing them to do so is the move to the cloud and more distributed ways of developing applications. Also, big customers like the US federal government require vendors to have a minimum level of AppSec. So, organizations are being forced to modernize and that can be a painful process in large companies.
The challenge of cultural change
RS: This is a major challenge. If you look back ten or maybe even five years, security people and engineering people wouldn’t know about each other, nor care about what the other one’s doing. Whereas today, security people who want to address the issue of application security are very much reliant on the cooperation of the engineering department and they have to learn to work together to a very intimate degree. And I think this forces things to change even more than tooling or practices or policies. It requires people to work together to address this joint problem or reach a joint goal.
Complexity of modern software
RS: Most developers’ time isn’t devoted to typing code. It’s focused on finding the right components and integrating them in a way that makes sense, is streamlined, performs well, and does the job that the application has been designed for. And it’s not just open source. It also has to do with the way modern software is built, with microservices and images that are sometimes even inner-sourced. However, the developer that puts the application together, doesn’t necessarily know what’s in that image regardless of where you got it from. It could be from someone inside your company. Different components have varying levels of quality, governance, control, and security policy during the time of their inception. So, when you compose them, it becomes very difficult to standardize anything and especially at a security level, which I think is the main driver of everything we’re seeing around software bills of materials (SBOM) and supply chain. All these initiatives are trying to address the complexity of building modern software.
Preventive AppSec: dependency management
JM: Applications are like recipes. You have a bunch of ingredients. You prepare them. You figure out how to integrate them at the right time, but you pay less attention to how fresh the food is, and you assume it’s safe. However, if you don’t look at the ingredients and make sure they’re good, they’ll make you sick. Similarly, if you don’t check whether your application includes malicious content, then your software could be contaminated. Without checking, you’re just hoping that your ingredients are good. One of the best ways to make sure you serve healthy food is to use fresh food. A lot of people let their dependencies and their software age. No longer. You don’t want a five-year-old dependency in your application any more than you want five-year-old meat in your stew. So that’s my version of fear mongering: do AppSec correctly or you’ll get poisoned!
Just like a recipe’s ingredients, components are interdependent, and they can have knock-on effects on each other. One package in a Python element of your application might be updated in a little piece of code that’s needed by a release, but it may have serious implications if it has a vulnerability or any security issues. It’s really easy for the developer to just update the package and test it, but that’s just one of thousands of known elements in their stack. There are also those they don’t know about. This makes the issue of interdependence really complex, and that’s in part what an SBOM is trying to address. But it can’t be a manual process. It has to be continuous, as the software evolves.
Getting the balance right
RS: But it’s not all bad news because there is no direct correlation between the level of risk and the amount of effort required to fix the problem. Sometimes your worst nightmare can be very easily fixed within two minutes of upgrading a version or doing some minor tweaks to some configuration. You can actually use that to your advantage. If you do have a good process and you do use automation, then you can leverage that in your triaging. You can make sure you take into account the effort required to fix problems when you prioritize them so that you make smart investments.
JM: I think people don’t realize how far tooling has come in that it can do things like detect your full SBOM for you. It can identify risks and tell you if a risk is easy to mitigate, and how to do it. And I don’t think the processes have caught up to where the tooling is. So, the good news from my point of view is that not only is all of this automatable, but the tools to do it already exist. You’ve just got to use them.
