DevOps Cybersecurity 101 with Jason Mar-Tang

Get ready to discover some of the most actionable DevOps techniques and tooling, including performance and reliability for some of the world's smartest engineers. Hey, I'm Joe Colantonio, host of the DevOps Toolchain podcast and my goal is to help you create DevOps toolchain awesomeness. Hey, it's Joe and welcome to another episode of the test skill DevOps toolchain. Today I'm really excited because we don't have a lot of material on security and cyber attacks and cyber ops and all these type of cybersecurity within DevOps. So I'm really excited to have our guest join us today. Jason.

Hey, if your app is slow, it could be worse than an error. It could be frustrating. And one thing I've Learned over my 25 years in industry is that frustrated users don't last long. But since slow performance isn't sudden, it's hard for standard error monitoring tools to catch. That's why I think you should check out bugsnag in an all in one observability solution that has a way to automatically watch for these issues. Real user monitoring. It checks and reports real user performance data in real time so you can quickly identify lags. Plus you can get the context of where the lags are and how to fix them. Don't rely on frustrated user feedback, find out for yourself. Go to bugsnag.com and try it for free, no credit card required. Check it out, you can let me know what you think.

Really great to have you on the show. Hey Jason, welcome to the guild.

Joe, thanks so much for having me. Really appreciate it.

Awesome. I think before we get into it, maybe tell us a little bit more about yourself, more how you get into security.

Sure. I've been in the industry for about 15 years at this point and security was always interested me. As a kid I got fished by a friend and completely destroyed my machine. Yeah, he's like, check out this picture, man. It was like AOL days. And I was like okay. And it was just a trojan and just messed up my machine. And it always intrigued me that you could do bad things through mechanical means with computers. And as time elapsed, things just got more complex. More complex. So I had the opportunity when I was first got out of school after my first job to get into the role of sales engineering. And sales engineering is really focused on helping other companies solve security problems, in this case with tools. And as I've been doing that ever since, I've been doing it for, since then 15 years. So I've seen a lot of different industry verticals, a lot of different tools, a lot of different problems and a lot of different solutions too.

Love it. You know, I love that role because you speak, like you said, with a lot of people, a lot of different verticals. Are there any common themes you see, like people still get this wrong and you're kind of surprised by.

I think the first thing that comes to mind is that from a security perspective, it. You're playing a. It's like insurance, you're playing a what if game. And I think security teams have a hard time articulating, hey, this could happen, this could happen, we're at risk, we're at risk. But it hasn't happened yet. So everything seems cool and copacetic until something happens. And that's a common thread that I've seen throughout my whole career. And unfortunately it remains. Yeah.

All right, so, you know, you have, you know, experience convincing people then. So if someone's a developer and they're in the team, they're like, I think we should get security involved in our DevOps pipeline. What do they do to convince their, maybe their team or the management to say, yeah, we definitely need to invest in this.

So it's tough, actually. You know, I mean, what I've experienced with developers, you know, developers are there to get their job done, which is develop right and build. Build things. The problem is, is that when we look at cybersecurity, cybersecurity is focused on what you hear called the CIA triad, the confidentiality, the integrity and the availability of information. How it relates to developers and development in general is that when security is not kept in mind, and to be fair, development is one aspect. Security touches everything. It touches infrastructure, it touches identity, touches development and applications. And when it's not considered in the pipeline or in the process, you can leave things or. What I should say is it's almost like this. Like when you put on a suit, you tuck in your shirt, you make sure everything looks good and is tight. It's almost like I put on the suit but, you know, my tie is crooked or. And it's not a huge deal, but it can become a big deal if not look correctly. What do I mean by that? Talking about exposed API keys or secrets that we just are saying, ah, it's not a big deal, I'm just developing. But if it makes it into production, attackers are going after this stuff because the development side is one portion of a larger attack kill chain that we call in the industry and security becomes everybody's responsibility. At the end of the day, all the teams I mentioned, including development and keeping that in mind, can go a long way.

So I guess maybe that's not part of the problem. But because you said it touches everything, development, apps, infrastructure. Does anyone know that they're responsible for it? Then? Is it just like this? We have a security team then that handles it. It's out of my hands.

Well, that's the thing. That's where the security team. It's always funny because I've seen so many different organizations, security is often seen more of a hindrance. And there's a very fine line between convenience being, you know, I want to be super secure, but if you're too secure, the business won't be able to operate. But if you don't put any security controls or processes in, then the risk is very high. So you have to get to a middle ground. And that is the job of the security team, is finding that middle ground. It's all about risk and risk acceptance. How much risk are we able to accept and to make sure that the business can continue? So here's an example, right? Developers typically have a lot of privilege and need local admin rights or whatever to do what they need to do. But guess what? That makes developers the target. Like developers are going to because of the privilege and the power that they have. They're going to go after developers because they know that they have access to certain things or certain code repositories or certain privilege to say, hey, you know what Joe does? Xyz, I'm going to send a phishing email to Joe. I'm going to see if I can compromise Joe's credentials because with his identity and the attackers can be you and then they can get around and do things as you.

So, yeah, I mean, that's a great point. Like a phishing email. It's. How do you, like, you can't really develop for a phishing email. It seems like a lot of the attacks are like not necessarily hard technology focus, it's more like social engineering. And so you may have, maybe you have great security, but like you said, you're targeting a developer that's a little gullible and that's clicking on a phishing email. So, I mean, how do you even fight that?

Yeah, there's a lot of thoughts on this. I've had some, you know, CISOs say, you know, we don't do phishing tests anymore because we know they're going to fail because, you know, in a. I've been part of a breach where you had 30,000 employees. All it takes is one email and then, you know the way an attack propagates is you get a beachhead and then you move laterally, you main persistent. So all it takes is one. So Ria, and I'm not saying education is very important. This is why understanding, that's why I say it's everyone's responsibility. Because just knowing that I have power and my identity actually means something to the attacker. It might make me think twice before I click on that link. Right. So I think education's very important. You don't really train for other than, like I tell my family, never click links. Don't click links on. Never give your information over the phone. Right. Authenticate, make sure you know who you're speaking to. Like that stuff matters. It can go a long way because that can be the difference between an attack starting or not.

Absolutely. So you did mention, you know, secrets being leaked out, especially with developers sharing things to like GitHub and these code repositories that are more open to people. So how then can developers get involved with security and try to bake it in to what they're doing? Do they do it as the development or do they wait till after everything's done and they're like, okay, let's put it in our pipeline. When we check and code it, it does a scan or something.

It's usually working in conjunction with teams, so the security team. And it does determine, of course, on the organization you're working for. Typically the security team will want to get involved if they understand that there's risk and it becomes a matter of, hey, they're going to run maybe an audit throughout the pipeline to make sure that again, secrets aren't just hanging out there. So hopefully you'll catch it before it even rolls into production. If it's in production, it's like hopefully it's found at that point. And this is why continuous testing and auditing is very important, I guess to your question was how do you, how could the team think about it beforehand? And it really is doing little things like that. Like if you know that access is always key. Pun wasn't intended, but yeah.

But it is key, right? Because you can't get anywhere without the right access and you need keys to do that. So whether it's API keys, secrets, SSH keys, or just your simple identity, making sure those aren't out there are really important. And you'd want to make sure, for example, you're using, of course, the standard. Like if you're in the Cloud, you want to be making sure you're using some type of secrets manager for sure. And that might also be coming down from a policy from the security team. Hey, if you're going to do this, use this tool, make sure so that what they can do is just keep in mind that it's important, it is part of their responsibility and work with the security team. Believe me, they're not there to make your lives harder there to help the business may seem that way, but I promise you, they're not.

Yeah, I mean, that's a good point. I do speak with developers that once security gets into the pipeline though, they start getting all these alerts and it slows them down. Like you mentioned earlier, and then you said they should be focusing on risk. But like, how do you mitigate then when you have like a hundred maybe alerts saying security issue, security issue, how do you know what's a real, what's the highest thing that they should attack to make sure that they're addressing it?

Well, prioritization is always the name of the game with anything. And this is where shifting into the attacker's mindset, as opposed to a defender's mindset, will help with prioritization. Because when we look at how attacks are propagated, the attack kill chain, the intrusion kill chain, the attack lifecycle, whichever always comes up. And it's never just one thing, it's always a series of subsets that happen. A, then B, then C, then D, then E. It's conditional. It's if, then statements. Right. If this and then that, if this and then that. So if we can start it earlier or mitigate risk earlier in the life cycle, the rest of the lifecycle cannot come to pass. And that's how you can prioritize. And the only way you understand that is by running risk assessments, doing red team exercises, that sort of thing.

So, Jason, you mentioned a few terms here. I just want to make sure people know what it is, especially as a developer.

Sure.

Just mentioned blue team.

Sure.

What is a blue team? What's a red team? Just set the stage for us. What you meant by that.

Yeah, Happy. So blue team refers to defensive team. So we're talking people on the security team. They may be working in the soc, the Security Operations center, and then like, you know, the SOC Security Operations Center. Their main goal is to triage security events and security incidents and what happens accordingly. So it's all defending, defending, defending, defending. The red team is actually attacking, attacking your own network and running these exercises with the lens of the attacker. To validate whether or not there's risk and validate whether the controls and processes that are in place are actually working as expected. And the conjoined efforts of both blue teams and red teams. Right, the offensive side and the defensive side is where this new term purple teaming comes up. Purple team is not a team. It's more referring to the efforts that both the blue and the red team, when they come together. What you get when teams are working together. Because like I mentioned earlier at the top of our conversation, security is a joint effort. It's not one person responsibility. It's not like, hey, I'm developing this piece of the application and that's my job. No, security ends up becoming. Because it's so complex and it touches so many things, you need a coordinated effort between folks. So the purple teaming mindset is defenders on the blue team, attackers on the red team working together to overall increase the security posture of the organization.

Awesome. So, you know, with that in mind, you did also mention you need to take into the mindset of the attacker. Should each different company then have a certain profile? Like, why do people get attacked? I mean, I guess, is it just malicious? Is it like if I'm an insurance company, I know they're trying to get this from a health care company, they're trying to get that. Or is it just like general, here are the common type of attacks or do I need to take into account what type of information my particular company has that may instigate an attack? I don't know if that makes sense.

Yes. Right. So here's what I'll say.

So it's multifaceted, right. So, and I hate the answer, it depends, but it really does. So for example, you're in healthcare, you're developing apps for a healthcare system. The nature of the business is going to be involved with personal identifiable information. PII and the people and the patients that you serve. If you're in retail, you might be developing an app that is allowing you to sell your product online. If you're in manufacturing, it might be something else. Right. Related to actual actually creating something. Now that being said, there's always information that we want to keep make sure that it's confidential so it's not being accessed by the wrong people that it's available. Meaning that I can access the application. Right. If things go offline, it's no longer available or that it's. The integrity is kept the same. So I joke about, I always make this joke that you can't tell. Right. I'm a short guy. I'm 5 4. If someone makes my file profile 6 4, they're messing with the integrity of my Persona right now. You asked a question. Does it matter? It does matter. Just because information, information might be critical to the business. So the common denominator throughout all of this is availability. This is where you see a lot of the ransomware attacks happening. Ransomware is indiscriminate to the industry. Doesn't matter if you're a casino, doesn't matter if you're in manufacturing, doesn't matter if you're in healthcare. If we lock out your systems, encrypt all your data, you cannot get anything done. And you have to pay money in order to get that back. And then they could do it again. So it's. That's really damaging. Like, that's probably like, in my opinion, like one of the worst case scenarios, because that could be, it could just mean doom for your business. But also right when we look at supply chain attacks, look about, you know, what happened with Solar Winds. Now you're developing an application and the application is used by thousands, millions of customers. You compromise the integrity of the application and the application gets rolled out. You've now compromised everyone downstream in your supply chain. So it doesn't always necessarily have to do with your business. Well, it does matter with your business, but it doesn't necessarily mean for you. You need to think about who are you serving? Are you serving somebody? Who are your customers? Who are the customers of the business? And that needs to come into consideration too. And typically this, these conversations are being held by the security team. It's not necessarily the developers, but again, they are part of the overall program. And this is why when the security team comes to you and say, we need you to do xyz, we need you to do this, it's this bigger picture strategic vision of mitigating all this bad stuff that could happen is what's driving their conversation.

Absolutely. So this might be another dumb question. And that is when you think of cyber attacks, you think of someone showing off or exposing someone. But I would think when I read things, a lot of times people didn't know they were hacked until like six months, a year after the fact. Because someone has an opening and they're somehow, I don't know, they're harvesting information and in the background and they're not being. How do you know you're attacked? I guess the main question.

Oh, man. Well, you're right that there's a lot of times you don't even know you're being Hacked, we call that dwell time. Dwell time is how long are attackers hanging out in the network. And if I'm an attacker, I want to maximize that. I don't want to, I want to stay under the radar because I want to gather as much information, as much reconnaissance about the network as possible. Because then I can, you know, if I know that if I can map things out, I can plan a larger scale attack. So for example, if I, if I cross the perimeter now, I'm in and I do research and I see the developers have access to this. So I compromise the developer. I move things here, I can move my malware everywhere, push the little red button, boom, encrypt everything. And now, haha, payday for me. So how do you know if you've been attacked? Well, that's one way of finding out. You turn on your machine and all your data is encrypted. By then it's way too late. So this is where security teams try and continuously monitor. And now we're seeing a move into the industry to be proactive with security. This is exactly why continuous testing, continuous security validation is becoming a new field and becoming so hot. Because if you can stop something before it even happens, you're being proactive about it. And if you know a gap, if you can identify the gap, it's better you find the gap than the attackers because the attacker is not going to tell you they're going to use the gap and they're going to continue to propagate. If you can patch that hole or patch that, fill that gap sooner rather than later. I mean, you know what it boils down to, Joe? An ounce of prevention is worth a pound of cure.

Absolutely.

So how do you know you're attacked? Bells and whistles. But we don't even want to get to that point. We don't want bells. Bells and whistles mean something's already happened. We're being reactive. Being reactive is tough. It's a losing game. You never ahead. Being proactive is much better. But I'm not saying it's easy. It is hard, absolutely.

I guess I also, I'm just thinking online, how many companies are actually being proactive and how many of these attacks are like completely avoidable? Because I think there are known vulnerabilities in certain software versions and they just need to upgrade and they're not being upgraded. What's the percentage of people if they just did. Here are the known attacks. If you just upgraded your software or whatever, you would avoid 80% of this.

That's hard to Say, I mean, I can't give you statistics, I'll tell you why. Because the things that you hear about in the news are just things that have been disclosed. I can't tell you how many times I've been involved with breaches or whatever where it never makes the news. No one discloses. Right. Unless they absolutely have to. And it's sometimes some type of regulatory requirement. Right. So, you know, PCI dictates if certain amount of accounts are compromised. You have to now let everybody know. Right. And we're going to see more and more of that. So if you could repeat your question. What was this? Was it what specifically how avoidable are.

Some of these attacks? Just because I know there's known, like you go to OWASP top 10 known exploits or there's known software versions that have known issues that you need to upgrade your software to, to avoid it.

Yeah. So it's interesting, right? Sometimes there's this gross negligence. You see a lot of that in the news. I'm not going to give examples. But sometimes it is close gross negligence where it's like, why didn't we just do basic security hygiene with things? And this could have been prevented. And that's what I mean, like little things. If you. Gross negligence to me is little things led to big problems. If you fix the little things, you could have avoided a lot of issues. You mentioned oas, which I completely agree with. And that ends up, you know, when we look at the attack surface is looking at the, the surface of applications. There's an element of that. So you want to make sure, again, basic hygiene that you're not exploitable to those things. But we also need to be aware of other things, not necessarily CVEs, common vulnerabilities and exposures. Right. You hear of CVE blank, blah, blah, blah, blah. Right. That's referring to a specific point vulnerability that might or may not be exploitable in your network. But there's also environmental vulnerabilities. And what do I mean by that? Misconfigurations, Right. Things like, you know, that can be leveraged to again cross the perimeter and start an attack. So again, it's being aware, if you're a developer, being aware of these issues, if, I mean, if your listeners are of the mindset that yeah, I want to do my part to keep the organization, that's great. Even that is going above and beyond because a lot of times folks just don't think it's their responsibility. They just, it's not my job. But there's, you know, you might have so much privilege and so much power. And, you know, with great power comes great responsibility. Right, so, absolutely.

So along those lines then, because like you said, the attack surface could be everywhere. What tooling do you think people need to have in place at a high level? Is it like one tool that could take care of all this for you, or do you have to have certain tools for your infrastructure, certain tools via developers, certain tools for production? I don't know the different types of.

I wish, Joe, I wish there was one tool, but if that was the case, nobody would be in business, right? I mean, if you ever walked around the trade show floor, it's sensory overload. I mean, I go to a lot of security conferences, black hat, rsa, et cetera. And it's just like there's vendors everywhere. And then the reality is, is because systems are very complex. I mean, I'm sure the audience knows that it's very complex when you're in technology. So there's never just one tool. It's security is a program, and the program should align to the needs of the business. Like I said, if you're in healthcare, retail, whichever, and it's protecting the business.

So.

Tip. There are typical tools that I always see that security team is using, and it's not really so much. I'll tell you where, again, where it crosses over, it crosses over into development with identity and access management, again, protection of those keys, as well as the testing of the applications throughout the process. So there are a lot of static application security testing, dynamic application security testing. That's going to be as an initiative and there are tools to help with that, to help speed up the process, because doing it manually is always hard. But when you use a tool, the tool's meant as a force multiplier to the 1, 2, or hopefully many more individuals on the security team to make sure that is happening in a quick amount of time. Remember, time is of the essence.

All right, so you probably get this all the time. Doesn't AI solve all this? I just have a large language model that knows cybersecurity and I've run into my system and it somehow knows all the vulnerabilities.

Yeah, I mean, so it's interesting. Here at Pantera, we leverage what we call like orchestration or orchestrator, meaning it's our product will look at infrastructure and run penetration tests on the infrastructure. And it's dynamic, meaning when a new clue comes in or like, hey, I found this SSH key. Where do I have access to now? I compromise this identity. Where Can I go now? Or you know, or you know this vulnerability on this server, what can I get? Remote code execution and then can I do X and I do it now? That's all of this. Automation can help, but you still. All it does is help. All it does is it's again, it's a force multiplier. It doesn't solve all the problems because who's going to make. Because at some point someone's gonna have to make a decision, right? Are we going to do X or are we going to do Y? And those decisions require humans. So you can get to that crossroads quicker, but you're still there at that point. And then you have to decide, do I want to go this way or do I want to go that way? And if I go this way or that way, what are the implications of that? AI can maybe tell you. And then you have to actually do it. And then you get to the next crossroad and then you get to the next crossroad. So you're always hitting Roadblocks are not a good term. Crossroads is a better term because you need to make decisions on risk. That's what security ultimately is. It's risk mitigation. So AI will help you get to those decisions maybe a little bit faster. Automation will help you get to the decisions faster. It's great. But you still need teams to make decisions. Because think about it, if I need to. Do I need to go to this team? Well, maybe it's not black and white, maybe it's gray. And there's always gray. There's always gray area in security and in technology, there's always gray. So you need to talk about it and we need to figure out, okay, what is the best case, move forward. And that's where again, that balance comes. And the teams should hopefully be working with developers and the rest of the other teams to figure out what's the best case for the business and what's the best case to mitigate risk.

I don't know if you'll know this answer then if there is like an incident, like, do you know, like how to set up your team so they're able to respond effectively or quickly to a security breach. Or is it. Every culture is different, every team's different. How they approach a security breach.

Every culture and team is different. But usually their playbooks or like, you know, real mature organization will have playbooks on a process that they follow. And this is where, again, it depends on the. Sometimes they use. Businesses will use third parties. They have a third party looking at all level one incidents, and only if they can't solve that, then they'll escalate to level two. But typically it follows a process. And that's where you see security operations centers. They're the ones that usually responding to these quote unquote incidents that are happening when they come in, like, oh, we saw this alert comes in what level? And level one analysts are coming in. So you'll have a 247 SoC and you have people working the day shift, people working the night shift. So you always have someone monitoring and looking and looking. And then if there's an incident, things will then proceed and follow a procedure of when we get to this level, we have to escalate. When we get to this level, we have to escalate. Or if it's like, again, that I hate using this, but it's a truth, like we're locked out, maybe all hands on deck at that point.

Here's another random idea that came in my head. What happens if you have like a gun ho developer and they download like metasploit and they just run it against their systems? That could cause issues as well. I mean, do you see people afraid to do security from like a pen testing point of view because they're. Oh, yeah, you know, you get in trouble.

Yeah, big time. Yeah, of course. Because again, the A in the CIA triad, the availability is always so important. So we get that question a lot because again, we use automation when we run tests. And the questions we get is, how do we know you're not going to take anything offline? Joe, I don't think I've been in any conversation when I've been here for three years, I think I've been in one conversation where that doesn't come up. And for us, our perspective and what makes our software and what we're very proud of is the ability to actually run tests safely. What does that mean? That means we spend a lot of time engineering our solution to be safe. We reverse engineer code and rebuild it in our system. And the way we run exploits, we only include it if it's been tested and we know it's safe. So an example of this is developing exploits in user mode, as opposed to kernel mode. Kernel mode, you're going to cause kernel panics. We don't do that. If there's any chance of exploitation that will cause damage, we just don't include it in the tool. Now, as opposed to your use case, when you said, oh, I'm going to get metasploit, yeah, there can definitely be repercussions if you do the wrong thing, for sure. And that is when we think of traditional penetration testing, traditional red teaming, that is definitely a concern. And it's always been an issue and pushback. And for us, this is why, again, we're very proud of what we do and we try and work with security teams, say, look, you can do this, you can use automation, but we've done it safely. And that's, you know, again, what we push forward as our partner. And like, this is what you're getting with us, but it's definitely a concern.

Absolutely. Awesome. So, you know, it is kind of still near the new year. Do you have any trends or where you see the future of cybersecurity and DevOps going?

Yeah, I think the AI trend is going to get even more this year. Is it going to get me even more? I mean, last year was a big buzz and even when it started, we started to see reports of polymorphic malware, malware that actually was able to change based on just the, on the AI. And that makes things very difficult for security teams because it just means that more attackers are going to be leveraging more speed and security teams are always, like I said, catching up and trying to catch up and now they're moving even faster. So I think that's going to become, I think we're going to see more AI related attacks. I mean, it's an unfair bet to say we're going to see some major breaches, because of course we are. And I wish that wasn't the case. But to answer your question, when it comes to development, I think that we'll see a bigger push this year of getting the developers and those teams involved, because as we move more towards the cloud, we always are stepping more towards the cloud. More towards the cloud, and that's where a lot of developers will play. We need to be more proactive with that. So I think that this conversation is very timely because I think that most of the people or a lot of the people listening will at some point be involved with security and hopefully they'll come back to this conversation and say, you know what, I do want to be involved with this because I can actually contribute.

So, Jason, it sounds like you're doing a lot of cool things, especially with automated performance testing. And I think there's a phrase I saw on the website about continuous security testing. Talk a little bit more about automated security testing continuously, how that fits into DevOps. What's that all about?

Yeah, continuous security testing is really important because it allows the security team and the business just to be always be ready, always be ready. Are we ready for an attack? Are we ready? Because otherwise you're assuming and you don't want to assume. You want to validate. So continuous testing is always like, you know, I'm a martial arts practitioner, I'm going to drill and make sure I'm ready for a punch. I'm going to make sure I'm ready to be attacked by a tall person, small person, whichever. So if I'm always ready, I can be confident. And that's what we want. We want to instill confidence. We don't want to assume. So especially the continuous nature, whether it's within the DevOps pipeline or just within the infrastructure itself, allows the business to be confident and communicate clearly that our posture is in a good and ready situation. You asked earlier about the processes of responding to an attack when you continuously security test your security team, whether it's a SOC security operations center, they're always ready and you know that they're going to follow the escalation procedure as it's expected to. You don't want to wait, you don't want to assume. That's the value.

Great advice. Okay Jason, before we go, is there one piece of actual advice you can give to someone to help them with the DevOps security efforts? And what's the best way to find contact or even learn more about Pantera?

I would say guard your identity with your life because again, your they will always go after you, even if it's just to get to the next step. So protecting your identity, making sure that you're not giving any information knowingly will go a very long way. If you want to find me, I'm on LinkedIn. Jason Martang Love to have a chat about security. I can talk about security forever. And if you want to learn about Pantera, you can find us at Pantera. That's P E N T R A IO sounds like the band. But we're not the band, we're pena.

Remember, latency is the silent killer of your app. Don't rely on frustrated user feedback. You can know exactly what's happening and how to fix it with bug snag from SmartBear. See it for yourself. Go to Bugsnag.com and try for free. No credit card required. Check it out, let me know what you think.

And for links of everything of value we covered in this DevOps toolchain show, head on over to testguild.com P139 and while you're there, make sure to click on the SmartBear link and learn all about SmartBear's awesome solutions to give you the visibility you need to deliver great software. That's smartbear.com so that's it for this episode of the DevOps Toolchain Show. I'm Joe. My mission is to help you succeed creating end to end full stack DevOps toolchain awesomeness. As always, thanks. If you're not already part of our awesome community of 27,000 of the smartest testers, DevOps and automation professionals in the world, we'd love to have you join the fam@testguild.com and if you're in the DevOps automation software testing space, or you're a test tool provider and want to offer real world value that can improve the skills or solve a problem for the Guild community, I'd love to hear from you. Head ON over to testguild.info and let's make it happen.