
CYBER24 · 2023-03-15 · 22 min
Key moments - from our scoring
Substance score
46 / 100
Five dimensions, 20 points each
Application security expert Laura Bell Main makes a compelling case for shifting AppSec from a peripheral security function into a core part of software development quality. Rather than treating security as a blocker imposed by security teams, Bell Main advocates for embedding security considerations throughout the entire SDLC - from design and architecture through deployment and maintenance. She emphasizes teaching developers high-level security concepts and patterns applicable across multiple languages and frameworks, rather than language-specific syntax rules that quickly become obsolete. SafeStack's approach includes threat modeling exercises during design phases, architectural security reviews for microservices and distributed systems, DevOps security practices, and supply chain security. Bell Main positions education as a critical enabler for smaller organizations to meet emerging US software liability requirements without massive budget increases. Her core message: develop teams are a "superpower" for security when properly trained and empowered, allowing a five-person security team to effectively scale to influence hundreds of developers.
Focus on leading indicators - evidence that security techniques and tools are applied consistently throughout the entire development lifecycle - rather than lagging indicators like incident counts or bug discoveries. Use free frameworks like OWASP SAMM and ASVS to measure maturity dynamically.
Education is the key enabler for smaller organizations to meet liability standards without massive budgets or large security teams; it allows small teams to become powerful in AppSec, preserving market diversity and enabling smaller players to compete fairly.
Teach high-level security patterns and design concepts - like how input flows through a system - rather than language-specific syntax rules; developers are already skilled at finding the right syntax for their language, but need guidance on security design patterns.
No-cost secure development training for up to 50 development team seats and 500 wider organizational seats for awareness and privacy training, with no credit card required or hidden upsells.
Security should be integrated from the design and idea phase through deployment and maintenance; threat modeling and business process attack planning can occur before any code is written.
Our reviewer’s read on each dimension, with quotes from the episode.
There are a handful of genuinely useful ideas - leading vs. lagging security indicators, teaching at the conceptual/pattern level rather than syntax, and the liability asymmetry for small vs. large companies - but they are surrounded by analogies, filler, and sponsor interruptions. Ideas are introduced and not drilled into.
we look at measuring the success of security in two phases. And first it starts with the ownership of the dev team... And then we have the maturity of this software development lifecycle itself
if every time you leave the house, you turn on the camera and you lock every single door and you do that every single day without fail, that's a leading indicator
The core argument - AppSec belongs inside dev teams, not beside them - is a well-established DevSecOps/shift-left thesis, not a contrarian insight. The angle on how US software liability disproportionately burdens smaller organisations is the freshest point, but even that is underdeveloped.
I don't think AppSec sits outside of development. I think the future of AppSec belongs to those building code. I think it's part of software quality
those are not good measures. Um, they are a historical view on what you've done before
Laura Bell Main is a legitimate practitioner - 20+ years coding, penetration testing, two O'Reilly-level books, and a founder/CEO role - which puts her well above pure thought-leader territory. However, her company is a training platform, creating an inherent promotional angle, and the interview never surfaces depth commensurate with her experience.
I've spent most of the last 20 something years... either building software in Langu, as glamorous as cobol, right the way through to our modern frameworks and then as a penetration tester and consultant
I'm the CO author of two books, um, Agile Application Security for O'Reilly and uh, Security for everyone
The only concrete references are OWASP SAMM and ASVS (useful and named correctly) and the free-tier seat numbers for SafeStack's own product. There are no client examples, no breach case studies, no cost or ROI data, and no published research cited to support any claims.
if you look up, um, owas. Sam. So the Software Assurance Maturity Model, which measures the maturity of your overall software development lifecycle, or the ASDs, the application security Verification Standard
you can have up to 50 seats for your development team and then up to 500 for your wider organization for awareness and privacy
The host's questions are topically coherent but uniformly soft - no claim is challenged, no number is interrogated, and follow-ups rarely push past the surface of what the guest just said. The 'one key message' wrap-up question is a textbook filler closer.
No one buys a car for the seat belts or the airbags, but we know they need to be there, right?
Yeah, uh, a lot of great information that you've shared with us today. I'm wondering if you could encapsulate it.
Computed from the transcript - who did the talking, and the words that came up most.
In this episode of the CYBER24 podcast, presented by VLCM, we discuss application security with Laura Bell Main, the founder and CEO of SafeStack. We discuss incentivizing security in software design and her belief that secure software is more than just the code developers write. Panelists Laura Bell Main, CEO of Safestack
Transcribed and scored by The B2B Podcast Index.
Speaker A: Cyber24 is presented by our friends at Valcom. Valcom is a Utah based IT solutions and services provider with a drive for getting it right. From ironclad security to computing and beyond, Valcom's 35 plus years means they have the experience and the expertise to help your business from desktop to the data center. Check them out@blcm.com. And welcome to the Cyber24 podcast, the weekly pod dedicated to helping business and governmental leaders better understand the often intimidating topic of cybersecurity so you can make better decisions to keep your organization safe. I'm Marty Carpenter of Northbound Strategy where we put thought leadership into action. And today's thought leader is Laura Bell Main. She is the founder and CEO of SafeStack, a published author and a regular conference and keynote speaker. We're going to talk to her about primarily AppSec application security and how that fits into the landscape today. How, how we can incentivize teams to build security into their software from design and a whole lot more. Great conversation with Laura Bellmain. I hope you enjoy. Okay, Lara Bell, thanks so much for
Speaker B: taking some time to join us from the other side of the planet. Uh, in New Zealand. That's uh, I was trying to figure out, as I mentioned earlier, whether you're the closest or whether you're the farthest or just the second farthest guest we've had. Depends on how far away New Zealand is compared to South Africa.
Speaker C: Absolutely. And I think we're probably, you know, the, definitely the smallest island in the middle of nowhere that you've had and the one with the most hobbits.
Speaker B: So that is probably true in both cases. I would just go ahead and grant you that status as you win both of those Categories. For the Cyber24 podcast I will update my LinkedIn.
Speaker A: Well, tell us Laura, a little bit
Speaker B: about yourself, your professional background and tell us a little bit about safestack to start so our audience can get to know you.
Speaker C: Awesome. So um, I'm an AppSec specialist. Um, I've spent most of the last 20 something years. I don't admit the number because it makes me feel old. Uh, either building software in Langu, as glamorous as cobol, right the way through to our modern frameworks and then as a penetration tester and consultant. And I specialize particularly in helping very fast paced dev teams put security through what they're doing without getting in the way of the innovation of what we actually want to build. Um, I'm the CO author of two books, um, Agile Application Security for O'Reilly and uh, Security for everyone, uh, by Holloway and my company SafeStack, we're on a bit of a mission. We want to make sure that every dev team in the world, so big or small, rich or poor, has the skills they need to do security. We're trying to create the team of 30 million security minded software developers.
Speaker B: Just a nice little easy goal. 30 million, absolutely.
Speaker C: Next week I'm taking a world piece.
Speaker B: Yeah. So just as an aside for this, you've written a lot of code and you've written books, uh, which was easier
Speaker C: to write, uh, in all honesty, code. I love the achievement of writing books and the ability to share what you do in a way that doesn't require consultancy and heavy fees. But every time I write a book I promise myself I will never, ever, ever do that again. Um, so yeah, there's something to be said in that statement.
Speaker B: So I really like that mission to provide development teams of any size, shape, uh, funding level, the tools that they need with uh, a wide range of software solutions and deep tech and development today. How does something like application security fit into that landscape?
Speaker C: I think uh, while as unsexy as AppSec can seem, especially if you know you're focusing your life on building an AI doctor or self driving cars or taking people to Mars, or just the latest wave of insurance software, whatever it is, that's your jam. Security is always going to seem like the sexy, unsexy, non fun part of all of this. But for me security is what's going to help us go really, really fast and do these things. Because we can't just build this new technology, we have to do it safely. We have to protect our people, our uh, data, our systems and using security rather than as a blocker to doing big things, but actually as a refining process to say, well I want to do this amazing thing, how do I do this safely? Gives us this mechanism to actually simplify our design sometimes just to have the extra pause and moment to say, how do I build this? Well and for me, um, I'm a little unusual in the app 6 space. I don't think AppSec sits outside of development. I think the future of AppSec belongs to those building code. I think it's part of software quality. Just the same way that performance and scaling, usability, accessibility, observability, those are all things that our engineering teams take care of every single day. All we're doing is we're adding another thing into their world. So I think, you know, people like us who we sit on the periphery and support our job in some respects, is to finally give the teams what they need to own this themselves and then get the heck out of their way.
Speaker B: Yeah, you mentioned, or you use the term a couple times there, uh, unsexy. It makes you think. No one buys a car for the seat belts or the airbags, but we know they need to be there, right?
Speaker C: Exactly. Um, and the world is full of unsexy problems we have to solve and we don't like doing them. Um, it's human nature. We want to chase the shiny thing. We want to do, you know, the next innovative thing. Um, we don't want to tidy up the house, we don't want to, you know, sort the recycling out, but they have to be done. And so this, I love this space. I absolutely am amazed by what technology is doing right now. I think it's an incredibly exciting time for engineering, particularly where engine is in that digital space. And so I won't ever build my own digital cathedral. That's not my path. But if, uh, security can help all of these people build theirs a little bit more safely so that they last a bit longer and people don't get hurt, then that's a really great thing.
Speaker B: So what have you learned about how we can incentivize teams to build security into their software from the design phase?
Speaker C: Yeah, I think this is something, you know, myself included, we've done wrong for a very long time. Um, you know, historically we'd come to our team of security people and we say, hey, I found you a tool and I'm going to put this tool in your world. Here you go. Take my magic box. And some of these magic boxes do really great things. But whenever you give somebody who already has a very busy world something else to do without respecting what they're already doing or the impact that that box has on their world, then you're always going to have a, ah, disconnect. For us, we look at measuring the success of security in two phases. And first it starts with the ownership of the dev team. So we have the things that are built into the products of product security maturity. If I build a product with X feature, do I consider the standard security requirements for it? So it's all about the AS built system. And then we have the maturity of this software development lifecycle itself. So rather than saying, hey, you're building this software here, we're looking at whatever software you build using this pipeline with this team, if you apply these stages, whatever the software comes out is going to be secure. So it's kind of like saying, I'm going to secure my production line, my factory, not just the car that's coming out the other end. And I think when we take those kind of frames, we can see that it's really not about the lines of code we write, but about the entire process end to end and the outcome. And I think historically we focused way too hard on the outcome only and uh, not the entire piece.
Speaker B: Yeah, you mentioned right there that uh, this, this position you have that secure software is more than just the code we write. Can you maybe tell us a little bit more about what you mean by that and what does it mean for secure development education?
Speaker C: Um, I started off as a COBOL developer. Um, I'm far too young to have been a COBOL developer, but that's a different story. And in my life I have been a professional level engineer in at least a dozen languages. And pretty typical, you know, our software development teams, they're no longer, you know, we write Java and that's what we do, or we write C Sharp and that's what we do. And we've always done that. If you look at their stacks, you look at their environments, they are dozens of languages, and not just dozens of languages, but different versions of the same language in some cases, or different configurations of libraries and frameworks and components. And so when we focus on the syntax, we're coming from a very limited perspective. We're saying, hey, in this language, at this version, this point, this is a syntax you write to stay safe. And this is a very narrow view. We actually then limit ourselves though. It's uh, very easy for an engineer to say, well, that's not relevant to me, um, that's not my language, that's not my framework, I don't do that. But if you instead talk about the high level frameworks and the patterns. So you're saying, hey, we're handling some input right now. This input has come from outside our organization or it's come from this place. We're going to do this with it and it's going to go store into this place and we start talking about the higher level concepts rather than the implementation details of the code. You can start having the same discussion about security, whatever it is built in. And that's an empowering thing. Our engineers are very good at finding what's the syntax I need for my language, my framework today. They do that every single day of the year. Um, but what they don't have the skill and practice in yet is understanding those design concepts of how we choose to build the software and how it impacts what syntax they're going to need.
Speaker B: Yeah. So how do you go about teaching that then? How do you implement that?
Speaker C: So we do it through the way we teach. So we bring everything up a level. Your software development life cycle, for those who aren't in the AppSec space, um, ah, it's a process and it doesn't matter whether you're agile or any of those buzzwords, just park that, you don't need it. They're just labels, they're really good for marketing. Um, whether you're going fast or slow, it starts with a design or an idea. You've probably got no code at all yet, goes through design phase to implementation or coding. You do some testing, deployment, and then eventually you look after this piece of software for however long it lives for. And that could be a very long time in some cases. What we try and find is for every stage of that life cycle, the considerations and steps you can take to put security through. So for example, if you've got an idea but you've not written anything yet, there are some amazing exercises that you can do where you're in the ugliest possible sense, mapping out, uh, what your system will be in its processes and flows and doing the modern equivalent of planning a bank robbery. You know, how would I attack this business process? Who would do this? Why would they do it? How would they do it? Uh, now this isn't about the deep tech. We're not here saying, hey, I'm going to exploit this vulnerability on this system. We're playing the same way we did when we were kids. We were very good at this as children, but we forget. So we're kind of bringing that back a little bit and making it okay to collaborate and talk about, hey, here's how I'd steal your wallet without actually doing the crime part. Then later on through the process, we mature m those out into architectural practices, so looking for common design patterns. So, uh, for us, for example, we have courses on securing microservice architectures and the thoughts and processes you have to get to when you construct software architectures of that type of. We also have practices that we can put through our DevOps lifecycle if you are a DevOps organization. Um, and if not, those same practices can be done in different lifecycles to do things like check for common vulnerabilities in the components you're using or to ensure that your build pipeline and your tooling is secure. Because as an attacker, I'm very lazy. And if your code's secure, then the next Thing I'm going to try and attack is your build pipeline or your hosting platform because I'm very motivation driven. It's not about your code, it's about whatever's shiny that I'm trying to get hold of. So those are just some examples. We're trying to make it fun, collaborative, inclusive of all roles in your team, not just one or two who happen to be super excited about security. And make it continuous so that we do a little bit of security all the time.
Speaker A: You've all seen the headlines. Everything. 39 seconds. There's a new attempted cyber attack in the US as the threat landscape becomes more complex, the need for security operations is greater than ever before. It's time to put experts in your corner. For something as important as your organization's security, having a named engineer and analyst paired with you is critical. Arctic Wolf is a leader in security operations, utilizing a cloud native security analytics platform to deliver security operations. As a concierge service, Arctic Wolf's security Operations center as a service is always on guard with security experts monitoring your environment 24. 7 Don't become the next headline. Learn more about Arctic Wolf's redefined cybersecurity approach at VLCmtech.com Arctic-wolf that's VLCmtech.com Arctic Wollf uh, listen CISOs, we know how hard it is to manage your security posture with often dozens of different security technologies that vary in process and application. Wouldn't it be nice if you had security baked into your actual server hardware? HPE's Gen 10 servers offer exactly that. As Utah's biggest HPE platinum partner, Valcom believes that your server infrastructure should be your strongest defense. Protect your enterprise with innovations in firmware protection, malware detection, and firmware recovery, right down to the silicone. Learn more about the servers that transform your business@vlcm.com gen10 that's vlcm.com gen10.
Speaker B: How can companies measure the success of their application security programs? How do they even go about that?
Speaker C: Yeah, I think so. Those who are listening at home, ah, just kind of mentally raise your hand if you like. Well, I measure it by the number of incidents we had. We had less incidents this week, so we're doing well. We found less bugs in the code. Those, those are not good measures. Um, they are a historical view on what you've done before. What we try to do is measure based on leading indicators. So a leading indicator in AppSec is some sort of evidence that you're applying the techniques and tools that you should be all the way through your process consistently. Now, if you do that consistently, then the chances are that there will be less vulnerabilities at the end. Now, uh, if you take this to the real world, if you're not an appsec person, this is the equivalent of saying, hey, I have a home and in my home I have a camera. Great. And I have locks on my doors. Wonderful. Now that in and of itself is not going to say whether your house is secure or not, because that's just you did a thing in the past, you install some things. But if every time you leave the house, you turn on the camera and you lock every single door and you do that every single day without fail, that's a leading indicator. The application of that process is an indicator that things are likely to be protected. So we look for leading indicators. Now there's two great open source frameworks people can check out if they want to look at how to measure these a little bit more dynamically. And, um, they're both part of the OWASP project, so the Open Web Application Security Project. So if you look up, um, owas. Sam. So the Software Assurance Maturity Model, which measures the maturity of your overall software development lifecycle, or the ASDs, the application security Verification Standard, that's how you can measure, uh, the security of your product as built. So if you bring those two together, there's a whole bunch of free tooling, no cost, no tricks that you can use to measure where you're at. Now look for those leading indicators and try and build those up over time.
Speaker B: Um, with the, uh, new USA cybersecurity strategy that's now been released, what role can you application security education play in in the age of this software security liability?
Speaker C: I think the US has done something very bold with its new strategy. I speak as somebody who doesn't live in the US but I'm watching it with a lot of interest because your new strategy essentially says that software manufacturers or the coders, people like me who build software, will be liable for the security of their software. And if it goes wrong, they're liable for the outcomes of that. Now, if you're a giant organization, you've got masses of money and huge budgets and loads of teams, that was probably quite a straightforward achievable goal. You know, it's likely to be more of a compliance thing, can I prove and communicate this than anything else? But our ecosystem isn't just built of big players. It's built of hundreds of thousands of organizations, big and small, who are, uh, innovating and building new things now, uh, those smaller organizations still need to meet these requirements, but may not have the resource to throw at it. So as they can't just build up a giant team, as they can't just buy lots of devices and magic boxes, education is a really great way to turn a small team into a really strong power for application security. So education is going to enable those small ones to still compete so that we don't end up with a market that is full of big players, because they're the only ones who can afford to meet that standard. So for us, we see that as a foundation, an enabler to stop the loss of diversity in our ecosystem by much needed regulation.
Speaker B: Yeah, uh, a lot of great information that you've shared with us today. I'm wondering if you could encapsulate it. If you said, hey, people listening to this, uh, podcast should leave with one key message. What would that message be?
Speaker C: If you have an AppSec team, if you have a dev team, they are an absolute superpower that you're not using yet. The future of security isn't your security team. They are going to be the best supporting cast you need, like they're superheroes on the side. But get it to the point where everyone who's building software, your testers, developers, analysts and architects, care about AppSec, that it's part of doing a good job, that it's part of being a good engineer. And by enabling them to do that, you go from having a team of, say, five security people to maybe having a team of 500. And if you can imagine the scale that we can achieve, where 500 people just do, say, an hour of security every two weeks, that's a lot of security that starts to happen. So rather than us staying separate and kind of doing our own thing and kind of looking in and trying to understand from the outside, I think the time has come for us to get really stuck in with our dev teams and start working together. Because if we're going to build this amazing technology as the future which we all desperately need, then we owe it to them to be at their side to help solve those problems.
Speaker B: Yeah, uh, Lara, great information. Uh, if people want to follow you online, uh, pick up any more pearls of wisdom from you or to, or to follow safestack, uh, let us know where we can go on the Internet to find that.
Speaker C: Um, you can find me in all of my normal human glory on the Twitters at ladynerd. Remember the underscore, because the other lady nerd doesn't do security. She doesn't Understand? You, uh, can find me on LinkedIn. And also one thing for your listeners. Um, as I said at the start, we're on a mission to build the team of 30 million security minded software developers. Now, to do that, Safestack, my company, um, we have a free plan. Now, as CEO, I get to say this absolutely honestly. No tricks, no gimmicks, no credit cards. This is not a weird side sell. We have a free plan. It gives you essential secure development training for your whole team. Um, you can have up to 50 seats for your development team and then up to 500 for your wider organization for awareness and privacy. Now, even if you've got no budget, even if you're having a really rough year and you're having to do layoffs and all the terrible things that are happening in 2023, seriously, 2023, stop it. Um, just come sign up to the free plan because it's not going to cost you anything. And maybe you could do something really great in a bad situation and turn your whole team into a little security army. Um, just when we need it the most.
Speaker B: Uh, excellent. Great stuff, Lara, uh, Bell from, uh, safestack and from New Zealand, uh, our first guest from New Zealand and, uh, I'd say the official appsec, uh, expert of the program based in New Zealand for our show.
Speaker C: Fabulous. I look forward to you endorsing me on LinkedIn for that one.
Speaker B: That's right. Lara, thanks so much for your time. I really appreciate it.
Speaker C: Thank you. Great to have you here.
Speaker A: That'll do it. For this episode, I, uh, want to thank our sponsors at Valcom. At Valcom, you get much more than a dedicated IT retailer. They become an extension of your IT team. Whether you're a startup or an enterprise, Valcom has the technical, sales and engineering expertise to make your business more effective and more productive. Check them out@vlcm.com that's vlcm.com special thanks as well to our supporting partners, the Utah Division of Technology Services, the Kem C. Gardner Policy Institute, the Utah Attorney General's Office, Utah Department of Public Safety, and our friends at Secuvant. A reminder, you can follow us on Twitter iber24 or you can hit us up on Facebook as well. We want to hear from you in either place to let us know what you think or if you have a topic you'd like to hear us discuss on a future episode. You can also rate and review the podcast on Apple Podcasts. We love those five star ratings. Thanks everyone. Have a great week and stay safe online.
Other episodes covering the same guests and topics, from across The B2B Podcast Index.