DevOps Chat: Interactive App Testing, With Synopsys

As the velocity of software creation, testing and deployment increases rapidly, security at the app level is gaining ever more scrutiny. Code vulnerability scanners, automated security test tools and test libraries for containers are just a few of the security testing approaches broadly in use. Many of these approaches fall under a DAST (dynamic application security testing) or SAST (static application security testing.)

Creator of Seeker IAST (Interactive Application Security Testing), Ofer Maor, Director of Solutions Management at Synopsys, joins DevOps Chat. We talk about the value of IAST, maximizing testing automation, integration of testing technologies into the workflow, security testing built into containers, application security testing orchestration and more.

As usual, the streaming audio is immediately below, followed by the transcript of our conversation.

Transcript

Mitch Ashley: Hi, everyone. This is Mitch Ashley with DevOps.com and you’re listening to another DevOps Chat podcast. Today I’m joined by Ofer Maor, Global Director of Solutions Management at Synopsys. Our topic today is IAST, Interactive Application Security Testing, in a DevOps, DevSecOps world. Ofer, welcome to DevOps Chat.

Ofer Maor: Thank you. It’s great to be here.

Ashley: Great to have you on. Would you first start just by introducing yourself, tell us a little bit about you, what you do at Synopsys and maybe briefly what Synopsys does for folks who don’t know them?

Maor: Sure. So I’ve been in the software security world for about 20 years now. I have _____ company and I’ve worked for multiple vendors. At my last company I created IAST, which we’ll come back to in a minute. Today I’m at Synopsys. If you’re not familiar with Synopsys, we’re the largest provider of software security solutions, so anything from static _____ dynamic, IAST, penetration testing, managed services, everything in this space, and we help organizations build better, more secure software.

Ashley: Excellent, excellent. Great company too, Synopsys. A great organization. So, let’s jump into it. So, you were kind of the inventor, the thought leader around IAST. There’s a lot of different frameworks, you know, acronyms for doing penetration testing, application testing, so you obviously came up with a little bit of a different approach. Tell us about IAST, what’s different about it, and maybe what some of the gaps were to why you created it.

Maor: So back in the days I had a penetration testing company called Hacktics. Hack and technics. We did a lot of penetration tests. We also tried to help our customers bring in SaaS and DAST technologies, and some of the things we’d seen was that there were some gaps in the way that customers were consuming DAST and SaaS, especially DAST was very difficult for enterprises to get into their development processes, into their testing processes because DAST doesn’t show you where the problem is in the code and it requires some security expertise that a lot of these organizations didn’t have. And so we wanted to create something new that will help make it better, help make it easier, provide value and be easy for the customers to get into their organizations.

We looked at what we did in penetration testing and really what we saw was the most efficient way for us was to combine the best of both worlds, so look at the code but also look at how it’s running, and that is what IAST is all about. It’s about analyzing code as it’s running as opposed to SaaS which analyzes code statically, or DAST which sees the running application but doesn’t see the code.

Ashley: So a point of clarification when you say when it’s running; is that while it’s in production running or while you’re testing it in a test environment? Is it both? Talk a little bit more about that.

Maor: So you can have either, but I would say it’s better to do testing in testing, so while you’re running in a test environment, but in your testing environment you’re still running your code as you run your test automation or your functionality testing and that’s a great time to also test for your security.

Ashley: Now did you also think of this both as a code scanning problem like the traditional kind where you’re checking code in a CICD process or do you focus more on the interactive run time in this test environment? Is that more of a focus of what IAST is about?

Maor: I think there’s been a transition for us. So when we started IAST it was 2008. DevOps was weak. DevSecOps was a nonexistent experiment back then.

Ashley: That’s a long time ago in the DevOps world, yeah. [Laughs] 

Maor: That’s a long time ago in the DevOps world, indeed. So we created something that could fit people who do test automation but could also fit people who do manual QA because that’s where most of the customers were, and so our product has actually evolved over time from a technological perspective to better adapt to DevOps world. So it was not necessarily just for integration into the code-checking process and so on, but it is becoming that today because we see it’s really mostly adopted in this world.

Ashley: You’re talking a little bit about how things have evolved since that point in time. Obviously we’re in a much different world than when DevOps started with automation and toolchains and much more adoption across the organization. Now we have security people working alongside application people with DevSecOps. How has that changed sort of the problem space of what you are trying to solve? Is it still the same fundamental problem or have you shifted where your focus is and what you’re trying to solve?

Maor: So I think that it’s still the same fundamental problem. It’s how we solve it that’s slightly changed, not what. The fundamental problem is that people write code that has vulnerabilities in it.

Ashley: No, no. Stop right there. Really?

Maor: [Laughs]

Ashley: Okay. Obviously I’m being a smart aleck, but of course, yeah. It’s tough to write secure code and that’s why we need tools like this.

Maor: It is very tough to write secure code. I remember 15-plus years ago when I got in this space all I could think of, oh, let’s just train the developers and they’ll write their code; a very naïve approach. And so what has changed is the way people build and test their software. So when we started Seeker _____ product 10 years ago we had to imagine that most of the people who had run this will not have test automation, they will have to have our own product run all the tests to drive the application, to make the codes run and create all this traffic which was a huge technological challenge, a lot of like what DAST products have to work with.

Whereas today, in most cases, we’re relying on existing test automation, which now exists for most of our customers. So the way people build and test their code has changed but the fundamental problem is still the same.

Ashley: It certainly is a much broader landscape of tools I imagine that you have to integrate with as well, as well as just being automated from the start. Great. Well, let’s talk a little bit about how IAST fits into the DevOps or the DevSecOps world. You talked about when you first kind of got involved in DevOps that wasn’t a thing and now it very much is or maybe we’re still in transition of DevSecOps really fully realizing what it can be, but it’s certainly important and many organizations are collaborating much more closely in that application testing, security testing process. Just a little bit about your view of DevSecOps and how IAST fits into that.

Maor: Well, I personally don’t like the term DevSecOps because I think the security should be inherent in DevOps. Security is part of our let’s call it nonfunctional requirement for everything we build today and it’s part of what DevOps is supposed to take care of, but if using the term DevSecOps helps raise awareness, fine that’s great. But let’s talk why IAST is such a great fit with DevOps or DevSecOps. There are a few aspects of IAST to make it the perfect candidate for testing in a DevOps environment. The first one is that a DevOps environment means you already have test automation in all likelihood, and so the entire challenge is how to make the code run is solved and so you already have a running application in a test environment, so making security testing as an add-on to that is just a no-brainer.

The other thing that makes it a great fit is that there’s continuous testing of incremental development. So in the past you could only test a running application very late in the development stage. So when we started with IAST a lot of people said, “Oh, but that only comes in the integration or testing phase.” This doesn’t exist anymore. That’s a waterfall statement. In a DevOps world we create incremental code changes and test them every hour or every day, and so IAST is easy to integrate into that.

The other side of IAST that makes it perfect is that it’s very actionable in identifying findings that are relevant for the running code, and so it has almost no false/positive, it has very clear clarification on what is the potential impact, and that means that it doesn’t create too much burden for the developers to understand what they need to fix and why. In some other technologies, the overhead on these aspects can take a long time, and when you create code incrementally every hour or every day you don’t have the time to do that.

Ashley: It seems like there’s also a balance too of making sure that what you’re presenting back to the developer, reducing false/positives so you’re not wasting their time chasing things that aren’t relevant to their code or aren’t actually vulnerabilities. How do you manage that balance of wanting to be thorough but also wanting to be as highly relevant as possible to be useful to the developer?

Maor: So one of the things that we do with our technology is what we call active verification. So for every vulnerability that we see in the code we create requests or some simulated requests that tries to exploit that or verify that, and that means that if we see something that looks like a SQL injection, for instance, we’ll actually create a request that tries to modify the structure of the query, and if that request has been successfully executed and we see the query has changed—because again, we are analyzing the code in run time, meaning we see the memory. It’s like a debugger. We see the actual query that’s being generated.

And so if it’s really changed from how it was originally then it’s a 100 percent true finding and that really helps prioritize. We basically call it _____ triaging. We can identify if it’s a real finding, if it’s a false/positive, or maybe it’s not a false/positive but it has no real impact because there are other compensating controls that prevent you from executing.

Ashley: Great. Can you talk a little bit more about some of the testing that’s happening inside of active verification? So what kind of tests that you run? You mentioned looking at SQL injection or SQL _____ modified. What are the other kind of things that you’re testing?

Maor: So pretty much almost every vulnerability that we test for. So let’s say there’s a cross-site scripting, right? Again, I can create a request that actually inserts a script or some JavaScript code and see that it’s really going through the entire process of going into the server, coming back and being rendered by a browser on the receiving end of this. So for everything that we do—so we normally just analyze existing traffic, right? Your test automation. But when we find something that looks vulnerable we will duplicate that request, modify it with some payload or an exploit simulation and then see whether that works. In a lot of cases there could be something that looks like it’s vulnerable but there is some input validation or other compensating control that prevents it from actually being exploited, and then it’s not a real vulnerability.

Ashley: Sure.

Maor: It’s a batch coding practice and we show you that in another view if you want to clean up your code, but for most customers they just want to fix what’s really dangerous.

Ashley: Yeah. Fix it and move on, right?

Maor: Yes.

Ashley: That’s the [laughs] developer’s view of the world ’cause they got things to do. Absolutely. Well, talk a little bit about—I think it was, what, 2015 that you sold Seeker to Synopsys, somewhere around that time period. Why was that a great acquisition for you or to be acquired for you and what’s that allowed you to do, to be part of Synopsys now?

Maor: First of all, Synopsys is a great company. You mentioned that in the beginning. It’s been a really interesting ride. I think, you know, when you’re a small startup you have your own solution and you say, “You know, this solves everything. You don’t need anything else.”

Ashley: [Laughs]

Maor: You will tell customers, “You don’t need SaaS, you don’t need DAST, you don’t need anything. We do everything.” But the reality is software security is a very, very complex problem. There isn’t one solution to fix all and there are different problems that require different solutions or a combination of different solutions, and being part of Synopsys really helped grow Seeker and make it part of a bigger solution. So some customers use Seeker in combination with SaaS and some use it in combination with Software Composition Analysis, and for some customers it’s a better fit, and not everybody’s a DevOps shop and so on.

So it’s been a really amazing ride. I don’t know how much you’re aware of it, but Synopsys has done a lot of acquisitions over the last few years in the space to build this group and it’s just been for me personally a very, very interesting experience to go through that, going from a pretty unknown vendor in the space to becoming the most dominant leader. It’s a hell of a ride.

Ashley: [Laughs] Well, and congratulations to you. I’m grateful to see as an entrepreneur a technologist building a product and a technology like IAST that has worked out well for you and you’re fitting into the organization and still with Synopsys, you know, a couple of years after the acquisition. I’d love to get your thoughts on—you know, you talked about when you were in more of the startup, that the thing you make, in this case IAST, you know, solves the world’s problems and now you’re part of a bigger picture. What are some of the—besides using Synopsys technologies, which we talked about earlier—it’s a great company—are there some more fundamental changes or things that you see that’s required for us to create more secure software?

And I ask because we’re creating more and more software. It’s not like the problem’s getting smaller. It’s getting much, much bigger as we do things like microservices and containers and, you know, we’re creating so many more components at a much smaller level which means more things to manage, more attack surface. What do we have to do to make the problem space easier to solve?

Maor: So I think it’s less about different technologies and, you know, maybe somebody will come up with a greater and better technology, but I really feel we have a lot of good technologies in place. I think what’s still missing is better automation of the entire workflow around security testing. I still see a lot of organizations that haven’t figured out how to get their process into sort of a railroad machine process that just works and works and works, and this is the part where we really need to improve.

Ashley: Can you say some more? A little bit how you think that might be realized or how that might happen?

Maor: So there’s a lot of activity going into the space right now in the market. We are building our own platform to make it easier for customers to integrate different technologies into an easier workflow, but I think there’s also a lot about building microservices that offer security testing that we’ll see happening more and more, and we see a lot of new vendors coming in this space, doing what we call application security testing orchestration, so basically what I just mentioned, how to make the process of deploying and running security testing and then integrating and following up on remediation or triaging a much easier process. I think that’s where the market needs to invest right now.

Ashley: Interesting. It’ll be great to see how that evolves. How do you view things like the configuration side of software? There’s writing code, of course, but to pick somewhat of an extreme example, serverless applications where a lot of that is already part of baked into the configuration of the environment that code is executing. Does that present a different kind of challenge or is that a better approach to secure applications? What are your thoughts on that?

Maor: I think that there’s a way of a fine line between configuration and code that is diminishing. A lot of configuration files today are becoming small pieces of code. I don’t think it’s inherently different. I mean even when you look at technology like serverless, people think of it as a new technology and a new approach, and there are of course a lot of innovative approaches to it, but from a security perspective the challenge there is not that different than the challenge of a client server application calling 500 different APIs that was built 20 years ago because people rely on client-side logic or don’t pass tokens properly between the different NPIs and that allows to abuse them.

A lot of this is—you know, if you learn your history you know a lot of the problems of these new technologies. So again, I don’t think personally that the challenges about the new technologies or the new configurations; it’s really about how do we build a better system for driving these testing and adapting to the changes in architectures and code languages and so on so that you can move fast and test and fix everything.

Ashley: Well, great. We’re coming up on our time here over, and I appreciate you being on with us this morning. Just so our audience knows we’re recording this at the time that the hurricane’s hitting the East Coast, so there’s a hurricane between you and I [laughs] as we’re recording this podcast, so if we have any dropouts that might be why. Well, you’ve listened to another DevOps Chat podcast. I’d like to thank you Ofer Maor, Global Director at Synopsys for joining us. Thank you, Ofer.

Maor: Thank you very much for having me.

Ashley: Awesome to have you. And of course I’d like to thank our listeners for joining us today. This is Mitch Ashley with DevOps.com and you’ve listened to another DevOps Chat.

Mitchell Ashley

Avatar photo

Charlene O’Hanlon

Charlene O’Hanlon is Chief Operating Officer at Techstrong Group and Editor at Large at Techstrong Media. She is an award-winning journalist serving the technology sector for 20 years as content director, executive editor and managing editor for numerous technology-focused sites including DevOps.com, CRN, The VAR Guy, ACM Queue and Channel Partners. She is also a frequent speaker at industry events and conferences.

charlene has 55 posts and counting.See all posts by charlene