Secure by Design – Josh Thorngren, ForAllSecure

This is techstrong tv. Hey everyone. Welcome back here to techstrong tv.

I am, I am almost as excited as this gentleman is excited to be on our show today. Let me introduce you to Josh Thoren. Josh is head of developer advocacy for All Secure, and it's a pleasure to have him on his first text on TV interview.

Hey, Josh, welcome. Hey, Alan, thanks for having me. I'm very excited to be here as well.

Appreciate you having me on today. Um, you know, it's, it's funny, I I have probably had at least a dozen of my team members on a techstrong TV show before where I've been pulling the strings beyond the scenes, so I'm just thrilled to be here, you know, on screen getting to chat with you, um, today. Ab Absolutely.

So moving out from behind the black curtain to center stage Where the lights are bright, They're Welcome. So Josh, you know, head of developer advocacy, we see a lot of these kinds of roles taking center stage, frankly, right? As we move from sort of a, it's called an enterprise sales model, where it was sales team salespeople talking to, you know, decision makers and stakeholders, you know, for most of my career in tech 30 plus years.

But now we, we see, you know, they've had a dev developer, advocates, evangelists, dere, these kinds of things, and people always ask us, how do, how does one get to become a developer advocacy person or a derel or ad you know, evangelist. Josh, why don't you share a little bit of your journey with us? Yeah.

You know, I'd love to. It's, I, I'll be honest, I was, you know, 15 years ago I was a developer and mm-hmm. I was, I was type developer that was okay at writing code, but loved understanding how all the pieces fit together and how applications and code could transform the world around us.

That led me into early DevOps roles where I helped architect pipelines and implement C I C D and make sure that we had closed loop monitoring, feeding back into bug tracking and tickets so that we were creating culture of reliability. That shifted some of that stuff left over time. I moved from roles where I did that in-house to consulting for companies that sold software or marketed software design target developers, DevOps professionals, security professionals in that shift left journey.

So I've had a career that's, you know, included managing Kubernetes clusters and also leading marketing teams at DevSecOps and application security companies. Nowadays, my role is largely around unlocking developers who, you know, to your point, any tool that fits in a development pipeline, the main users of it are the folks who day in and day out are writing, committing, and pushing code. And so if you have a product in that space, you're talking to developers every single day and you know, sometimes the developer teams don't have pocketbook, that doesn't matter because you want to put a smile on their face when they wake up and use your product.

And so that's what I try and do every single day, uh, here at or here. Love it. That's, and you know what, I appreciate the honesty and I appreciate the sharing of that journey.

I I think people in our audience will appreciate it as well. So for all secure, you right? I look, there's a lot of security companies, a lot of DevSecOps companies out here.

Uh, there's a lot of noise in the market. Tell, you know, let's cut through all that. Tell, tell our audience for all secure, what's it about For, for all Secure?

I, I'm really excited being part of this company. It's, uh, the way I described the company is we're a hacker organization. Our founders, um, cybersecurity professionals, cybersecurity professors, academics who do consulting work for, you know, three letter agencies on how do we push envelope both offensively and defensively with cyber.

And over the years for all, Secure's done a number of different things. Company's been around for a better part of a decade working in cybersecurity education and research over the past few years though, all of that work has really culminated in the development of a product called Mayhem, which is a, I tend to think about it as a start left application security instead of shift left. Um, okay, it works, it works the way developers do testing in every other aspect of writing code instead of like a security scanning tool that was just pushed into their pipelines.

And so mayhem runs thousands of testament to understand how a hacker would actually exploit an application in an A P i so that developers can actually focus on and fix the vulnerabilities that are linked to exploitations, not just run down the list of false positives or, well, it doesn't apply the way I deployed IT type issues that bogg bogged down teams today. Okay. Got it.

Um, and we, I want to, we're gonna talk today about shift left SPOs, all these things, but before we do, for people who want to, you know, dive in a little deeper on fur all secure url, like what's the right on-ramp here For Yeah. You know, folks want check us out. I'd say go to Mayhem Security, that's our product, and you can get started for free.

Takes just a few minutes to integrate it into your, um, I b e, your C I C D pipeline and start running tests. Beautiful. All right.

security, so we'll check that out. com almost 10 years ago now, and, um, actually it is 10 years ago. And, you know, one of the reasons I got into it is because my background's in security and I thought DevOps was such a great thing for us in the security space that it would give us a chance to kinda write some past wrongs.

And then, you know, we didn't call it DevSecOps then, right? But we started talking about security and DevOps started doing the RSA DevSecOps. We called it Rugged DevOps initially, in case you don't know.

But, um, eventually we settled on DevSecOps and this whole concept of shift left began to emerge rate of pushing security as well as other concepts, testing and stuff further left in the development life cycle. At the same time, we were also pushing more and more on our developer's plates. But, you know, I've never met a developer who raised his hand and says, I, I don't care about quality and I don't care if I have insecure code.

Right? So it's not a bad thing, but, um, we've made a lot of progress during these eight, nine years of doing that. Have we, have we made enough progress?

Do we need to go further left? Can we go further left? What's your take on this?

I think there's room for improvement. I think the progress has been astonishing to walk. I think when I talk to developers either who, you know, use mayhem today or just in my networks or in, in my world, there are two things that they struggle with, with shifting security left.

And one is getting the security tooling integrated in a seamless fashion to their workflows, be it plugged into the tools they use to write code, ship code, or just where does it fit in my day-to-day? That's one. The second piece is we pushed a lot of noise left to development teams and what used to be a running a, you know, SaaS scan in production now is blocking a deployment or a bill for a developer until they resolve certain issues.

We've pushed these quality gates and security results into the development world and said, deal with it. And I talked to a developer who runs, you know, a SaaS or an SCA report, they say, well, I get 200 results every single time I run something. I can't fix all of that, but I don't know where to start.

And if I make decisions about it, I have to go have a conversation with security about prioritization, which slows us both down. We want the same thing, but it's hard to get there. And so I think those are two of the challenges that I hear day in and day out from developers that shift left, brought to them.

And so I think resolving those is where we need to focus next. Fair enough. I agree that there is room for improvement, but I, I also, I, I hear, I hear in the, in our audience from developers who say, Hey, we can't put everything on our backs, right?

We, we saw several companies, Josh, who, you know, at, when this whole shift left movement really started catching, steam started, you know, their slogans were something along the lines of creating security for developers. And I think a lesson we've learned from that time period is, you know, what, developers want to develop secure code. They want to develop high quality code, but you know what they want to do.

You know, what developers like to do develop, they like to code. And when we, when we take them away from the task of coding to become QA people, security professionals, et cetera, it, it kind of, it's changing the very nature of who and what they are. They're not, we, I don't think we can expect our developers to become security professionals.

We, we can expect them to maybe become security champions. We can expect them to be security conscious, but they're never going to be security professionals. They're developers first and foremost.

Yeah. I, I totally agree with that. And I think this is where, this is why I really like the idea that, you know, you, you see this, you know, CSUs championing this a lot these days.

It's like secure by design. I think that's, you know, and you can say it's fluffy or just like, great, well what does that actually mean? But conceptually, what's secure by design really unlocks is it says from day zero, let's start talking about what security for any given application looks like and what are the risks?

What is the attack surface? What's acceptable to the business in terms of managing or mitigating those risks? And how do we development, security, business leadership align on that early on so that we can implement the right practices, do the right security testing and ship something that, to your point, developers can be happy with the quality, reliability, security of it, but it was built with intentionality to reach that goal instead of developers doing their best and then being told later, well, hang on, the scans we ran said that this is insecure.

Usually when I talk to developers and that happens, it's because there wasn't an upfront conversation on what the security standards for a given application, a given API should have been. And had that happened, had there been a more from the get-go secured by design approach, they wouldn't have run into those speed bumps later on in the process. And so I totally agree with you.

It's not, it's not about making the developers security experts, it's about planning security the same way you plan a product feature and treating security just like you would any other feature with a scope requirements and acceptance criteria. Fair, fair enough. You know, Josh, I think another, just when we were kind of normalizing this whole shift left and everything, we, this whole software supply chain security and then SBOs kind of exploded on the scene.

No, no pun intended. The yes bomb exploded, but, um, you know, the yes bombs exploded on the scene. What effect do you think this has had?

I think it's a blessing and a curse. Yeah. It, it is absolutely essential given the prevalence of third party components, open source software that anyone who is building and shipping applications knows the provenance of what they're shipping.

SBOs vital. I think part of the challenge with SBOs as they're leverage today and discuss today and use today an SBO is what's included in the code. It's not what's on the attack surface.

And so it's helpful from understanding a complete picture, but if you're really looking to actively manage, mitigate and PR risk and prevent, you know, attacks, you need to do more work with the sbo. And, you know, one of the things that I think I'm starting to hear more asks for is don't give me an sbo, give me the SBO of everything that's present at runtime. Give me what's present when my application's executing so I can focus on those and treating the SBO of, well, what's including the code more as a compliance or audit artifact versus a security artifact.

Yep. But, but never, I mean, look, the, the, one of the key pieces of the SBO values is, is third party dependencies and stuff like that, right? And, and so, you know, I think it is good to have the entire third party dependency tree mapped out there.

Um, But I think, I think in a nice way what you're trying to say is, is we can go down Alice's rabbit hole with that and wind up in Wonderland And yes. Business to be done. That that's exactly what I'm saying.

And it's, I think this is the cybersecurity challenge. Yeah. We, every cybersecurity vendor says, Hey, I'm gonna generate a bunch of data and help you make better decisions.

We need to give folks less data where every piece of information is actionable. Yeah. Let's go get business stuff.

Let club developers code. Yeah. No, and that's exactly what we were saying.

I mean, and, and that's always been, I mean, that's, look, I've been in security 25 plus years, the whole deens de desensitization deens, I always have a tough time with this word desensitizing issue, right? Yeah. Not only of developers, but ob security people themselves, right?

We used to be inundated with, you know, telephone books full of vulnerabilities and a constant stream of potential, you know, intrusions and so forth, and threats and alerts separating what's real from what's not, what's actionable from what's not important has, has always been, always been Always An issue. Anyway, alright. Yeah.

You know, Josh, I, I appreciate you coming on. We're about out of time. I don't, you know, what, for your first text drug TV man, you, you nailed it.

I thought you did great. Hey, Hey, I, I, I appreciate it. I, you know, I'm just getting, I get so fired up.

I could go for another hour, but, you know, very much enjoyed it, Alan. Appreciate the time. Great conversation.

Great to be on here finally. Not a problem. You know, I'd go for an hour with you, but our, our, our research shows people like, you know, 10 minutes done.

I, Hey, I, I tune out at nine. Yeah, I hear you babe. All righty.

Hey Josh, best of luck again for people want to get more about, uh, for all secure, it's mayhem security. Mayhem security. Yep.

Go check it out. Check it out. Get started for free.

All righty. We're gonna take a break here on Textron tv. We'll be right back in just a moment.