Panel Discussion: Application Security Testing

So, hi everyone. Thank you for joining us today at the panel discussion on application security testing. And as we mentioned, application security testing is one of the very important topics and stay tuned. We have some really amazing guests with us as the panelists. And I'm going to request all the panelists to introduce themselves one by one. And before that, let me introduce myself. My day's job is with one of the multinational companies. Apart from that in my free time I spend on pro bono work, where I am one of the global Board of Directors for OWASP, as well as I run some diversity initiatives with InfoSec girls, InfoSec kids, and some other initiatives.

Now I'll head on to our panelists, where I'll ask them to share a few words about themselves so that the audience can get to know them. I will start off with Scott. Scott, over to you.

Awesome. Thanks, Pedona. I'm Scott Gerlach, CSO and Co-founder at StackHawk, which is a developer-focused, dynamic application security tool. I'm going to keep mine a little short because I know we're kind of tight on time and I want to get to this really great content. Thank you. Sam, over to you.

Hi, I'm Sam and I'm an independent application security consultant by day, and in my spare time, just like you, I do pro bono work and do volunteering for OWASP. I'm an OWASP London chapter leader and I also lead a couple of OWASP projects as well. That's it for me. Thank you. Over to you, Liren.

Hey, everyone. My name is Yaron. I'm a developer advocate at Snyk where we help developers build open source in a secure way. That's it. Over to you, Bar.

Hi everyone. I'm Bar. I'm a security researcher, hacker, developer, and software architect. I'm the CTO and co-founder of Neuralegion. We're doing zero false positive application security testing for developers. Great to be here. Thank you. Thank you. And we are glad to have you all here with us. And now I will straight head to the panel discussion and start like we will start the discussion around application security testing.

And now I will straight head to the panel discussion and start like we will start the discussion around application security testing. So I have been hearing that DevOps with security and or what we call it as DevSecOps. Everyone has their own way of defining it or have their own definition. So I would want to know from all of you, each one of you that what it means to you, what DevSecOps means to you.

So this time I will start off with Bar so we'll go in a reverse order. All right so first of all I think it's an interesting topic to discuss. DevOps in general is about connecting two communities together. It's about connecting the people of the ops and the people of the development. Those used to be kind of rivals before and I think it's very important and a very good idea to try and create some kind of a bridge between those two sections. DevSecOps more specifically is about introducing security into the conversation. It's about trying to see how those security concepts, tools and other techniques can help enable and not interrupt developers and Ops personnel with what they do. Yeah, that's great.

Lyrin, over to you. Yeah, I think DevOps has been there for us to, the way I see it is, it's laying the infrastructure to allow us to scale what Ops means. That's how I see it really helping and coming into life with DevSecOps. For me, it means it's not just about automation, it's about putting the infrastructure, putting everything, the automation that is needed for developers then automate security inside it. It's not about using a specific tool, one or the other, or in a specific stage, it's about building that pipeline, that infrastructure, everything that then goes together and flows in a very seamless way. That's the way I see DevSecOps. Yeah, totally true.

Over to you, Sam. Yeah, for me, I think DevSecOps first of all is a philosophy, it's a culture. It's a culture of introducing security as code to everything, making sure that people treat security as their responsibility, as their job. So it's not just about tools, it's not just about automation, it's about state of mind, security first, that's what DevSecOps should be, really. It's an overarching state of mind for all of us. Yeah, true.

Over to you, Scott. Yeah, I'm about to get myself in trouble here. I feel like I need a how it started and how it's going meme for this. Because I think what everybody said is like the vision of DevSecOps, right? It's security is part of the develop and operate applications cycle. And we have to keep putting security into there so that people keep talking about it.

But I think the way that it started was DevOps, Dev and Ops teams were leaving security behind and security teams were like, hey, we want to play in this awesome little circle tool. Let's just jam our thing right in the middle. And then they get left behind because they're not operating in that same cycle that Dev and Operations or DevOps teams are. I think we're getting to a point where security teams are starting to see I need to be more agile, more flexible, more cyclic, like the DevOps team is. So I think we're again, how it started, how it's going, kind of meme. Yeah, absolutely. You have different perspectives, but I think we all are talking the same language wherein we need to start shifting left. We need to understand when we're talking about DevOps, we're not leaving security behind. And it's everyone's responsibility, not mine's, not developers, but all of ours responsibility. Even when we talk about culture, culture has to go upside down and it has to inculcate from the developers till the leadership as well. So it's both ways. If leadership doesn't give you an approval to build a DevOps pipeline or DevSecOps pipeline, you cannot do anything. Similarly, if we don't have the right kind of culture, and we don't have the teams speaking with each other, we will never be able to build the kind of mindset or a kind of habit that we want for DevOps or DevSecOps.

Now, when we are talking about DevSecOps and we're talking about that security testing is becoming an integral part of DevOps pipeline. So in your perspective, how much automation is important and how much relevant it is because everyone says that we have culture, we have tooling, we have whatnot around DevOps and now we're talking about culture as well. So how much automation has a role to play in that? And I think we can start off with Liron.

Yeah, sure. So when we talk about automation and the security importance of that in the pipeline, we need to understand a thing that when we say DevOps pipeline, this is basically a word where it's being able to deliver something, right? That's basically, if you're unable to deliver something, if the pipeline is stuck, you are basically now not delivering, not putting out something that you need for customers. By the way, that could be a fix, a security fix or a fix for regression. So that's a very important aspect. And automating security into that means that you're now basically giving the organization, the business, a company, a way to basically be able to ship something fast in a secure manner. So that's kind of obvious. But what I think we're missing here is that a lot of the times when DevOps, that pipeline is something that is, for many times, I think, also from experience from being a developer before, this has been a lot of magic that happens behind the scenes, right? People just merge something, there's a pull request merge majestically, it goes into production, right? It's there. It went through so many automations and regression tests and visual testing and security testing and performance testing, so many things. So having security automated into that, that is basically giving you more guardrails and ability to deliver fast in a secure manner. And you have to do it throughout the app lifecycle, right? You have to do something when you think about applications today, this is more of like a cloud-native application security world, because it's not just your dependencies, it's your container and then it's your Kubernetes YAML. A lot of things that basically are present when you actually click that merge button and something magically goes into production. And then that security automation being basically all the way, that is what I think is going to be life-changing in terms of how you push security into the DevOps lifecycle.

Yeah, I totally agree with you on that. Now, I want to take Barr's perspective as well on this side, because he's working around tooling, he's working around product security, so I want to take Barr's perspective on how automation is helping his teams and the work that he's doing around product security.

So, I think the most obvious is that automation is key, right? We can't expect anything to work in this DevOps, DevSecOps paradigm without having automation. I think that's something that a lot of companies miss, is that developers, even though we really want, like our dream, is that each developer will be this kind of superhero for security, knows everything about security, can run his tooling, can do manual testing, can verify everything, and that's not how it's going to work. And I think that even in the best way we shouldn't even expect that. Developers are here to create amazing things. They're here to build. And I think that using automation and giving developers the right tools through this automation, not to make them security experts but to allow them to see those security concepts, those bugs, because security in the end is just bugs. So giving them what they know, which is bugs, but in the security kind of way, that's where we really aim. And that's where security and GitHub and all of those amazing new integrations are happening. And it's really, I think, that's the main point.

Yeah, true, true. And I just realized that there's something that I want to ask all the panelists. But before that, I would ask Scott or Sam if they want to add something to it, based on their experience with DevSecOps.

Yeah, I think one important thing about automation is, first of all, it needs to be there, right? Because obviously, if you don't automate security tools into your pipelines, you don't really get that nirvana of DevSecOps.

But I think what's important, and I think what's already been mentioned, is that developers need to actually play with security tools that they integrate in public. They need to understand them because this is where automation is important, because previously, when we had manual process, developers would write a piece of code, and they would throw it over the fence to a security team. Security team will do their scanning, and they will produce a result with lots of vulnerabilities, like long list or your code is buggy, lots of security flaws, and they will throw it back over the fence to developers, and developers say, well, what are we going to do with this? I think this is the important bit, is just to make sure that the developers and security teams, they're actually collaborating together on the automation, and they're building that automation together.

True, Scott. Yeah, everybody said amazing stuff, I just want to build on a little bit. Automation is obviously super key, but a thing that Lirian said was really important, and that's don't make block boxy stuff happen in CICD. If your developer can't outside of CICD, understand or run the process or has control over what's happening with security tooling or QA tooling or whatever that might be, and they can't reproduce what's about to happen in CICD, that's when you start introducing that, how can I work my way around this thing because it keeps blocking me and I don't understand what it's doing. So making sure that those kinds of things are available outside of CICD and accessible and all that good stuff, and I think it's just as important as automation. At Apache Strux libraries, it's a small vulnerability I can probably deploy. Small vulnerability I can probably deploy without it. Yeah, I do remember that. And actually you mentioned the right way that developers are trying to find ways to escape security because they are the superheroes of development and we are trying to make them superheroes of security. But what instead we could do is we can make them security champions and then we can take help from them.

Now, Scott, a question for you around the same thing, like developers are working rigorously making sure that the applications which are developed as the way that they have envisioned or the clients have envisioned. So, when it comes to security testing, it sometimes, we all know that it becomes an overhead or something which is overburdened for the developers. And we all have been developers so we can understand that pressure. So, are there any developer focused tooling which is available or there's something the security team can help developers further which can be useful, which can make the CICD pipeline faster or easier for the developers so that they don't feel that there's something that is putting pressure on them, but they feel that, yes, it's part of my daily job and it's totally cool to do it? That's a great question. I think there's a lot of logos on this panel here and there and here and that are great, great insights into where you could get started. You know, there's obviously some open source tools out there that do similar stuff to all the products that we're representing here, but having that commercial focus into the user and making sure that the things are working the way that they're supposed to are really good. But the most important part is just starting, right? It's picking some stuff, whether that's SCA or static code analysis or DAST, or whatever those things are, picking one and iterating on there if you're starting out. If your AppSec team is struggling with getting results to fix because the value is in fixing security bugs, not finding security bugs. And you're trying to rework, start small. That's always my advice to people that are struggling as an AppSec team is just start with a tool in a project and iterate out from there. Make sure things are working the right way and continue driving for developer adoption. So Liren, do you want to add something to it? Yeah, I'd like to take a stab at this. It's passionate in my heart. So I agree with both of that. I think both Scott and Bar had actually referred to this in a way that developer efficiency or effectiveness to also move fast and move in a smart way is super important. I don't think anyone is expecting developers to be the next amazing security expert on the company. If they do, that's amazing, but it's not an ask.

We can't do that. But instead, what we can do is help them fix the problems. So I'll take two practical examples of what this means so we can actually relate to an example rather than an abstract discussion here. And that is, if, for example, you use Container, and it has 500 vulnerabilities, at that point, what do you do with that information? Traditionally, security would say, we'll fix it. But hey, that node image tag has 500 different base stacks that you could use, right? Alia says, should I use Slim or Buster or different Linux versions or different Node.js versions, which one should I actually move to? So I think a developer-first security tooling is one that helps you make that decision, tells you which probably alternate base images you could try to do that. Similarly, if we talk about AppSec moving a bit downstream from the cloud native here about containers to maybe, for example, Java developers, one of the things that developers... I see frustration with developers when they need to scan the dependencies and they have this issue of, well, maybe I don't use that dependency. Maybe that vulnerable function in the dependency is not callable, right? In code, maybe my code doesn't call it yet, it's bundled, but it's not getting called. So I think that if we have a tool that helps you and says, there is a reachable vulnerability from your code to that vulnerable dependency, that helps you make a decision. So now you have hundred dependencies that are vulnerable in your POM file, but you know which now to prioritize to fix first. That's the way that ICS basically helping developers fix the problems. Right.

Yeah. So now I want to ask Sam, we've all been talking about that developers have issues with that. Now developers are facing issue. Developers should be champions. We've been talking about DevSecOps, but there is one point that still I'm scratching my head, and I want to know that what are the pain points of integrating security testing? And we all know that we have to integrate, but I know there are some pain points that we all go through. And it's not just for developers or for testers, it's for security team as well, for leadership as well. So Sam, I would like to start off with you that, what do you think that, which are the pain points in integrating security testing early in the pipeline?

One is technical pain point. And I think because we're in a test JS summit, worth mentioning that in particular with JavaScript, there are some issues with some of the tools, for example, a simple technical thing that they, for example, would require JavaScript to be not minified, for example, or packed in order to be able to scan it efficiently, right? Define vulnerability. So this is kind of a technical pain point. And trying to resolve this, the multitude of frameworks that developers use, and today we heard about lots and lots of testing frameworks and development frameworks, and basically fitting your security tooling to make sure it supports it. It is quite a challenge.

The second pain point is the cultural pain point. Because suddenly introducing all the security testing tools into pipeline, it's, well, I wouldn't call it shocking. But it is culturally quite a difficult thing. And obviously, there's one question which always pops up. And I don't know, it's like the eternal question to be or not to be. And the question here is to break the build or not to break the build. So do you guys break the build? And if your security tools start breaking the builds, what are developers going to think about it? So this is one of the interesting pain points. So for example, with build breaking, one of the things that I always find useful is actually not to break the build, but make sure that security findings are given to developers as comments on the pull request, for example. This makes sure that the cultural shock when you get security introduced into your pipeline for the first time is kind of a bit smoother.

We always talk about three things that are kind of barriers to entry in security tooling with developers, and one of them is the production bias. So a lot of tools that are security tools have this like you have to run it in production, which means you have to push your vulnerabilities to production to find them, which is weird. But then it's also the older version of DevSecOps is it's the wrong people working on the wrong things at the wrong time. So it's application security people who largely probably can't fix these issues. They don't know how to app work, so they struggle with things like authentication and they're doing it in production again. But then the cultural shift of here's the people that can fix this thing and they can check it while they're writing it and they can ensure that they're making active decisions. I know Liran made a joke about the Apache struts vulnerability, but if they knew about that and they said, I'm going to do this anyway and documented it, wouldn't that be super awesome to know as a security person that you actually did that versus I have no idea where we have Apache struts at all?

I agree with you on that. And I remember spending days on just finding that where exactly is the bug, how to fix this, how soon I can do it and who should I reach out to. So yes, absolutely.

So a lot of tools that are security tools have this like you have to run it in production, which means you have to push your vulnerabilities to production to find them, which is weird. But then it's also the older version of DevSecOps is it's the wrong people working on the wrong things at the wrong time. So it's application security people who largely probably can't fix these issues. They don't know how to app work, so they struggle with things like authentication and they're doing it in production again. But then the cultural shift of here's the people that can fix this thing and they can check it while they're writing it and they can ensure that they're making active decisions. I know Liran made a joke about the Apache struts vulnerability, but if they knew about that and they said, I'm going to do this anyway and documented it, wouldn't that be super awesome to know as a security person that you actually did that versus I have no idea where we have Apache struts at all? I agree with you on that. And I remember spending days on just finding that where exactly is the bug, how to fix this, how soon I can do it and who should I reach out to. So yes, absolutely.

Now, before we wrap up, because we have very minimal time left, so it's a question from each one of you, and I know that each one of you is contributing to some or the other open source project or is using some of the open source project. So any open source project that you want to recommend to our audience, where they can go back and check, which can help them in building a secure pipeline. So I'll start off with Liren, then we'll go to Bart, Sam, and Scott. Well, yeah. So I am involved with the OWASP Node Goat project. It's basically a vulnerable application that helps you train and you'll learn about vulnerabilities in your code and in your dependencies with Node.js ecosystem. So if you want to try it out, it's a really cool one. You can work workshop, it has tutorials, videos, explanation. I would say that's a really cool way to do security championship within your company. I also maintain some other security projects, both OWASP and my own project. So if you want to get into open source or one of these, I'd be happy to work with you and mentor you into this open source projects. So onto Bar. Thank you. So I think just maybe raising one point is that when integrating new things into your pipeline, even open source tools, it's really important to understand that you might get a bit overwhelmed with notifications, alerts and all of this noise. So just pick and choose what you want to work with because most of those tools are really noisy. But one tool that I think is pretty nice to start with is the Oasp Header Tester, which does header security very, very nicely and it can give you some kind of a very nice baseline for header security, which is something that usually is like looked as a nice extra or something nice to have. But that could be the difference between an XSS or a similar very strong application security issue and not having that. Over to you Sam! Yes and thanks for mentioning an OASP project, what I'm going to say that lots of lots of fantastic OASP open source projects which can help developers in securing their work and securing their pipelines and of course OASP Zap being our DAST scanner which can scan your applications for vulnerabilities and it's available as a github action which you can drag and drop and use straight away. For example there's dependency tracker dependency checker which can scan your code for dependencies. So quite a few tools available also in terms of the standards like ASVS. Another very important thing if you're interested in looking at how to shift security left is you need to start from your epics and stories and one project that not many people are talking about that we have at OASP is user security stories. So this is what you can incorporate into your design into your requirements from the very very early stage you can have all your security stories as a user and as an attacker. What can attacker do with your application? So it's quite important to look at this. Another some great tools which are not specifically pipeline is threat modeling tools like OASP ThreatDragon can help you build and diagram your threats early in a lifecycle and another quite interesting project and it is a really fun tool completely unrelated to pipeline but it's important for DevSecOps and for your culture is something like OASP Cornucopia Board Game so you can play board games with your developers and you can learn about threats. Great, thank you. Thanks Sam. Scott, we're just gonna go to the wrap before that. Please go ahead and share your tools. Yeah, totally. Sam pitched all the really good open source ones that I was going to mention including ZAP. We super love ZAP, and in fact like a half an hour ago we announced a call for presentations for the first ever ZAP user conference. So check that out in the ZAP Twitter handle and lots of other stuff. If you have ideas on how to use ZAP in a CICD or DevSecOps method, submit a presentation. We'd love to share it with everybody. Thank you so much Scott. This was really helpful, and thanks everyone of you for joining us today and a huge shout out to our panelists for sharing their views. Hope to see you all soon and do follow all our panelists to get more updates around application security.