Shift-Left Security Testing with Kevin E. Greene

Five, four, three, two, one.

Drop that.

Welcome to the Test Guild Security Podcast. We're all getting together to learn more about security testing with your host, Joe Calantonio.

Hey, it's Joe. And welcome to the first official episode of the Test Guild Security Podcast. If you haven't Already, check out episode 00 to find out why I created this podcast.

Today we'll be speaking with Kevin E.

Green all about Cybersecurity Security Testing at Speed and Swamp. Kevin has over 20 years of security expertise and is known as an innovative thinker and leader with strong cybersecurity expertise and a great deal of expertise leading federally funding research and development in the area of software assurance. Kevin has also written several articles published by Doc Reading discussing various ideas, problem areas solutions as it relates to advancing the state of art and practice in the area of software security testing assurance. Lately, Kevin has been focusing his attention on evangelizing approaches, ideas and strategies to help organizations shift left moving security into the requirements and design phases of their software development life cycles. So as you can tell by his experience, I'm wicked excited to have Kevin as our first ever guest. He brings, I think both a background in research and also hands on experience that I think we can all learn a bunch from. So you don't want to miss this episode. Check it out.

It's no secret that the number and complexity of applications are growing, but what is alarming is that 90% of security incidents result from exploits against against defects in software. The need for better application security has never been higher and micro focus Fortify is here to help. Fortify is the recognized market leader in application security and it is the most comprehensive and scalable application security solution that works with your current development tools and processes. With Fortify you could start security applications in a single day, including custom code, open source or commercial components, components and scale as your needs grow with an on premise as a service or hybrid implementation, check them out. Head on over to microfocus.com app security hey Kevin, welcome to the Guild.

Hello, how are you doing? Thanks for having me. I appreciate that.

Awesome. So today I'd like to talk about all your insights around cybersecurity security testing at SPEED and also swap. But before we get into it, Kevin, could you just tell us a little bit more about yourself?

Sure. Kevin Green been doing cyber for about.

Over 20 years.

Started out doing a lot of the operational work, firewalls, IDS and stuff like that and eventually got more involved in some of the more I will call sophisticated aspects of cyber. As technology started to mature as Threats start to emerge. And then eventually, you know, got into working in the government and kind of really tried to lead federal R and D around trying to improve how we test and evaluate software for potential bugs that can expose vulnerabilities in software, and really trying to create four leaning capabilities to improve how we do it. Because obviously software is, is a big part of everything we do. It touches every aspect of our lives. So trying to, you know, work with, you know, key stakeholders in industry, academia to kind of create some novel capabilities and technologies to improve how we look for issues in software and in particular security issues was something that I was very, very passionate about. And you know, I think that's one of the things that we're seeing now. So much of what can be traced back to security breaches and security issues can be traced to poorly developed, poorly designed software. So that's kind of how I've been doing it. Now I'm doing some work, working with different sponsors and trying to help formalize their DevSecOps strategy, working on some threat intelligence stuff around key indicators or key key controls that are known to be associated with security breaches and really trying to formalize that into a community to get support to try to, you know, look at how adversaries are attacking or trying to attack different enterprise organizations and really rethink how we are approaching how we're doing security. It's so important because people are asked to do so much with so many, so little resources, and I think we can be a little bit more efficient in terms of what we monitor, what we protect, how we mitigate potential issues as it relates to security.

Yeah, so it's a great point. And for some reason lately I've been hearing more and more about security testing, the need for it, even though it used to be on our backlogs. As a definition of done for teams I've worked on. I guess the biggest hurdle though is like you said, people are so busy and yet for some reason security, even though it's been around for a while, a lot of people don't know much about it. So when you're doing like a DevSecOps type strategy, how do you get teams to like, what are some building blocks people can use to start implementing a security type strategy for their software?

Well, I think, you know, it's really important to develop the right mindset as it relates to security in software development. And what I mean by that is the goal is really try to get the entire team to think about ways in which the software can be attacked, whether it's through, you know, doing formal threat modeling, through misuse and abuse cases, and really trying to get people to think about, you know, the design decisions that they make up front. What security requirements that needs to be part of the acquisition strategy? Are we part of a solution? Really try to codify those aspects of security all the way left into acquisitions and requirements so that, you know, when you do develop or procure a system, you can test for these requirements that you have built into whatever acquisition strategy you have so that you reduce your risk and reduce, you know, the attack surface that is known to be associated with software development. So I think that's the key aspect where you try to get everyone on the entire team. When I say the entire team, I'm talking about the entire product team. From product owners to product managers to developers to engineers. You want everyone to think about security. That way it ensures that everyone is taking a shared responsibility regarding security. And it's not just the security organization or security team's job to do security, but everyone is collectively thinking about security and building the right mindset to build a good product so that you can deliver software and have capabilities out to your customers or to, for instance, your war fighters to keep driving and pushing the mission forward. So I think that's very important, to really solidify that up front. The technology stuff to me is secondary, but I think initially developing that level of culture, that level of mentality, that mindset is so important because you can't build security in if you're not thinking about it from the onset. So that's why I think that's very important.

Absolutely. I was watching one of your presentations online and it was about security at speed. And you brought up the point, just like you just said now, about actually building security into your product while you're developing it, not waiting to the end for some other security team that's going to test it. Are there best practices developers should then use when they're creating code or when they're thinking of code like, hey, I need to make sure I code for this known exploit that I know is going to leave me vulnerable if I don't do it up front?

I think essentially the goal is to really to have good requirements, security requirements that can be formulated into good design principles and use those design principles to develop a architecture or system design. And I think it's very important that developers are aware of security or design principles so that when they are coding, they are aware of it and they understand the consequences of their coding or refactoring on their daily activities so that we're not creating technical debt or gaps in or the, I should say the architecture. The security design principles are not eroding over time because of poor coding violations. So I think from the onset, I think that's a very important aspect, is for developers to fully understand the design principles so that they are building or implementing the design correctly in code. So that's one. The other is obviously developer training and really understanding what I call defensive security programming and understand ways in which attackers are trying to attack a particular, particular application or system and really understand secure coding principles. But the other piece is also is a lot of what we do from software development is really building gluing things together. It's not a lot of software development that's really going on. It's more using components and frameworks to develop an engineer system. And it's really also important to understand the hygiene of components and understanding how these components can potentially expose an attack vector or attack surface that could potentially lead to a security breach. So it's important that you, you know, you start off with good components. And when I say good components, I'm talking more, more so in terms of having a good hygiene. And typically what people have been used to is basing hygiene based off of CVE scores or CVE entries that have been reported through the National Vulnerability Database. But I would take it a step further. It really tried to emphasize the need for developers and organizations to focus on the defect proneness rates of these components and software as well as the attack proneness rate of these components and software because it's very important, because you can get a component that has a pretty decent hygiene or track record in terms of the amount of issues that have been vulnerabilities that have been associated with it. But that does not mean over the next six months or to a year it's going to maintain that level of, of hygiene is important to kind of have an idea of if I, if I choose this component, what's the overall effort or level effort to maintain it over the course of the system lifecycle. And I think it's important to have these things in your mind as you do software development.

So is there a way, you know, with Git and everything, people can just pull down components, throw them into their application, paste it together? I'm sure there's things that could make them highly vulnerable to certain attacks if these components are kind of not security conscious. So how do you rate these components? Is there like a system you can go to see how secure a certain component is? That they may be consuming in their application before they even decide on using it.

So I think there are things that are out that different technologies, different solutions that are out that tries to give some type of scoring regarding the hygiene of components. But that, that's largely from what I've seen been, been associated with tallying a bunch of CVEs which is common vulnerability exposures. Right. That's something that, you know, each time a vulnerability is, is discovered, there's an entry that goes into the national vulnerability database that uniquely identifies a particular vulnerability in software. So there are solutions out there to do that. But I think we need to move a step further and be more forward leaning and really start thinking about what could go wrong and what will go wrong by using this and really understand the touch points of bringing this particular component or framework into my organization, how best to implement it into my environment and really have some idea as to what's the level of maintenance that's going to be required of me down the road by bringing this in. I mean, for instance, if I buy a new car, I mean, you know, especially if it's a, you know, a high end car, I mean I better be willing to pay for the maintenance that's associated with it. Not to say that there's going to be frequent, frequent issues with the car, but typically high end cars have a higher cost for maintenance. So. And I think the same can be, can be said for software. Is that really understanding, you know, what the component is, the community around the component as well as intelligence around a component? What are you seeing from a threat intelligence standpoint that may steer you away from this component given the different type of activity you see from adversary behavior regarding a lot of software. Because what we are noticing is that adversaries are starting to or have been doing for a while trying to infiltrate the open source repositories and in many different ways. And I think it's important to have some, some idea be cognizant of that as, as people are starting to develop and design systems.

Cool. So I think along this kind of this, this getting the mindset of having people more aware of security and things they can do, you helped create something called swamp, the Software Assurance Marketplace could just at a high level tell us a little bit more about swap.

Sure. SWAMP is, was a program that I led when I was at Department of Homeland Security, which stands for the Software Assurance Marketplace. And essentially it was a research infrastructure that's designed to try to do a couple things. One, provide a place for people to test their Software. One of the major barriers for doing some level of software assurance is access to compute power resources and tools. So the swap was really designed to help lower the bar to formalize some aspects of software assurance in terms of the testing aspect of it. And by offering a platform where there's free computing power, free resources in terms of test data, test targets as well as tools leveraging open source tools where you can bring your software in or you can download something called swamp in a box to run your software through and have some level of visibility into what's going on with your software and just being able to identify some of them, some of the low hanging fruit as it relates to bugs that can expose vulnerabilities in software. So that's one aspect of Swarm. The other is really to provide a research infrastructure for tool developers to bring their tool and run their tool against an enormous amount of, of software. So there's, there's the NIST to make test cases there, there's tons of open source software there. These software packages become targets where, where software researchers can, can run their tools against these targets, look for ways to improve the tool, figure out what techniques work, what doesn't work across a, a broad range of software, whether Was it Java, JavaScript, Perl, Python, whatever you name it, the swap was able to bring the corpus of these tools and packages into a research facility to sort of kind of facilitate the need to try to improve and develop new techniques in terms of how we test and evaluate software. So those are kind of the underlying principles and the impetus for the software insurance marketplace. And as I mentioned, the swamp in a box is something that you can throw behind your firewall and use on prem and be able to formalize, you know, at a very, very low cost because the swamp is formalize some aspects of software assurance. And also, you know, you can integrate your commercial tools and still get your return on investment by bringing your commercial tools into the swamp in a box or the swamp platform to get the best of both worlds. Because one of the things we did find out is that studies, some studies have shown that using more than one tool can help improve tool coverage. So the goal is really try to try to improve tool coverage with, so we can lower residual risk in using these tools but get more visibility into what has been a systemic problem, the false negative and also try to figure out ways to reduce false positives that known to be associated with using these tools.

Very cool, Kevin. So what I really liked about it, and I don't know if this was an unintended feature is I was watching an interview with someone saying in their classroom they have their, the software developers submit their code to Swamp and you get kind of a report back and then you can go over maybe what they may have missed to help them know maybe how to write better secure code, which I think is severely lacking where any sort of software development is any sort of testing training. So is that something you see being popular or as a feature being used that way?

So I really kind of hit on the two major features of Swamp, but obviously there's other value propositions associated with the Swamp. And you just brought up a third one that I probably should, should have mentioned forgot. So as, as when I was a program manager, I, I, I work with Bowie State University Dr. Lithia Jackson and in trying to bring the SWAMP in the classroom as well as the SWAMP team working with folks out in Madison, Wisconsin to really expand the use cases associated with the Swamp. And the classroom is, is a perfect example of how it does a couple of things right. It refines those who are learning how to code, helps them understand some of the, some of the mistakes they're making in terms of their coding practices, but it also helps them see what issues that could be associated with their coding style and things they need to modify or things they need to change or key areas around software development that they need to investigate as it relates to, you know, trying to develop good code, good code that has good quality, has, you know, good, good structure. That has been such a, a big problem. What we've seen with a lot of these, and no mock to these organizations, these coding communities like code.org and I'm not saying code.org specifically but, but since code.org came out, there's a lot of grassroots organizations that are, are starting these programs, is teaching youngsters and individuals how to code. But one of the biggest problems is, you know, there's the security aspect of it. And I think bringing a SWAMP in a classroom, especially in academia environment, is a great way to reinforce the good coding sensors that are so important to have our future upcoming software developers who are going to lead our next generation of software development and innovation.

Yeah, I love it. I think it's a really cool idea and hopefully it'll catch on. So like I said, I think this podcast could be geared more towards beginners. You mentioned something about Juliet Test Cases for folks that don't know what is the nsa. Juliet Test cases.

Essentially there are synthetic test suites that are used to try to help improve the detection rate in software static analysis tools. They have known issues in them. And, you know, you can either determine if the two found it or it didn't. It's one or the other. Right. So these Juliet test cases become test targets that can be used to evaluate in benchmark tools. So as of now, when I was associated with supporting some of these programs, when I was a federal employer by the Department of Homeland Security, I know that they had Java and C and C. I'm not sure if they expanded the languages, the language set, but those were the core languages that were supported through the JIRA test case suite. Essentially they had coding violations issues, potential bugs embedded in the small snippets of code. And the goal was to really determine if tools was able to find it or not. And that way it gives us some idea to try to realize and rationalize around what tools are really good at. What are the strengths and weaknesses of tools? I think that's important when trying to select or try to determine what tool to use in your organization, because not all tools are good in Java, not all tools are good in C or C. And to really think realistically that a tool is good at everything across all the different software programming languages and across all the different weakness classes is not realistic. So, you know, these, these tests that were ran or the support of, I should say, of the G let test case was a good way to try to benchmark and really get some understanding of what the tools can and cannot do. It also gives us some indication of where we need to focus our research in trying to improve the tools. So the Swamp uses Juliet, as well as a number of my researchers who did research for me, to really try to identify the strengths and weaknesses and then kind of use that to either focus on other ways to continue to improve the tool, especially around open source, or come up with new innovative techniques that a lot of these tools just don't have and try to close the gap that exists in the state of the art.

Now, I know you mentioned there is not one tool, one uber tool I think is how you worded it in one of your sessions on security testing. But you know, with automation for functional testing, a lot of vendors are coming up with machine learning and AI and big data. Is that something that can maybe help security testing to maybe find issues that maybe can't be found as of now with the current practices?

Well, I think a couple of things. So having the amount of data to train these algorithms is very important. And I'm not sure if there's enough sample, sample data out here that can be representative of that So I think, you know, not saying it can't be done, but I think that's a challenge. And a lot of, a lot of organizations, a lot of companies struggle to get to a point where they have enough good data to train the algorithms and get some confidence in the fact that if it finds something, you can rely and it's reliable. The other part is I think we have to be very careful in automation because, you know, we can automate badness as well. Right. So, you know, a lot of times, you know, we have not been good at doing the basic security hygiene things and practices and if we, we were to automate that, then we're, we're automating a lot of badness. And I think the goal of automation is really try to automate the things that we know are proven, we've had success with and are some, you know, in some regards low hanging fruit that, you know, they become mundane tasks and we can just automate it and really, you know, try to focus on other things and have some level of confidence that whatever, whatever the algorithm's find that they are reliable and can be trusted. But also we gotta be cognizant of some of the threats that have been associated with machine learning and algorithms. I know that there's a lot of research that's going on and obviously.

They become places where adversaries would try to target, to try to deceive and provide some, some deception or you know, make you not be able to rely and trust what, whatever the algorithm is reporting to you. So I think, you know, a lot of, a lot of vendors have started to, to use machine learning. But one of the biggest problems I see is, you know, a lot of that is locked into the proprietary platform that the vendor has. You know, I would like to see a way to break the glass and within these proprietary platforms so that we can use data from different desperate places and bring better context to what we're trying to do around bug detection. Because one thing you believe our adversaries are using some form of data science, whether it's AI or machine learning, to hunt for bugs in our software. So if, you know, we need to be able to match that and start using it in a defensive way, but in our operational environments to, to find things, to be more proactive at finding things and fixing things at a very, very rapid pace. Because what we have been seeing is that although the window of exposure seems to be sliding to the right, we've noticed that the time to exploit is shrinking. And if we can be more proactive and leverage some of these forward leaning approaches to look for things or hunt for things or discover things within our environment. I think we'd be in a better position to kind of shrink that window to a certain extent.

So Kevin, your experience how much or how many of these exploits are something that could have been avoided? Like how many of them like oops top 10 if you just follow that 90% of the issues we've had with security would have been resolved. Or is it more devious than that that it's always something new or something different that you can't really plan ahead for like that.

So I think some of it's bad. I think is know if you look at The OS top 10, I think the top, the top three or four has been within the top three or four for the last 10 years or however long the OS 10 been out. So secret injection, quarsite scripting, you know, those have been like on the top top three for as far as I, I can remember when os top 10 has come out. So what that says is that either the defensive approaches to, to avoiding SQL injection cross site scripting is really hard or there's just negligence, negligence in software development and people are just not doing the basic things in terms of how they are developing these techniques and capabilities when they roll out, roll out these web applications. So for so on. So I think part of is that but then I think part of it is I'm not sure tools are good enough and we rely on tools. I think a lot of times we there's an over reliance on tools and because the tools are not sound and precise they miss a lot of things. Right? There's residual risk using these tools. So we use these tools. The tools don't find them, but there are issues in your code, but the tool just can't find them. But if the tool doesn't report it then you think the tool that you think there's no particular issue and typically software gets released into production and they're saying, you know, there's a breach associated with some type of, you know, issue that was discovered through, through you know, a you know, reconnaissance or some type of pen testing that an adversary or something was trying to do. So I think you know, if we can improve the tools and also there's the training aspect of it as well and just really trying to move and shift security further left as I talked about initially with the requirements and design and really try to do threat modeling early on. So as new features and functionalities are being discovered and conceptualized we can we can model threat to those features of functionality to really understand ways in which those, those features of functionality can be attacked, then we can understand the defensive tactics that we need to include in our coding practices to mitigate those issues. So if we can do that, I think we'll be a good sheet. But I'm not so sure that fundamentally people are doing that as part of software development. I think there are some who are doing it, but by and large I think we are falling behind. And that's one of the things I think we definitely need to improve since software is so pervasive and.

So essential to everything that we're doing today in this world.

I agree. It's getting even scarier with these Alexa apps and smartphones and smart TVs and everything listening now and all this data being collected. So it seems like a lot of different scenarios that can occur now that you can't even really anticipate with Iot and everything.

Well, the software is probably smart. It's just that the people who are configuring and implementing design are dumb.

We're not learning from the things that we should have learned from like hard coded passwords. Why are we still seeing or seeing exploits associated with hard coded passwords? This is something that's like low hanging fruit, like security secure development 101. Or I would call it 100. Forget 101. Right. These are things that we're still seeing and we should be far removed from that. And we should figure out a way to not hard code passwords into software systems. Right? So it's some of those fundamental challenges that becoming our Achilles heel. I interviewed Dr. Diane Burley of George Washington University and she was on my podcast. We talked about how people resist change and people become Achilles heel in the software engineering process. So as we starting to see, like we shouldn't be seeing hard coded passwords in systems of any sort, Right. So I think that's one of the elements that we need to, we need to work on. People become, become a roadblock in moving things forward and they become, become dangerous in our own security because they're not, they're resistant to change and they're not, you know, by and large doing the right things to ensure that we develop these good practices and we developing good systems that people can trust and people can rely on that they won't, you know, for instance, evade your privacy or provide a backdoor or easily low hanging fruit that attackers can go after and have had some success in compromising the system. So we got to get Away from people being accused here in software engineering, that's becoming a fundamental problem that we're seeing.

I know you said it's not about tools, but there are tools I think that you've helped create or you help promote. And one of them was the, I think it was automated pen testing on demand OWASP Code Pulse. So can you just tell me a little bit more about the OWASP Code Pulse?

So there's a company that.

When I came to dhs, they were part of a broad agency announcement. They were providing analytics and visualization around software issues. And the company is called Secure Decisions. And if you haven't been checking the news, Secure Decisions just I believe was awarded investment funding from Data Tribe. So they was able to raise funds. So that's reason I bring that up. That's a success story from government funding research that I was very instrumental in provided some good oversight over. Part of what they built was a research idea that I came came up with called Hybrid analysis Mapping, AKA ham. Essentially it was based off my operational background in supporting IV and V pen testing, software assurance and trying to figure out a way to bridge different testing methodology like static analysis with dynamic analysis so we get better tool coverage. So hybrid analysis was bringing static and dynamic analysis together and that was commercialized and Secure Decisions Code DX platform. Also they were successful in developing something called Code Pulse which provided dynamic traces tracing around code issues that that can be found in Java software. So they've been very successful and I'm very proud that you know, I was able to work with them to really take, take research across the valley of death and get it commercialized. And now Security Decision is on its way to move into Maryland because they got the investment funding they got to open a headquarters in Maryland. And I think that's good. A lot of times people don't really see the investment that the government makes and how government research really have broader adoption. And people need to know that taxpayer dollars are going to a good cause. And this is one of these examples where government funded research has been successful and now it's commercializing people are using in their environments from banking, government. I know security citizens have all types of clients that they have. So I think that's a good success story.

Cool. So you've mentioned Swamp Ham and in one of your other sessions you talked about Stamp. So what, what is Stamp?

Oh man, Stamp. I forgot eggs, right? We got ham. I forgot eggs, right. Somebody said that to me.

Stamp. Wow. I mean, you know, I could, I, you know, I remember, you know, Watching.

Very vividly. I remember watching HGTV with my wife. And I'm not sure you're familiar with the two property brothers. You got one brother who find neglected homes and you have another brother who refused money to renovate and bring those homes up. The idea hit me, I was like, wow, that's what I want to do with static analysis. I want to find neglected open source static analysis tools and take money and a fuse to innovate them and modernize them. Because we are suffering from what I call a lack of good tools that are affordable for people to use. Right? The goal was really to incentivize people to do software assurance early on in software development process and lower the bar. So this became a project of mine. So I named it Static Tool Analysis Modernization Project. And it was really looking for neglected open source projects that had value in terms of static analysis, that value. And the goal is, you know, do a couple things. One, figure out what the tools can and cannot do in terms of strengths and weaknesses. Let's make the strengths better, right? And let's focus a subset on the weaknesses and use that as a modernization strategy to modernize tools around the areas that they were weak in. And the goal is not to create an uber tool, but I think if we can get tools who are good at something, let's not make, let's make them better at it. Let's increase that at least two, three times, right? In terms of its detection rate, its coverage rate, the fidelity in the result, let's try to increase that the best we can. Because we're using multiple, we're seeing people now using multiple tools as part of their testing pipeline. You'd be talking from a DevSecOps perspective, but stamp was really that let's figure out how to evaluate the tools, figure out what they're good at, what they're not good at. That becomes our modernization framework. Let's modernize around those key areas. And the other piece, the last piece of it was to really create a consumer report that guide people to select tools based on what the tool is really good at. So a lot of times people don't have an idea what the tool is good at and they, they buy a tool and the tool doesn't really meet or match their needs that they have for their software assurance. But if we have labels that we can put on these tools and say these tools are really good at these weakness classes, these programming languages, I think people could be more, more intelligent about what tools they use as part of software assurance and software testing. Grammar Tech won the down select and they've been developing that. I haven't gotten an update regarding how it's going, but I'm assuming it's going well and hopefully you should see something. I would advise people to go to grammar tech.com and figure out where that technology is and see if it's available and start using it. Because, you know, having the ability to use open source tools in conjunction with your investment, commercial tools to me provide the best of both worlds and it really allows you to get tools and developers who are doing a lot of development for you at a very low cost so that you can form a lot of software assurance in your organization.

Okay, Kevin, before we go, is there one piece of actionable advice you can give someone to help improve their security testing efforts and let us know the best way to find or contact you.

So one piece of advice I would like to give folks in terms of how we are building and designing and developing systems is really develop the mindset of what it means to shift left right and shift left. We have to move way past continuing integration, all the way into acquisition. And while many consider shift left as a catchy phrase, I believe it's a mindset that emphasizes the need to think about security in all phases of a software development life cycle. So we are working with acquisitions to get the right language into contracts. So when awards are made, we're getting good suppliers who can develop or have the track record of developing good systems that have quality and security as part of it. Right. We are building the requirements and turn those requirements into good design. And we're taking the design and implementing design correctly in code and we have tools that we can model to help us look for those issues that matters the most. Right. And what that does is as people want to deliver software at speed, this is the way to help do that and help not clog up the pipeline where people won't even test their software. But this is an incentive to really get people to think about security at all phases and mainly early in the software development life cycle. So shifting left has to be, or has to evolve, evolve into something more than just a catchy phrase. It really needs to be the mindset that, that the entire product team is thinking about security from the onset and we are thinking about ways in which software can be attacked and misused and abused. And if we do that, I think we can be on our way to trying to improve the overall hygiene and help from software that is powering every aspect of our lives. Right? Critical infrastructure, hospitals, medical, I mean, software is power in every aspect of our lives and automobiles, cars, you name it. And if we can do that and shift left with the right mindset, I think we can see some significant improvements in terms of the overall confidence in using software. You can find me at on LinkedIn @Kevin E Green J E N E and also you can find me on Twitter at I am Captorious S K E V T O R I O U S I am captorious thank you.

Kevin for your security testing awesomeness. For links to everything value we covered in this episode, hand on over to testguild.com S01 and while you're there, make sure to click on the Try It Today link under the Exclusive Sponsor section to learn all about why Fortify is the recognized market leader in application security. Check out their awesome security solution. So that's it for this episode of the Test Guild Security Testing Podcast. I'm Joe and my mission is to help you succeed with creating end to end full stack automation awesomeness.

As always, test everything and keep the good. Cheers.

Thanks for listening to the Test Guild Security Podcast. Head on over to testguild.com for full show notes, amazing blog articles and online testing conferences. Make sure to subscribe to join the Guild and continue your testing journey. This has been a Joe Calantonio production.