 presentation. Awesome. Thanks, Megan. Super happy to be here, everybody. We're talking about shifting applications security left. As Megan said, please ask questions if you have them throughout the webinar. Look, I'm begging you to ask me some questions. This is so awesome when people ask questions that are engaged. If you don't have any, that's fine. But, you know, if you do, please ask. I'll try to answer them. A little intro of me. I'm Scott Gerlach, as Megan said, CSO co-founder here at Stackhawk. It was a CISO at SendGrid for about three years. I was a senior security architect at GoDaddy for nine years. I did like almost every job you could do there in security, including screwing up a lot of stuff, breaking things. I'm also a husband and dad, brewer, golfer, breaker of toasters, lots of other cool stuff. If you want to chat with me after this webinar, you can actually hit me on Twitter. There's my Twitter handle. And then you can also find me on LinkedIn as well. So today we're talking about why we want to automate application security testing, the shift to developer centric security testing, types of application security testing tools. We're going to do an example. So we're going to talk about a couple of different tools. Today I'm talking about Stackhawk and I'm talking about Sneak. And there's a very important reason I'm doing that, you know, aside from my work at Stackhawk. But the other reason is you can actually scale this into your organization if it actually works for you. And then we'll do a demo, a live demo. I'm going to attempt the demo gods here. We'll see if we can keep the internet running while we do that. And then we'll hit any missing Q&A at the end there. So let's talk about the cost of fixing security bugs. Why do people want to do this shift left thing in the first place? Aside from the person on Twitter that we triggered because shifting left seems like a Marxist comment or something. I don't know what happened yesterday. That was weird. The relative cost to fix things as they get farther and closer to production is exponentially increased. So if we look at this chart here, which came from deep source IO, the farther along you get in the development life cycle, the more expensive and like a lot more expensive, like 30X, 35X or whatever the strength, that's crazy. If you can catch this stuff in that coding, like let's hope you can catch stuff to requirements and architecture, but let's be real. You could do requirements and architecture all day, where the rubber meets the road is where the problems happen most of the time. So if you can catch that stuff at coding or at integration and component testing, you've saved almost 20X costs. So that's what's really driving this shift left mentality and market as well as a lot of companies that are coming out trying to help enable people to do this. And so you're saying to yourself, self, is that what testing is for? And absolutely. So testing is exactly what this is for. And that's why we do functional tests and unit tests and integration tests at the time of coding because of that cost savings of not pushing it to production and having your customers go, hey, did you guys know that nothing works the way it's supposed to? So being able to test that while you're writing code is super important. And failing those tests before you commit code and having those tests back you up in CICD is really important to be able to do this the cheap way, the inexpensive way, right? So being able to catch those things and test them on your laptop, test them in CICD is super important when we're doing functional unit and integration tests. But why do we treat security differently when it should be the same? They're just bugs, right? Security issues are just bugs until they get to production. And then suddenly they transform like Optimus Prime. They turn into vulnerability. So let's catch them, fix them while they're bugs. So the way that this happens today, and you probably are familiar with this, if you're in a security team or if you're in a development team and this is what's happening, testing is happening frequently, once a week, once a month, once a quarter, annual pen test, something like that. And it only happens in production. So you necessarily, this is the scary part of this thing, necessarily have to push software into production. Wait, is this your left or my left? We'll see. You have to push those things into production to find them, which is a scary proposition at best, right? Hopefully, a good person finds them or someone on a security team or security researcher and not some kind of threat actor. But then also those testing resources are limited. We kind of go, you know what, this is really application security is hard. It is real, real hard. We need application security people. I can't find any need to hire. We've got 900 developers and I've got one and a half application security personnel on my team. And so everyone's behind. One and a half is an inside joke. If you get it, you don't get it. It means you can't hire people. Next. So the way that we change this is security tools that are built for developers. So the kind of security testing isn't new, but the developer friendly version of them is. There's no silver bullet to security testing. But if the closer you can get this, the better you can get information about application security to your development team helps them work within their workflow to discover what's going on. Help them make decisions. They don't have to be experts in application security. That's what the application security team is for. But they need to be able to make decisions and have information about the decisions they want to make. So the trouble there is usually we go, Hey, I'm ready to deploy this application security team. Check it out for me. And the application security team goes, Okay, cool. I can get to that in a week. And they're like, wow, that's going to get pushed to production. So here we go. Giving them the ability to find kind of low hanging fruit or things that are easily triaged and fixed is super important because now they can make decisions and they can self serve. And if you can do this effectively, it scales efficiently because we're helping putting this kind of basic testing out into the world. We're democratizing application security in such a way that the application security team and the pen testers and the bug bounty program participants are focused on finding really hard to find stuff. And we're talking about, you know, cross system problems or logic problems or things that are really hard to test for make the easy tests easily available and readily available for people that write code. So today we're talking about two specific types of application security testing. There are more than this. I am aware that there are more than this. But this is the ones we're talking about today. And I'm going to show you why in our demo sneak, we're talking about their static code testing. They also have a software composition analysis testing tool. Those are both really good because they're looking at written code. And they're looking at written code looking for dependencies and manifest files and template files. And it does a good job of going, hey, this is, you know, you've got outdated vulnerability or outdated packages that have vulnerabilities you need to update. Wish it was as easy as that most of the time to just go, yep, cool update. Because a lot of times those break things, but that's what unit testing is for again. And the downfall here is the program is executed or interacted with directly. So does a good job of looking at written code, does not do a good job of understanding kind of the context of how things are working, what pieces of information are being taken in and given back to the user. Dynamic testing methods. So DAST, DAST testing dynamic application security testing, we're running the application and testing it actively. So what we're doing there is going, hey, run the application, we're going to just jam a bunch of stuff at it in known patterns to try to execute stuff like injections, SQL injection, command injection, cross-night scripting, looking at cookies that the application is actually serving. So static code analysis doesn't do that. So it doesn't look at the headers that the application is serving, the cookies, how you're handling that, lots of different stuff. Now, the cool thing about both of these technologies is both the routing and finding defects, and they're very, very complementary when you get them put together. And that's what we're going to talk about today. The reason we're talking about Snake and the reason we're talking about Stackhawk is because, one, both of them have free trials or free accounts. Actually, you can use both of these products for free, forever, on limited amounts of information applications. The awesome thing is there's lots of open-source tools that do the same thing. But when you go, man, this is great, I want to scale it out in my organization, it's impossible. Now you got to build products. You got to build a sneak, you got to build a Stackhawk. So the cool thing here is you can actually test, check this out in your organization with these two products, with the free accounts. And if it's working and you're like, I love this, I got to roll it out, you can actually upgrade those things and have infrastructure and people to support your process. Let's talk about how test-driven security should work. So if you think about unit testing and integration testing and functional tests, these are all things that are telling people that write software when things are broken so that they can know about them and fix them. And it's super important for that to happen early. And security testing should be the same. Security tests should go, hey, you are making a security error or mistake or introducing a problem and then be able to go, yeah, I don't care about that. Or I should fix that. Or I should fix that, but not now. I should fix it later. These are all very active decisions versus what happens today. And what happens today is a very passive decision by the engineering team most often the time. Because it's so hard to get this information or understand the posture with kind of legacy tooling, they're just making a passive decision of I'm pretty sure I write good code. Let's go to production. And there's no things there to inform them that they've made a mistake. As a CSO, I don't even care if they make the wrong decision. It's documented. There's a record of it. I can go back and review it with my application security team. And I can now have a proactive conversation with the development team. Hey, let's talk about this actual thing that exists. I think we should fix it. Let's talk about why you said we should. Versus, let's see, what is integration tests? Hold on a second. Hold on. Versus the inactive decision, the passive decision. So the couple of questions I want to hit real quick. Has the shift left trend widened the gap between security and DevOps? And the answer is it depends. So there's lots of security teams that I've talked to that have actually embraced DevOps and want to participate in the spirit of DevOps and how DevOps is supposed to work. There are a lot of security teams that don't. They kind of go, we are totally pro DevOps, but we don't operate that way. You do that. We're going to do stuff the way that we've always done it. And in those organizations, that has definitely widened the security gap. Someone also asked what is an integration test? And that's when you put more than one piece of software together to make sure that this program and this program are actually talking together and not doing this, but they're actually going, yeah, when you put us together, they actually work. Thanks for the questions. Let's talk about the right time to do security testing. And the right time to do security testing is pre-production. Like you can test in production, but it shouldn't be the first place you test. It definitely should not be the only place you test. So introducing security testing into a local development and into CICD, that's exactly what we're going to show off today in our demo, gives immediate feedback to people that are writing code. So it's super good to be able to go, hey, there's a SQL injection. There's a cross-sync scripting. And a lot of people don't think secure developers care about this stuff. And I challenge that heartily because they do. Well, they do care about writing high quality software. Security is just part of quality. Again, the problem is we make it really hard for them to know today. And that's why it seems like they don't care about this. But adding the ability to test locally allows for this quick iteration in the fixed test loop. So being able to do this while you're writing code and while you're doing your build artifacts, super important. Let's talk about DAS and Stack Hawk a little bit more. So our mission over at Stack Hawk is to modernize dynamic applications to security testing and why DAS, here's why I love DAS. You're testing a running application like a hacker would, so like a threat actor would, or a bug bounty participant, or an APSAC team member, using inputs and outputs, behavioral tests, and you can think of it like negative validation testing, right? If I put this string in here, the application should not return it to me or it should not execute it against SQL. If it does, that fails. So really, really good stuff. Really low hanging fruit to be found there. And it helps find security vulnerabilities from all of us. And such as injection, cross-site scripting, cookie errors, all kinds of good stuff. And here's maybe the most important thing. It's language independent. I have run this kind of tool at many, many companies because of this fact right here. As long as there's a running HTTP endpoint, I can test it. And someone in the development team can't show up at my door and go, hey, we're going to use Rust today. And we go, there's no things for Rust static code analysis. Now I've got a dynamic analysis tool that can help test that application. So let's talk about legacy DAS, the old school DAS. Usually a very high cost implement. So like six-figure contracts, crazy numbers, 30-day, 45-day implementation windows, scans, like a tiny bit of the application and doesn't do it very fast. And those tests are run periodically. We talked about this already, quarterly, weekly, whatever that is. And that's partially because it's really slow in how it works. And most importantly, all these vulnerabilities are found after their ship to production, more than likely. So the way that we're trying to think about this differently at Stackhawk is simple configuration as code. So using those DevOps principles, configuration as code, that configuration lives with the application that's doing what it's doing. So the infrastructure, the security scanner, the code, all live in the same place. Being able to rapidly scan HTML, REST, SOAP APIs, GraphQL, and do that at a microservice layer, if that's what you have, super important to us. Automate those tests in CICD. There's very few DAS tooling people that can actually do stuff in CICD. And when I say in CICD, I mean the scan is contained within CICD. So it's very important in DAS land to get the scanner and the application as close together as they can, because that makes request times really, really fast. When you do that from the cloud out here, over here somewhere in the applications here, there's a lot of round trip request time that goes into that. And that's what makes those things slow. And then again, the ability to find fix and triage, find fix and triage issues before production. Let's see. I think I answered the question about how shipping left increased the divide between security and DevOps. If I missed it somehow, can you rephrase the question so I understand what you're asking. So let's look at how DAS scanners work really quickly. We're talking about a scanner that's looking at an application. So it's actually kind of crawling through it, or looking at an open API spec or GraphQL introspection queries, understanding this application, then starting on some passive scans, what kind of headers are coming back, what kind of cookies are being set, kind of form CSRF, lots of different things to look at here. Then it starts doing this kind of what we call active scans. So test actively testing with malicious input against the application to see if it handles it correctly. And then reporting, right? So the end of this whole stream here is again, here's things that we've found. Again, configure and run this in less than 10 minutes. And I talked about this earlier. Usually the cost of implementation is 30 days, takes a long time. Most of the Stackout customers are up and running a scan in under 10 minutes, which is super cool. Lots of support for different authentication types. Another handy problem in applications is supporting many application types. And then open API and GraphQL support is super important to us. This is actually a configuration file that I've got up here. Very simple configuration to be able to scan GraphQL. Looks very similar for REST, server-side HTML, single-page apps. Scan anywhere with Docker. So the scanner that we provide at Stackhawk is actually a Docker container. So anywhere you can run Docker, you can run a Stackhawk scan. We're going to actually look at that as well. Deliver that scanner inside firewalls and WAFs and staging environments on laptops, super hard to do if it's not done that way. And then that thing calls home to authenticate to Stackhawk and upload results. So we can talk about that. Also complete coverage for APIs, being able to ingest open API spec or GraphQL. Interspection query is super important because that's what helps understand what those APIs look like instead of kind of the old-school method of guessing by looking at single-page apps and hoping you find all the routes. Again, developer-first platform. We're going to look at some of this, but the language here is all about what do I have to do? So the whole point is go from I understand there is an issue, I understand the issue, and now I'm fixing the issue as fast as possible. So we don't talk about things like MITRE. And we don't talk about things that developers don't understand. We talk about things developers understand in the platform. So really quickly, just kind of quick recap here. Easy to get started. Works in almost every CI. Intuitive triage screens. The scanner remembers things in between scans. So as you triage stuff, it remembers that. Gets out of the way. If there's no new issues, it doesn't bug you. It's trying to not bug you. It's trying to let you do your job all the time. And then helps give you confidence that you're not making security mistakes. So let's talk about where we're doing all of this stuff. So the sneak side, we're talking about static code analysis and looking at actual written code, which is very similar. But again, developer centric, how do I go about fixing this stuff? We're going to look at this again. But we talked about that left side, right? We talked about doing it during code time, doing it during build time to be able to go, are my tests passing? And can I release this software? So being able to do that automatically and programmatically around this release cycle, super important, but giving the power to do it back here in code and build also very, very important. So now that we've expanded, let's expand our Mobius here and actually look at what this looks like in a linear fashion. So we can do sneak and stack-hawk tests while we're writing code. We can do sneak and stack-hawk tests while we're checking in code, looking at source control, doing build triggers on PRs. When we're about to push an image, we can do container registry scanning. So sneak also supports that. So you can actually get really good coverage around all of these application security processes and be able to go, hey, before I pass this trust boundary of internal to production, pre-production to production, have all of my tests pass. And if they have, awesome, I feel great about pushing this into production. And I can also test in production if I want. But if they haven't, now I can make that active decision of why we would want to do that. So that's kind of what we're talking about here, just in general of the ability to shift that application security left. If you have any questions about what we talked about, please ask them in the Q&A. I'm going to go hammer through a demo here. So we're going to actually go do what I'm talking about. There is a link to the webinar or to the, sorry, to the GitHub repo that we're using. So you can actually check this out. It's public repo that I've set up to help you understand what this looks like, how to set up this tests, all kinds of good stuff. And it's out here under this Linux foundation webinar in my personal repo. You can see we're actually dealing with a little bit of a vulnerable spring app. And here comes a demo. Someone asked, can we see some demo for API testing and remediation coverage? You bet you can, because that's what we're about to do. So out here, the link to this GitHub repo just got posted into the chat. So if you want to check this out and play with it later, or over holiday break, great. But the two things you're going to need to be able to do this are a sneak account and a Stackhawk account, the way that it's built today. So we've got a Java spring application that's running here. It's actually this little guy. He has all kinds of different functions, form and functions. He actually is also a REST API. So there's the ability to test and check on REST APIs, but we kind of built it as a REST API and as a server side application. Today, we're going to look at the server side application, but the API is in here. And I'll show that to you in a bit. So what I've actually got here is an IDE. And this is my IDE for our Java project. I've tried to blow up this font as much as I can to make it readable. If you are on a laptop watching this, you need to zoom into it later. We have the recording. So you can actually come back and check this out and look at the individual things. But I've actually got this program running as we saw. So it's currently running today. So here's debug logs from our running. I've got two things installed here. One is the sneak console to be able to look at our open source security and code security. And then I've also got the Stackhawk scanner installed in this machine. So again, a Docker container, we're going to do both of those tests right now. The first thing we're going to do is look at the Stackhawk configuration file. Again, very simple configuration. Where is the host running? How does authentication work on this particular host? And then a couple of different configurations, including this failure threshold configuration. So that's the thing that's actually telling us if we find untriage high issues, we want to exit nonzero. So that's going to help us break the build. So we're going to run both of these sets of tests here real quick. Remember, one's dynamic, it's going to test the running app takes a little bit longer. And then the other one's the static code analysis. So we're going to look at both of those. I'm going to fire off this Docker run. It's going to do its authentication to the Stackhawk platform, go through some validation steps and then start testing. So here we go. We're doing some scanning on this thing. We're also going to do our sneak tests. So what I did before this webinar started was I actually was updating this particular repository with some updated copy. I've got this set up to actually do automated security testing when I make a PR. So when I make a PR, what happens is this workflow runs. So this is GitHub Actions. You can use this GitHub Actions as free for like 200 minutes or 2000 minutes for public repos. So you can actually test this as well. So two things we're doing here, running our HockScan, our StackhawkScan. So what that means is this application can be run as a Docker compose. So the database and the application spin up together, we're actually doing that inside the pipeline and then running our dynamic scan in the pipeline. We're doing our sneak code scan as well. And we are doing our sneak SCA, so software composition analysis scan in the same test. So that's set up for push and pull request, which means when I try to update some copy in this search form with this code push, these tests actually ran. So let's jump into what these tests look like. So you can see I've got the dynamic application security scan, the static analysis and the software composition analysis, both running. We have the HockScan that ran and it looks like it found a couple of issues, anti CSRF, I've already done some risk acceptance on these things. So you can see that most of my issues have been taken care of already. I've got a SQL injection that we need to work on for sure. And we're also going to work on this cross site scripting thing, because let's fix, let's fix some stuff, shall we? So you can see the StackhawkScan has told me, hey, you've got some problems with your running application. The sneak scan also told us very similar information, hey, cross site request forgery stuff, SQL injection stuff. I'm actually working with my good friend Tomas from sneak to see why that cross site scripting is no longer showing up in here and used to. And we also have our open source stuff. So I got a lot of packages, I got an update. Today, we're going to focus on static code analysis and DAST SCA, the whole different topic by itself. So, because I have these security tests backing me up in CI, that's awesome. The worst thing you can do is make this thing a whole black box. The only place I can test it is here in GitHub Actions, the only place I can reproduce what's going on is in GitHub Actions. That's terrible for a developer, because now I got to go, okay, I got to push code to make this test rerun and I don't know what it's doing. So the ability to run that same test on your local machine, super important if you're going to do security testing and help empower development teams. So we already saw that I can run both of these tests, we're doing that already, both of these tests on my local machine. Look at this, I got the same output. So I've got that cross site scripting, that SQL injection, I've reproduced this on my local machine. And over here in the sneak panel, I've got my cross site request forgery and my SQL injection showing up in here as well. So here's what's super cool about this. In the StackHawk scan, if I want to go look at these results out on the StackHawk platform, I need to dig into this, I need to be able to go, what does that mean? How does that actually work? I can jump to the SQL injection and go, okay, it's on the search path. My remediation work here is going to be use data object models, okay, or parameters queries, all right. On the search path, seems like we passed some stuff to the search parameters and something had, oh, there's a SQL error here. How could I replay that? Maybe I could just take this, take this request and actually jump in here and replay that same request against my app. Hey, look at that. Oh, wait. One thing I forgot. Self-signed certificate. Hey, I just replayed a security test in my terminal locally. I guess what else happened? Because I'm running that locally, I've got core dumps that happened on my local machine. So now I can start going, hmm, that probably shouldn't have happened like that. What's, what happened? Maybe sneak can help point me to the right direction. So we've got a SQL injection problem that sneak is pointing out. And it's saying, hey, out in this search service, I know you can't see this. I can't blow it up. Trust me, it says out in the search service, there's a problem. So let's look at it. So here we are in our search service. And it's telling me something around here is wrong. So let's look at this a little bit. So it's saying use parameter flows and actually, okay, so, oh, I'm doing some string concatenation here. That's probably not a good idea because string concatenation gets you in trouble in SQL server actions almost every time. So obviously, I'm cheating here because for the sake of a webinar, the right way to do this is actually do something more like this. So we've got a parameterized query here that is the same thing. So you can see that we did a select name description from item where description like and then did the search text concatenation together. The right way to do that is with parameterized queries or with the data object model, we're going to do is parameterized queries today that is safe data object model is a little bit different, but also very, very effective. So select ID name description from item where description like question mark. And then we're going to prepare the statement by throwing the query into the into the prepared statement. And we're going to set the parameter, which is this guy here, equal to the search text with some parentheses. So we're doing some wild card matching here. But this part is super important because this is what's going to prevent a SQL injection problem from happening. So we actually have this kind of fixed, but we can validate that it's fixed by stopping our program running it again. And as soon as it gets all fired up here, there's a couple of different ways that we can test this again, right? So we actually have the ability to do to replay this test again. Like we did earlier, so that did something different this time. I don't think that's the right error. But the other cool thing is we can run that Stackhawk test again. So again, just run the Stackhawk scanner from my local machine. Now I'm validating that I'm fixing stuff right here in my ID. So this is real validation that I'm actually fixing these problems. So we're going to let the Stackhawk scan run. We're also going to take a look at our sneak scan again, we're going to trash those results. We're going to run our open code security scanner again here and see what it's telling us now that we've done something here. And now here, so you can start to see some of the power of putting these two things together. Stackhawk said, Hey, on this running application, I found this problem. Here's where it exists. And here's how to recreate this kind of problem. And sneak said, Hey, here's the line of code that you can actually worry about or the section of code that you're worried about. Now that we've redone this in a parameterized statement. Look what's happening here. This my SQL injections gone from here. That's pretty cool. Let's see what our Stackhawk scan says here. Still running so that's good. So sneak is saying that I fixed this SQL injection issue, which is actually super interesting because what it used to point out was that out here in our search controller that we were passing search stuff directly. So unsanitized search getting passed to the search controller, you would have to know spring very well. Guess what developers know spring to know that you'd have to go. It's actually in the search service that this problem exists. But because this thing is now saying, Hey, look, there's not even a problem here anymore. And our Stackhawk scan, which is just about done is also saying the same thing. So we can actually go look at our Stackhawk scan live as it's running. Hey, look at that. Our SQL injection is gone. Hey, we fixed a SQL injection problem in our live code. And so now you can see the power of being able to run these tools on your local machine. So there's no more left or thing than being able to run it while you're writing code. I have now addressed and fixed both of these SQL reported SQL server issues. So same thing here. Now we just have cross-site scripting anti CSRF tokens. I still want to fix this cross-site scripting problem, but our SQL injection problem is gone. I can now confidently go, if I commit this code, one of these errors is gone. So let's look at our cross-site scripting issue. So I've got a cross-site scripting issue. What's remediation going to look like for me? Properly encoding data return for back-end data. Okay. All right. That makes sense. And I'm obviously on the search path and I'm injecting the script thing and it's coming back and popping out in my HTML. I could probably replay that, but you know what? Since we've got the app up and running, we can just do this. We've got to log in again. Here we go. Logged in. Oh, yeah. See, that's not good. That's definitely a cross-site scripting problem that I've just reproduced locally because I have the information to be able to reproduce that locally. Now, here's the trick in spring. Spring is actually doing, using this particular app, is using a templating engine called time leaf. So time leaf is actually a little bit different in how the code is working. And where this particular problem is, is in the template that renders that page. So it's actually not in the code itself, but in the template. So over here on our search template, this is, this is the template that renders this search page, search results page. So we can look through here real quickly. I've cheated and shown you, so this is all in the repo, where this problem actually exists. In time leaf, you text is unescaped text and text is escaped text. So again, if you know time leaf and you know spring, you could probably find this pretty quick. If you're an application security professional, you're unaware or unfamiliar with spring or time leaf, the chances of you finding this are slim, slim at best, right? So being able to know that you got to go, oh, that is the fix for this particular issue really requires domain expertise around spring and time leaf. So again, I think I fixed this cross site scripting problem here now. I can test it again. So let's test it again. So again, running this test locally to confirm that I've got the test in a good shape. If we go look at our stock platform again, we can see as soon as that scan starts running, we can see the scan run and watch what it's actually doing. So there's some really cool stuff that actually happens there specifically around dynamic scan. So dynamic scanning is really testing again, patterns that are important for application security status. You can see our scan has started. And if we go in here, we can actually see what it's going to do. So here's all the paths that it discovered in the application. That's that crawling discovery phase. Now we're about to start the testing phase. Excuse me, getting real dry. So we can actually see what tests are running. And this is like live, right? So you can see the tests are running over here and we're filling some of this information in running through our cross site scripting tests, we're running through our SQL injection tests and other tests. You can see how long this is taking, right? This is less than one second. How many requests I'm finding. Let's see, cross site scripting. Did I not get it fixed? You're right. I didn't get it fixed. You know why I didn't get it fixed? Because I didn't do this. I didn't restart. So let's restart our application and we'll do a retest. We're almost at the very end of this thing. If anyone has any questions, please jump into Q&A. I've got, we've got obviously a lot of time left here about 15 minutes till the top of the hour. I would love to answer any questions anyone has, help you get started, ideas about your particular environment or challenges that you've faced, trying to do this shift left thing in your organization or push back from development teams, anything I can help you with. So we're actually running our application here again. Let's rerun our test. As soon as this local tests fixes or validates that we fixed this issue, we're going to push it back up to GitHub and we're going to have the GitHub test run again. Any questions I can help anybody with out there in the world? I think I answered this one. I think I answered this one. I think I answered that one. Oh, here's lots of questions that I'm totally missing. All right, here we go. Can we see demo for API testing? API testing works very similar to how this works. So there's lots of examples of how to do the same thing for API testing, including I think this guy right here, where we're ingesting an open API configuration. So this particular app also has an open API setting. I think if I just go, there is open API JSON. So the swagger setting for this particular thing, I can ingest that with Stackhawk. Obviously, Sneak doesn't care. I can ingest that with Stackhawk and test the API behind this as well. So there's that. Compliance of these offers with OWASP-SAM, you know what OWASP-SAM I think is pretty well covered between both of these tools. There's some stuff in OWASP that it's tough to test for. And the things that are really tough to test for in OWASP specifically around REST API is insecure object access. So tenancy filters, yet another problem with security tools. We invent words that actually exist in development land. So tenancy filtering to make sure that customer A can't see customer B's information. That's a little bit harder to test for automatically. However, there are capabilities coming in, I think, both platforms to be able to write custom tests. It's a little bit more difficult, obviously, in static code analysis than it is in dynamic code analysis to be able to do the custom test stuff. So being able to go, hey, I'm customer A, I should not be able to see customer B's data. And if I do, I'm throwing alert. Hopefully that answers your question about OWASP-SAM. Let's see. Where do we find resources to learn the technology as well? So resources to learn these couple, the two that we're talking about today, Stackhawk and Sneak, docs.stackhawk.com, docs.sneak.io both have really good information about these particular applications and how to use them. Let's see. There's lots of resources on the internet, obviously, about software static code analysis and dynamic code analysis, dynamic application security testing. Lots of resources out there. If you can't find what you need, come talk to me. I'll try to help you out. Let's see. Oh, our test has finished. So you can see our cross-site scripting is actually gone. So now my thing is not alerting. Stackhawk's not alerting that I have untriaged highs. In fact, I only have triaged highs. So all of my stuff is taken care of. I'm feeling good about this. I'm going to actually commit this change and push it up to the repo. So fixing xss and c4i, push, sonar lint, look, guy, look sonar lint. We're just going to do this anyway, okay? So we're going to push that up there. And when we push that up there, we should see a brand new test running in CI CD. So again, the same test that we ran locally, ran in CI CD, yep, to back us up. So being able to run these tests in both places helps us do more efficient testing, more efficient fixing, and have confidence that when I make this commit and push to the code repository, that it's actually going to be fixed and won't break again. Let's see. Next question. How do we do this at scale? Here's the really cool part. The reason I showed you these two tools is they're built to be able to scale into an organization. So when I talk to security professionals about how do I get involved and make this effective application security program with development, the first thing I say is, how many stand-ups have you sat in with your development teams? Have you done it for a month? Have you built trust by just sitting there and understanding the problems that they're trying to solve and then help them solve those problems? That's step one. Step two is figure out how this works with a team. So will this work with a team? Can I get it to work effectively in their workflow? And then once I've done that, I can scale that out from there and include more teams, more applications throughout the organization, et cetera. Hopefully that helps with how do I do this at scale? Maybe there's another approach to deploying security in the application code. For example, implement add-ons with Nginx controller app security add on the controller delivery module. You can easily layer in security, self-service, and security insights to the apps, your dev, and DevOps team are deployed. So I think what you're talking about there is a technology called IASP or RASP. So it's looking at runtime stuff. Those are actually super good. I like to think of them as backstop things because what happens is those things don't get operationalized very well most often. So you put IASP or RASP agents into software delivery, software systems, and you get stuff that starts alerting and prod. And usually the only ones that are consuming the alerts are security teams. So again, it's this backwards. Sometimes that's really good, right? If you're taking care of low-hanging fruit and doing a good job. But it's kind of that long loop of how do I get informed about these security things. And like I said, it can be good if you're doing basics first to be able to go and now I've got a thing running in production. I think there's a ton of uncertainty in being able to go, hey, this thing that is running in production that's preventing security issues is not going to block legit customer access. I've seen that happen. I've deployed stuff that does that. I have actually blocked legit customer access. So I think if you do this first and have that as a backup, you're in good shape. Test-driven development like approach and security, yes. I think these help with that. You saw the curl command that I re-ran a bunch of those tests with with Stackhawk. You could easily make regression tests out of that. If I put this string in, it should not do. And then now there's a regression test for those things. Test-driven development. I think that's it for all the questions. I think I got through all of them. We've got just like two and a half minutes left, maybe two minutes left, something. Look, I blew it with the demo guts. I thought I had these all ignored and ready to go so that that scan would pass. I know that the Stackhawk scan is going to pass. This PR would have actually fixed itself and been good to go. I messed up this neat part because live demos. Anyway, I think that's about it for my time. Thanks everyone for all of your great questions. Hopefully this helped. If you have, let's see. There's a webinar recap. If you have any questions, please read it out to me on my Twitter handle, which you can get on the recording or my LinkedIn or shoot me an email, whichever. Happy to answer questions and help with your application security journey. Well, thank you so much, Scott. Thank you for being here today. And thank you to all of our participants who joined us for this webinar. As Scott mentioned, this recording will be available on the Linux Foundation YouTube page later today. And we hope to see you back at a future webinar. Have a great day, everybody.