The Evolution of Application Security in a Cloud-Native World: Q&A with Chris Wysopal

As technology explodes, so do the threats. Point solutions emerge as security players innovate in order to keep up. This creates the need for consolidation, as the fragmented solutions become too much to manage. We’re entering a consolidation phase now, the process of distilling, refining, and letting the cream rise to the top. We sat down with cybersecurity veteran and vigilante, Chris Wysopal, to get his perspective on emerging trends in cloud-native security. Let’s dive into the conversation.

Natalie Tischler: Chris, it’s great to chat with you. I’m inspired by your story and how everything you were doing with L0pht over two decades ago is still what you’re doing today: creating a world where software is built securely from the start with clean code. But now we have the cloud. So tell me, what’s your take on the evolution of application security in a cloud-native world?

Chris Wysopal: What we’re seeing with the move to the cloud today mimics the AppSec trends of 15 years ago. People would find security problems in production and then introduce dynamic tools like Burp to address those problems at runtime. But controls began shifting earlier in the development lifecycle to reduce risk, lower fixed costs, and improve remediation speed.

Of course, then you wound up with different types of scanning, which got hard to manage individually. So we started combining functionality into a single platform for more efficiency and visibility.

This is the case today as the world becomes cloud native. Point security solutions have popped up, pointed at specific parts of cloud-native architectures—APIs, containers, infrastructure-as-code—and many of them focus on finding problems at runtime.

One emerging trend we’re seeing—cloud-native application protection platforms, or CNAPP—looks at what practitioners might want ten years from now, as DevOps teams really coalesce around cloud-native architectures. CNAPP takes a platform approach, recognizing that managing all these different tools is hard, and points out that Dev and Ops are all writing code these days. Everything is code.

The problem is, CNAPP leverages that word, “Protection”, as a key word… but what about prevention or remediation? Or even detection?

‘Protection’ is too late. It’s antiquated. I like all the other letters except “Protection” because I think prevention is the is the most important thing we can do. Any way you can prevent attacks, remove attack surface, or make things more resilient, those things are all better than hoping you can detect an attack and protect yourself from it. 

The protection viewpoint is valuable when thinking about zero-day exploits, and they do get a lot of press. But as our own State of Software Security report points out year after year, organizations struggle with basic secure coding. And if you think about protection technologies, we’ve all seen how antivirus and firewalls have helped us through the years… They haven’t. Well, they’re only one small piece of the puzzle. 

If everything is code, and the best time to scan (and remediate) code is before it’s in production, I would like to caution against over-indexing on the word “Protection”. A more suitable term could be something like Cloud Native Application Security Platform. Or Cloud Native Application Prevention Program to emphasize how important it is to build a secure cloud-native app. The protection part is secondary to prevention and an observable feedback loop from runtime back into design and build. Maybe CNAPOP for Cloud Native Application Prevention & Observability Program is even better. Ha!

NT: Is this just semantics? Could you explain more? 

CW: To go beyond semantics, let’s look at the core areas of CNAPP functionality: artifact scanning, cloud configuration, and runtime protection capabilities. At its core, this consolidation is something I’m completely for, which is security in context. It’s being able to understand the entire application stack together – app level, container level, and infrastructure level. Given my experience in seeing the value for practitioners in consolidating multiple technologies, I also agree with it being a platform-based approach.

In the past, when everyone was operating their own on-prem data centers, we couldn’t have this kind of visibility. But now that infrastructure is being built in the cloud, we can look at it all in a meaningful way. If everything is code running through cloud-native CI/CD pipelines and into cloud-native architectures, you can look at that code together – and, more importantly, make risk-driven tradeoffs at different levels of the application stack. 

There are some logical synergies between artifacts scanned during development and at runtime: A significant proportion of Veracode customers using dynamic analysis scan throughout the SDLC, including regular production scans against their applications and APIs. We’re seeing an increase in customers using software composition analysis regularly at runtime as well. When it comes to cloud-native architectures like containers and infrastructure-as-code or IaC, it makes total sense to ingest artifacts during design and build to scan continuously through those cycles and even after they reach production.

Similarly, some of the functionality bucketed into the cloud configuration area, like posture management for containers and IaC also has logical dovetails with artifact scanning. If you find a flaw in how a configuration has been built—regardless of when or where it’s found—you want to help to remediate it as quickly as possible. Veracode is investing heavily in fixing flaws faster, like the auto-remediation capabilities we acquired from Jaroona. This is the same approach we take toward offering auto-pull requests for open-source library vulnerability remediation today.

We call this intelligent remediation. It’s more like getting a solution presented to you for evaluation, instead of automatically making the fix. As a developer, I have to express reservations about some process automatically making changes to my code or configurations, especially if those changes are happening in production and bypassing governance processes like ticketing systems for traceability. This introduces more risk than it solves. I would rather see technology get better at suggesting fixes in line with my organization’s own policy.

This brings me to more of the runtime protection capabilities that CNAPP forecasts in its consolidation, like application monitoring, cloud workload protection, and network segmentation. While I think protection technology is becoming more enmeshed, I see this space becoming more of the domain of the hyperscalers—the large cloud providers—than meshing well with the other functionality we’ve been discussing. These are very different domains requiring different skills and expertise. I see the micro-segmentation required by security approaches like Zero Trust as becoming more complex, not less.

That said, if we want to find security nirvana, the solution must solve the problem of two worlds: what’s happening at build time and what’s happening in production. I believe in the power of immutable infrastructure, but you can’t always push a new infrastructure version without considering a feedback loop back to design. It’s the definition of insanity, doing the same thing over and over again and expecting different results. Don’t just make changes in production – consider why things are breaking. This means you need observability that is actionable by the developers.

NT: What concerns you about this view of the market?

CW: Well, the full list of capabilities include technology that isn’t really about writing code, and that’s really where I’m focused. I mean, yeah, it would be great if every single facet of securing and protecting an application could be accessed from a single platform. I believe in the vision of consolidation, but there are some serious operational hurdles to overcome.

I love technology, but it comes after people and process. Today’s world asks a lot of developers: You have to keep up with constantly shifting languages and frameworks, look for innovative ways to solve problems, understand and write code across an entire application stack, oh, and do it all securely, which is something you probably didn’t even learn in school, by the way. 

I first testified in front of the U.S. Congress about the need to secure code back in 1998. More than 20 years later, security still isn’t enough of a priority to be required by computer science programs. What I’m trying to say is that we can’t expect to keep dropping more and more responsibilities onto peoples’ shoulders and expecting them to be successful. Let alone find people skilled enough to hire for the job!

From a process perspective, building the kitchen sink into a platform is—as they say—a small matter of programming, but if no one can run it or buy it or integrate it, then what’s the point? Who’s the purchaser? When you’re talking about functionality that crosses Engineering, Security, Operations, Compliance, and IT…who has the authority and the budget? The surveys and market analyses we’ve seen show increased fragmentation of the purchasers of security tools, which is the opposite of what would be needed here.

I think what concerns me most is that a race to bolt together mismatched components will result in a terrible experience for the people out there who are just trying to build good, secure apps. We’re going to be watching this and helping people get there – but 10 years is even an optimistic timeline for the degree of consolidation CNAPP requires.

NT: Are there other ways that you see this space evolving that maybe we haven’t talked about?

CW: Oh, absolutely. I spend a lot of time working with the NTIA multistakeholder process for defining the standards for what’s known as a software bill of materials, or SBOM. Given the fact that it’s the closest we’ve ever come to having a machine-readable standard that’s like an ingredients list for your software—and the number of requirements to produce them for all U.S. federal suppliers—this has the capacity to shake up our market.

Then there’s hacks like SolarWinds that have created more visibility into the security of our supply chain, and SBOMs are seen as one way to create that visibility. But when you start talking “machine-readable format,” there are just a whole lot more use cases that I am already starting to see crop up that go beyond just the lifecycle management capabilities. 

Artifacts like SBOMs and a companion artifact known as a VEX, or vulnerability exploitability exchange, offer some promise for communication between development and operations sides of the house. There’s a lot of exciting potential here.

I don’t think I mentioned it earlier, but these types of artifacts make it easier for security technology companies to partner with one another, which is a way to measure the appetite for what types of functionalities people really want to see together. I think this is a very good thing. We could do with a lot more cooperation and integration. I mean, how come my endpoint protection and my VPN software get into a slap-fight every time I boot up my laptop? 

Just thinking about the consumer’s point of view, if Veracode were to acquire all the companies we’ve partnered with on our platform, that egregious cost would be passed to each customer, regardless of whether they need that capability. 

NT: So, what’s your vision of how this space will evolve over the next 10 years? What does security nirvana look like in a cloud-native world? 

CW: Let's start from the ground up and say, how should we do this? Almost everything that's happening in DevOps is developer led. But that doesn’t mean we need a development tool for security: We need a security tool for developers. At the end of the day—whether the management of this gets upleveled to greater automation or a security operations team, whether developers are writing the code themselves or describing the code that gets written—this is still a security problem that gets solved by developers.

We must be asking: What makes security easy for a developer to manage? What makes it easy for them to have a high quality, secure application? I’m biased, of course. But I think that cloud-native application security should grow out of development processes. It should grow out of the developer tool chain and the developer network. And if anything's living in production, it should be feeding back into development. It should be telling developers what's going on with their application.

Security nirvana is security in context. Which looks like this: First off, threat modeling practices need to get more iterative and automated across the SDLC, which creates guidelines and stops problems before they ever start. We can’t just let threat modeling be a one-time or runtime event. A scan is run—probably different types of scans are run at once, actually--and then all of the vulnerabilities are presented in the context of the entire application stack, where the team has the ability to manage risk tradeoffs at all levels. Not changing code in production, pissing off developers, and so on.

Our job isn’t to piecemeal out information by scan or provide stale and rigid learning curriculums. Our job is to provide a holistic picture of vulnerabilities across the entire application stack. Then from that holistic snapshot we sort and rank the vulnerabilities and give in-context recommendations for fixes and mitigations. The last piece is the relevant additional learning opportunities that tie back to real world challenges a team is facing.

I can’t stress enough that the future is developers writing secure code. There’s a huge education piece here that is sorely missed in this industry. That’s exactly why we have invested in Security Labs.

The only thing that developers are really monitoring in production today is performance. They’re monitoring performance and aren't necessarily monitoring for the behavior that might be wrong – that stuff is pretty sophisticated. Veracode is focusing on not just education but also technology that gives us a good connection to monitoring what’s gone wrong in production so it can be brought back to the developer. 

In today’s world, people are fixing things in production all the time. They're changing configuration. They're patching things. They're changing permissions in the database. They might even be changing code. And given the explosion of the attack surface, that’s a really risky world to live in.

In the perfect DevOps world, developers are making all the changes. Developers are saying, “We're going to use this container image now. We're going to use this AMI. Now we’re going to change this code. We're going to update this configuration.” Anything that’s going to get remediated must eventually come back to development.

It all has to come back to the developers. Veracode is interested in making observability actionable for the developer. And also giving developers tools like Security Labs so they can hone their craft.

NT: That all sounds very ideal for a perfect world. Vision is one thing, but I’m sure you’ll agree with me that solid execution is something else entirely. I’d like to chat about what you’re doing to enable developers today in the real world.

CW: Right, execution’s a different story. Well, what the real world is dealing with is radically accelerated digital transformation. It’s a world of rapid adoption of cloud-native tech, new kinds of architecture, and other bleeding edge software development approaches. Meanwhile workloads are getting smaller, and the cadence of delivery is increasing. So this is the real world we’re building security strategies and systems for. 

We’re focusing on a fully integrated platform that’s open enough to integrate other analysis plugins so we can keep up as things shift. It’s the single pane of glass approach with continuous orchestration of things like inline remediation, policy definition, runtime intelligence, and prioritization capabilities. We want to be pervasive, not invasive. Which is what runtime-focused strategies struggle with because changing code in production is as invasive as it gets.

Then there’s developer experience element that enables so much of this adoption. Our own experience in breaking apart our monolithic platform into cloud-native services, using Veracode technology every step of the way, made it clear that we’ve missed the mark on parts of the developer experience. Which is a line that our competitors try to use, to be honest. But the competition is inspiring because we know we can fix the UX part - and still serve our best-in-class tools and technology with an experience that matches the quality of the functionality. First to market is less important than best to market.

We’re only going to secure the world’s software by giving developers high quality tools to write secure code. We’re improving pieces like onboarding, integrations, intelligent remediation and mitigation, containersecurity, and other coverage for cloud-native development. And we are working on ways people can see for themselves more easily. We already have a free Community Edition of Security Labs, and we are looking at furthering our free experiences of Veracode’s platform.

Look, securing applications is a journey—for you, for me, for everyone out there. When it comes to execution, Veracode has been helping organizations build and mature their application security programs for close to two decades. We meet you where you are on your journey. 

Legacy apps in diverse languages? We’ve got you. Going cloud-native? We secure APIs, serverless functions, with exciting new developer-first capabilities that we’ll be announcing soon. Got a mixture of apps and environments? You’ll be hard-pressed to find so many aspects of software security combined into one platform, along with the knowledgeable resources that help you put the technology to work for you.

When it comes to the evolution of application security today and tomorrow, we’re invested in creating the DevOps nirvana I’ve been talking about.

NT: Clearly! Thanks for your time, Chris.

To learn more about achieving DevOps nirvana, click here to speak with a Veracode expert about integrating application security where and when it makes sense.