API Security – Steve Boone, Checkermarx

This is texturing TV. Hey, everyone. Thanks for joining us here on another tech strong TV interview.

I'm really happy to welcome back to our show my friend Steve Boone. If you don't know Steve, he's with check marks and Steve's pleasure to have you on again. Hope all is well with you.

Everything's going great Allen. Thank you so much for the opportunity. All right Steve for those households where you're not.

You know a household name. Why don't you give them a little why don't you give our audience a little bit of your background and you while you're at it you might as well give them the check mark story, I guess. Yeah.

Absolutely. Absolutely. No.

Yes, I started back probably with you a little while, you know, probably at this point what feels like decade ago when we were really cruising the devops market, you know, focus on helping Enterprises really automate continuous integration continues delivery, which got me into security and in pretty heavily and so, you know moved on over to join forces with check marks and since then we've been really focusing on help and developers really pay more attention to how they can be more security minded and bring security Focus solutions to them. I mean, that's the classic defect cops tail right now like it right it's good. Yeah, absolutely.

And of course check marks look check marks has been around now. Geez, I'm gonna guess it's probably closer to 12 years. Yeah, you're right on that.

I think we were founded in 2006. I want to say so here. It's cruising along.

And transformed a lot we went from you know as essentially a SAS company to really transforming ourselves into a platform player, you know where we've got, you know a number of different points Solutions now where the idea being you can you know single click and scan across multiple engines. Yep, I mean look originally, you know. Well it and I mean the state of Art and Abstract back then was fast and death right static and dynamic skins check mark, actually it's paved the way with several other, you know categories.

And as you said today offers a full range of of scanning and and security tools as they've expanded which I guess brings us to today's news. Yeah, right. That was my Segway as we call it in the business Steve.

Why don't why don't you share with our audience? It's a little bit about the news. Yeah, absolutely.

So hopefully you guys everyone made it back from black hat successfully and hopefully no worse for the Wares and you know, no nasty virus is to bring back home to the family. We had a really big announcement out there around API security. So we just formally launched our API security offering which, you know differentiated in a number of ways, but we're really again focused on helping developers put their organ.

Nations in their applications in a better a better what I'll call Api security posture right giving them visibility into all of the apis that they know about and really starting to be able to call out differences between documentation from what we see in the code what we might have formally documented and let's say a Swagger file and shedding light on some of those zombie and Shadow apis that we know are, you know causing a lot of chaos for a number of organizations? Absolutely, you know it's interesting that you mentioned, you know, we're helping developers with this because I mean the API security Market is a market. We've looked closely and covered closely a tech strong.

For as long as you know, we've seen API security companies and as you know Steve there there have been several. There are several startups that are solely focused on API security. That's all they do.

and and that's typical usually of an early market right where you'll get that and some may say well that's a feature not a product right and and eventually you know this gets Brought in either through acquisition or in the case like a check marks developing your own into a wider offering a platform whatever you want to call it. But really what we've seen is the question of who's the customer in API security. Is it the security person who obviously is concerned about security or is it the developer who oftentimes is making or building these API calls into their into the application?

Is it the Ops guy who has to run these applications and really doesn't have a map if you will or a nice bomb or something right of what apis are in there? And what what he's actually heading and in many ways, this is the classic deficit cops. But no, I mean you're exactly right.

There are a number of interested personas that all care about doing the right thing. But you know, I see it quite largely as who do we give the responsibility to to solve the problem. Right?

So many folks are involved in identifying and alerting and letting us know. Hey, we think troubles in town. But ultimately we give that that challenge back to development and we say look when you get either fix these right because at some point, you know, as a security operations guy, I can just disable the API and be like look, you know, that's problematic but we want to get that feature especially if it's valuable and point back up and running and that's gonna take a development cycle.

Right? What we've discovered is that you know, when we're talking with our clients large majority of them and it's 46% say that they have some formal process for documenting apis some and out of those the only like 30 some percent say that it's actually good coverage that they actually have a good Says and they can keep up with it. There's a lot of challenges even for companies that are capable of documenting these apis they fall out of sync with what's actually running in production and it's mostly because it's a challenging thing to go.

Do you know a lot of development teams now are solely assembled just to develop apis and just because you're good. Let's say web app developer and you know good security practices around coding for web apps. Those are different set of challenges when you're trying to do secure coding for apis.

So the skill sets aren't completely one-to-one and a lot of the you know, what I'll say, um Creative Solutions that are out there today our primarily focused and production. They're looking at analyzing your network traffic, right and they'll bring those findings back to you and say hey this looks like an attack on these apis. Do you think it's an attack you want to do something with this information and largely even if you were able to identify it as an attack?

How do you take that little bit of network traffic data that Have and then find the appropriate development team in your Global organization who can actually go and fix that and so there's a disconnect between some of the solutions are out there. And what I think is like that true devops feedback cycle of being able to bring these results shift. It left find the problems earlier in development so that you're not waiting in production to find out whether or not you're being attacked right to me.

There's this idea of API protection and then really API security like knowing and working in practicing the better coding skills to write and deliver more security apis, and that's largely where our focus is is providing that visibility. We're starting at the code. So when we're scanning code, we're able to bring you full breath of all apis.

And with that we can go and start talking about generating documentation or differences in documentation, but really help the developers know where the risks are and if you were trying to put a security program together to say hey we want Prioritize and enrich our apis in the security standpoint this data around what you have what's documented? What's internal? What's external?

It's extremely valuable. Yes, Steve. I'm listening to you here and I like what I hear.

because to me, this is now sort of Gen 2 for API sec. I I think the first generation of API security tools was based on the premise. You can't defend what you don't know.

Right, so they were very much about mapping out what apis you have right? At least. Let me give you a list of the API calls you're making.

And that that was better than what we had before right? So it's it's valuable. Now, it sounds like check marks is saying okay.

Here's the API that you have API calls you're making and now we're gonna start documenting. What apis these are what they do how they work. Are they configured?

What what calls they're making so that We can be smart about securing them. So it's not enough just to know they exist. But let me let me take you to the next step and tell you really a lot about them so that we can get smart about protecting them.

Yeah, that's exactly right, you know, and I think a lot of folks from you know, security operations team say look even if I just had an understanding of what the whole landscape of our apis looked like, right, that's a start. So you're back to your point that idea around visibility, you know. While we're also scanning code, we're looking for other things like to your point, you know SAS phone the abilities right other things that we can pull in and now all of a sudden we can make correlations to these things right?

Not only do we have these sets of apis, but we can put ultimately what we're driving towards is a risk assessment based on these NBA these apis right are they sharing sensitive data? If so, how much or what types do they have known, you know SAS vulnerabilities that we're finding associated in that same project that same code base. And so when we start to do that now we can make a case for why we should have better prioritization.

We want to lift up some of these findings because there's other things attached to them that we know about and I think that's helpful too. Right, you know at the end of the day developers, we're giving them all the responsibility for all of the stuff. And so if you want them to make good decisions around security, they're gonna have a limited amount of time to go and do that.

Where do you want them to focus that time and effort? Think the business overall knows what are the most valuable endpoints in their applications that they need to Monitor and secure and take care of I think a lot of times though when we are, you know, developing an innovating on applications. We're making a lot of changes, you know things that we intend to be internally apis when you test them, sometimes you make them external and those, you know, don't always go back and get patched up.

So as we start even seeing the evolution and kind of change of apis over time because we don't bring in new developers who may not be intimately familiar with how it was originally designed right all of that changes over time, and it's it's our kind of Duty to let people know when stuff change what's changing and how you can best protect yourself going forward. Excellent, Man Steve let's go to the business side of the house on this right for those who are familiar, you know check marks does have a SAS kind of scanning offering it as well as others. I know from talking to you and other check marks folks in the past a lot of times if you're in existing check marks customer and you have I guess it's the Enterprise or whatever the premium one a lot of these new offerings are actually rolled up into it as part of it.

They're just added in is that thing? You know, I don't want to put pressure on you but is that the case here is is it's 100% So earlier this year, you know, we had the big announcement of our check marks one platform, right? Which again right?

That's our SAS platformer. You've got all of our different engines that are a part of that and with the goal there being that we can start to aggregate data and correlate right? We also had this announcements around marks Fusion, which is our correlation and like that's where the beauty of having this all in one place really starts to Evidence because we can look at your SAS data next.

Let's say the data that we get from the API security engine or the data that we pull out of one of our other engines and now all of a sudden when we pull that together, we can start doing a couple of cool things right one. There's improved prioritization. We were kind of talking about that already.

I'm seeing multiple engines across different hits I can pull out that they didn't say. Hey this is more important and more more risky than other things. But you also get the things that a lot of SAS customers struggle with which is just around when you get a lot of false positives, how do you reduce those false positives and by you know, finding multiple hits across different engines we can say, hey we know for sure.

This is actually a thing right? This isn't a false positive. We're getting this finding several times and I think the really cool thing that it does if you have multiple engines today, especially across different vendors, you know, your gas solution might find let's say a sequel injection and so what you're fast, but now as a developer, I'm finding out about the same thing twice and there's a lot of redundanc There it's like I gotta go and did we already fix this?

I'm gonna keep track of it in multiple places. And so just an idea of that we can consolidate those findings and say hey look the SAS thing we found over here in the desk thing. We found over here.

Those are the same thing. And so you're not gonna have layers upon layers of, you know, just, you know thousands of vulnerabilities overwhelming your development team. And so that's the beauty of the platform and a whole is the being able to look across all that data.

And yes, that's exactly where if you were interested in, you know, learning about our API security scanning capabilities, you'd find that on our check marks one platform. Excellent and just to tie a bow on that if you people are interested in going to check out check marks one platform. com that c h e c k m a RX you got it.

Absolutely and you know fill out the reach out to me on social media or anywhere else too. We'd love to show folks around and answer any questions they might have All right. Hey Steve.

I love it. I like to see you know it look and let me just say a word. these vendors who have been out here, you know, they're kind of One trick ponies API SEC is what they do, and I don't mean that in a bad way.

Right these people kind of with the missionaries evangelizing the need for API sect, but when we see a company like check marks and we see some of the other larger companies recently that have you know, recognize this as a market as a problem. It's validation. right and and it takes the whole sometimes it takes the whole industry.

Yep. No, you know and that's really right. It's a very valid point in.

You know, we talk about some of these different more points Solutions. You know API security is gonna be a lot like application Security in a sense that it's kind of a patchwork quilt what I mean by that is it's not one size fit all you're gonna need a little bit of different types of solutions to really get full coverage in that area. And yeah, you know, you're gonna want some runtime protection you're gonna need a good API Gateway, but I think the thing that's largely overlooked and missing is this well, how do we get it fixed?

How do we make sure it doesn't happen again? I don't always want to be reactive. I want to be proactive about making apis more secure and I think that's where you know check marks has our our best opportunity today.

I agree with you man. All right. Hey, Steve.

We look forward to seeing you soon. Keep up the great work. Say hello to everyone a check marks.

Thanks for being our Tech strong TV. Thanks so much Alan. Appreciate it as always and hope to talk to you soon, right?

We're gonna take a break here on Tech struggle. We'll be right back.