So hi everyone. Thank you for joining us today at the panel discussion on application security testing. And as you mentioned that application security testing is one of the very important topics and stay tuned. We have some really, 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 audience can get to know about them. I will start off with Scott. Scott, over to you. Awesome. Thanks, Pradhana. 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 OWASP's chapter leader and I also lead a couple of OWASP projects as well. That's it for me. Thank you. Over to you, Liren. Hi everyone. My name is Liren. 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 Neural Legion. We're doing zero false positive application security testing for developers. Great. Thank you. Thank you. And we are glad to have you here, 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. 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 here, 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 in 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. Liren, over to you. I think DevOps has been there for us. The way I see it is it's laying the infrastructure to allow us to kind of scale what ops means. And 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 to then automate security inside it. So 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, that 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 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. We'll just jam our thing right in the middle. We're 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 perspective, but I think we all are talking the same language wherein we need to start shifting left. We need to understand when we are 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, still the leadership as well. So it's both ways. If leadership doesn't give you an approval to build the 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 team speaking with each other, we will never be able to build the kind of mindset or a kind of a 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 Liren. 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 saying and I'm worried with 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 there 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 in our developer before, this has been a lot of magic that happens beyond behind the scenes, right? Like 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 life cycle, 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 Bar's perspective as well on this side, because he's working around tooling, he's working around product security. So I want to take Bar's perspective on like 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 a 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, security is just bugs. So giving them what they will 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 points. Yeah, true, true. And I just realized that I have this 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. 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 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? And I think this is the important piece, 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 that I think just as important as automation. At Apache Structs libraries, it's a 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. 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's 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 that security team can help developers further, which can be useful, which can make the CI CD pipeline faster or easier for the developers so that they don't feel that there's something that 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. Yeah, 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 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 app sec 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 that's always my advice to people that are that are struggling as an app sec 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 do you want to add something to it? Yeah, I'd like to take a stab at this. It's kind of like a passion, passionate in my heart. So I agree with both of that. I think both Scott and Bar had actually referred to this and in a way that, you know, developer efficiency or effectiveness to also move fast and move in a smart way is super important. We don't I don't think anyone is expecting developers to be the next, you know, amazing security expert on the company if they do. I mean, 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 like relate to an example rather than an abstract discussion here. And that is, if, for example, you use kind of container, right, then it has 500 vulnerabilities. At that point, what do you do with that information? Right. Traditionally, security would say, you know, we'll fix it. Right. But hey, that's I don't know, node image tag has 500 different base stacks that you could use. Right. Alia says, should I use Slim or Buster or, you know, different Linux versions or different Node.js versions? Which one should I actually move to? So I think a developer first kind of 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, you know, AppSec, not 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, you know, there is a reachable vulnerability from your code to that vulnerable dependency that helps you make a decision. So now you have 100 dependencies that are vulnerable in your POM file, but you know which now to prioritize to fix first. That's the way that I see us 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? Yeah I think mainly there are probably two categories of pain points. 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 vulnerabilities. So this is kind of a technical pain point and trying to resolve this also the multitude of frameworks that developers use and obviously today we heard about lots and lots of testing frameworks and the development frameworks and basically fitting your security tooling to make sure that it supports it. It's 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 is 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 tool 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 a pipeline for the first time is kind of a bit smoother. Yeah I agree, totally agree on that point. Like sometimes you mentioned that it's not a shock but trust me it's a shock. Now Scott can you please add your experience with this? I know you've been working a lot around this area so I would like to hear from you on this. Yeah sure I'll try to keep it tight because I know we're close on time. We always talk about three things that are kind of barriers to entry in security tooling with developers. 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 you know 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 the app works so they struggle with things like authentication and they're doing it in production again. But then the kind of cultural shift of you know 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. I agree with you on that and I remember spending days on just finding that where exactly is the bug how to fix it 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 projects. 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 here I'll start off with Liran then we'll go to Bar, Sam and Scott. Well yes so I am involved with the OSP 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 on OSP 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 on to 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 you know 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 OSP 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 OSP project. What I'm going to say that lots of lots of fantastic OSP open source projects which can help developers in securing their work and securing their pipelines and of course OSP Zap being our dust 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 in terms of the standards like ASVS. Another very important thing if you really want to 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 OSP 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 an attacker do with your application. So it's quite important to look at this. Another some great tools which are not specifically pipeline is a threat modeling tools like OSP Threat Dragon can help you build a diagram your threats early in your 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 OS Cornucopia board game. So you can play board games with your developers and you can learn about threats. Thank you. Thanks Sam. Scott we're just going to 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 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 CI CD or DevSecOps method submit a presentation. We'd love to share that with everybody. Thank you so much Scott. This was really helpful and thanks every one of you for joining us today and a huge 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. Thank you so much.
GraphQL Galaxy 2022
