Hillel Solow -- How to do AppSec without a security team

0:00Chris RomeoHillel Salo is chairman of the board at ProtectOnce, where he helps guide product and security strategy. Hillel is a serial entrepreneur in the cybersecurity space, but his favorite thing is still writing code at 2:00 AM. Hillel joins us to talk about how to do AppSec without a security team. We explore the building blocks of an AppSec program, what AppSec looks like for companies of different sizes, from startup to midsize to enterprise, and then we dive into Hillel's most important advice for companies that can't afford a security person. We hope you enjoy this conversation with Hillel Salau.

0:37You are now listening to the Application Security Podcast, brought to you by Security Journey. When you finish this episode, check out our other show, High Five, to stay up to date with all the hot AppSec news.

0:48Chris RomeoHey folks, welcome to another episode of the Application Security Podcast. This is Chris Romeo. I am the Chief Security Officer at Security Journey, And I'm also joined by my good friend, Robert Hurlbut. Hey, Robert. Hey, Chris. Yeah, it's Robert, and Principal Application Security Architect at Acquia, and really glad to be here to talk about application security again. Yeah, it's a shocker that's somehow what we end up talking about, but the show is called The Application Security Podcast, so you kind of knew what you were going to get when you downloaded the episode. So, the topic that we have for today is talking about what is some important advice for companies that can't afford a security person. But we're going to lay some groundwork, some foundational items before we get to that particular topic. We're joined by Hillel. And Hillel, we always like to start with, what is your security origin story? So, help our audience understand, how did you get into this world of application security? from as far back as you want to go?

1:55Hillel SolowAwesome. Well, first, thanks for having me on, Chris. Always nice to talk to you guys. And yeah, AppSec is a passion, so I can talk all day. My background, I got into security. I was a junior developer, graduated college, looking for a job, and got a job at a company that was doing security. Learned all about cryptography, learned all about packets and encryption and transmitting data across the internet. From there, I sort of never looked back. So everything I've been doing has been about developing security products and trying to figure out what's the next way we can protect applications, organizations, content, whatever it is I was protecting. Most recently, I was at Cisco for a bunch of years, and we overlapped there and spent some time. And then I left Cisco, started a startup in cloud security. It seemed like a place nobody was doing anything, so why not do something in cloud security? And sold that off to Check Point a couple years back, spent some time there, and left Check Point a while back to start focusing on other startups, other projects, and sort of see where else I can be impactful and effective. And so, everything's been about security, whether it's organization, network, application, cloud, et cetera.

3:02Chris RomeoSo, when you were in that junior developer role, How did you make that jump? Were you in a development role and then somebody gave you an opportunity and kind of piqued your interest in security, or how did you— what was that flashpoint for you?

3:20Hillel SolowYeah, so there's a bunch of moments, but, you know, the first one was someone said, hey, we got to do some security things here. Let's go do them. And I had the instinct, I think, that every developer has, which is let me go write my own security, and learned the hard way for the first of several times, you know, the old don't roll your own crypto. So, you know, made a bunch of mistakes along the way and learned that security is a discipline. It's an engineering discipline. It's built, you know, layer by layer. And what you got to do is you have to look at all the layers that exist, see how you can use the things that exist, and then tie them together and then add your own little piece to it. And so, I had the opportunity to do that a couple of times, whether it was on the cutting edge of things, so things that didn't necessarily exist and we were trying to create, Or it was, you know, yeah, we just need to encrypt our data, or we need to transmit our data encrypted, or we need to get our database encrypted, or we need to encrypt our file system. And let's see how we can use those building blocks. So I had the opportunity and the fortune to be given some tasks that required me to do some things. Sometimes I overstepped my boundaries and then learned, you know, where you should write your own things and where you shouldn't. And sometimes I got the opportunity to really spend time understanding the ecosystem. So cryptography was really the first area. that I sort of fell in love with and spent time, whether it was in research and product development. And then as I moved away from that into IoT security, started learning about other systems and other protocols and focused a lot on trying to see how we could secure some of those things. And then at some point thought, okay, cloud seems to be interesting. People are doing that. I think maybe that cloud thing will catch on. Let me see what I can do there. And again, you know, you gotta learn the discipline. You gotta come humble. You know, when we started the startup, I realized I didn't know a whole lot about OWASP and AppSec. And I spent my time in other areas of security and I needed to learn and I needed to open my mind and stay fresh. And you start out being humble, you start out learning, and eventually, hopefully, you get smart enough to say something intelligent once in a while. So we'll see how that goes.

5:09Chris RomeoThat's the— you just described the whole startup journey right there. Like, I start something and then I realize I don't know anything. And so I can also agree that that is the truth. Like, you go into it and you're like, Finances can't be that hard. P&L, you know, profit and loss. I've seen that on TV. It was in a movie sometime. But, you know, figuring all that stuff out, you're spot on. It's that you either embrace a life of humility or you get knocked over a bunch of times and then you're like, you get taught some lessons in that particular space.

5:43Hillel SolowAbsolutely. So, hello. Just to sort of dive into application security programs, In your experience, I know we talked about time at Cisco and other places, but what are the building blocks for application security program? Right. It's a great question because I think we often talk about AppSec without even thinking about what we're trying to solve and what we're trying to do. We just rush into web application firewalls and RASP or something without even thinking about what it is. I think, first of all, for me, it's always about remembering what the end goal is. And the end goal is, you have an application, you have data, You want the availability, the confidentiality, the integrity of those things to be maintained. That's your goal, right? Everything else is just part of the journey. But your end goal is to say, I'm deploying an application. I want to make sure everything works. I want to make sure it protects my customers' data and my data. I want to make sure that it continues to function the way it should. And I know there are bad guys out there trying to do bad things to me, and I want to make sure I can survive that, right? And then the second thing you have to keep in mind is, you know, okay, there's some level of security that makes sense for my organization. There's some level of security that's overkill for my organization. And I Often, I've been in situations where we've put too much security into a situation and we've spent too much effort on security and found that we've crippled the product. So it is worth saying, okay, am I worried about a nation-state attack or am I worried about corporate espionage, et cetera? So once you've got those things sort of laid out for yourself as, okay, I'm a company, I'm worried about my customers' data more than anything else, I'm worried about my system being available more than right after that, et cetera. Now you say to yourself, okay, what are the things you got to do for that? One of the things I learned through Chris and through Cisco was to sort of think about this through the before, during, and after division of labor. So what are all the things I'm going to do in order to get myself to a deployed application that'll be as secure as possible? What are the things I'm going to do during the time my application's running and when I'm under attack? And then what are the things I'm going to do when I want to recover from that and handle that? So we think broadly about that. And I know the past few years we spent a lot of energy in the world around the before. which is great because I think we used to ignore a lot of the before, go right into the during, and then do a little bit of after. So it's great that we've now focused a lot in on the before. We've thought about, okay, how can we do things earlier? How can we get more stakeholders? You know, any organization, especially a small one, which we'll talk about later, has more developers than security people, right? If you don't, you're doing something wrong, right? So, you know, how do I get my developers to be part of that? How do I get my DevOps engineers to be part of that? So all that before is really good. It's really about getting yourself to be deployed in a way that's as secure as possible and as risk-free as possible as you can. The during is super important still, right? You can't discount that. At the end of the day, bad things happen while you're running, not before you're running, not after you're running typically, right? So focusing on what are the things we're going to deploy in and around and above our application to make sure that the people who want to do harm to us are going to have as hard a time as possible. And then the after is often ignored, especially by small organizations. You know, the easiest thing to do is convince yourself, well, if I do the right things, I won't be attacked, so I don't have to worry so much about being attacked. But the reality is you need to understand whether you're under attack. That's not always so obvious. What was impacted? And then, you know, what do I do about that? How do I, you know, come back from that attack? And, you know, one of the nicest things I've seen written recently was, you know, it's not about saying I'm never going to be attacked. It's about saying I've got a plan for if I get attacked, what I'm going to do, right? And so that after is also important. Do I have— am I collecting the right data? Am I putting it in the right place? Do I know how to get to it? Do I know who's going to look at it? Do I know how to understand from that data where it was impacted? And then, what's my program to remediate, fix, recover, et cetera? So, I think it's those 3 things. It's a lot of work, to be honest. The more you think of it, it's a lot of work.

9:19Chris RomeoYeah. I hadn't thought about before, during, after for, I guess, a little bit of time. And when you think about A lot of companies in AppSec are spouting the shift-left approach to the world, and we have to— that's really the before. Like, shift-left was before it was cool, before it was the in thing to say.

9:46Hillel SolowExactly. Exactly. Yeah, I actually recently bumped into a CISO who said to me, yeah, I'm done with during. I'm just doing before. I mean, he said, I'm just shifting everything left and that's it. I said, like, you're turning off your WAF? He's like, yeah, I don't care. I'm gonna just do pipeline, CI/CD, and that's gonna be enough for me. And it was funny because I said, like, I understand why you want to believe that. Like, I understand the emotional goodness that comes out of thinking, oh, if I just do these 6 things in my pipeline, I'm gonna be fine. But man, that's not realistic. Like, the reality is the really bad things happen because Because everything looked fine and then it just wasn't suddenly. So, you know, it's that balance.

10:27Chris RomeoYou come back to, I mean, when did we start talking about defense in depth? Like 100 years ago or something? I can't remember exactly when on the calendar, but that age-old principle, it's funny how some of those security principles from the '70s that were created by folks in the US government still hold true today. Something like defense in depth. You even give that example, like you can do all the shifting left in the world that you want, but if you don't have something like a RASP or some level of protection while your application's in production, you're gonna, you're gonna have something happen that's outside your control. You're never gonna get to the point where your pipeline is 100% effective catching everything.

11:14Hillel SolowRight.

11:16Chris RomeoAnd so, that's, that's, it's an interesting thought. I think it's going to end up in peril in neglecting, you know, the running applications in production. And then, it almost sounds like also not thinking about the incident response side, you know, on the, in the after. Right. Yeah. You know, how do you clean up and learn from that from a retrospective perspective? The only way we don't do this again is to learn from that experience. And if we don't stop and learn, How do we ever prevent repeating the same problems over and over again?

11:46Hillel SolowYeah. And then, it's worth saying that across all 3 of those areas, maybe the biggest thing we don't focus energy on is making sure our people are trained to do the things they need to do. So, it's, I bought a product, I put it into my pipeline, but did I train my DevOps engineers to look at the output of that and be useful with it? I bought a product for runtime security. I'm running a RASP engine. Did I train and give people the knowledge they need to understand how that's going to work, what it's going to impact, and then how to manage it, and then what happens if things go bad? And then maybe the biggest one is incident response, right? So, okay, I'm a startup. Yeah, I'm dumping everything into some file on S3 somewhere, and I know the data's there, but do I have anybody who knows how to look at that, just make sense of it? Do I have a plan for that? I think that piece is also really often neglected.

12:32Chris RomeoYeah.

12:33Hillel SolowI mean, right now I'm working with a company that's trying to sell a tool. So I don't want to discount the value of tools and tools that can be useful to people who don't have a lot of training are really great, but it doesn't get rid of the fact that we need to know how to use the things and the processes that we put in place.

12:47Chris RomeoYeah, that's a good point. A lot of times we deploy a tool and we don't prepare people for the tool, meaning to your point, we don't train them on What is the technology that I'm giving you as a developer? And we wonder why developers push back on tools in the pipeline when they get 10,000 results the first time. Oh, you need to fix all these things before you can push to production. Well, there's 10,000. It'll take me 152 years to fix these 10,000 items you've just given me, right? And so, yeah, I mean, tools are crucial. I'm never going to suggest— I mean, what would I have in my pipeline if I didn't have tools? It would just be a straight line.

13:29Hillel SolowCode comes in, pushes to production.

13:31Chris RomeoRight? Like, we have to have things to do automation, to increase the speed of which we can deliver software. But we do have to educate those people on how those tools work and what are they going to get from it. Instead of making the tool about us as a security program, let the developer know, here's the advantage of this tool. Here's what you're going to get from it. Here's how it's going to make your life easier. Here's how it's going to let you go on vacation and not have to worry about these things. when you're not here. And that's one of the crucial points. So, I want to transition and talk about AppSec now at some different sizes of companies because we've— Hillel, you did a great job of laying the groundwork of, you know, what are we thinking about when we say AppSec and from a program perspective. But let's say we took like startups, mid-sized companies, and enterprise companies. In your experience, what does AppSec look like in those different-sized organizations?

14:27Hillel SolowRight. So obviously, large organizations typically have evolved security teams that have a program in place, and they've bought a lot of tools. Their biggest challenge is things like— I hate the phrase single pane of glass, but at least it illustrates the challenge of, I've got a lot of things in place. I need to figure out how to use those things. How do I make value out of those things, right? And then, the unfortunate reality is I've got 43 tools, but I'm also not fully covered. So do I really want to buy another tool? And What's the overhead of that? So those organizations have big programs. They are, you know, they're also large machines. They're ships that are hard to steer. They've got a lot of developers and a lot of groups doing a lot of things. And so for them, the challenge is, yeah, I've got an evolved security team with well-trained people and the budget to buy good tools, but I'm also dealing with a much larger, much more complex, much more heterogeneous organization that, you know, I need to somehow secure, right? And that's not easy. When you go to the other end, startups, Again, sometimes nothing, unfortunately. That's the reality. I think that's getting a little bit better. I think there are, you know, one of the companies I work with, ProtectOnce, is a good example. But there are a bunch of companies out there that are really focused on letting developers do security early and do security well without being super high-end trained. So, there are ways for startups to sort of balance the fact that it's not just about budget. It's really about energy, right? As a startup and And we've been to these places and I've been there. If I sit at the beginning of an epic or a sprint going, okay, what should I do? Should I add disaster recovery capabilities or should I add features? I often think, okay, who's going to write the press release to my customers about the fact that I added disaster recovery or I enabled single sign-on or something? It's not exciting. Whereas if I turned— so you're always motivated to add security features and you're always limited in terms of budget and capacity and people. So some startups, I think, are really skipping over it. And that's obviously a real shame. I think that's getting better. I think you can do some of the fundamentals today, whether it's driving towards compliance, which a lot of times you need to do in a startup, or even just getting an AppSec program in place to have, you know, some, something happening in your pipeline, something running at runtime to protect you, some thought about whether you or some outsourced program can help you if something happens and is in place to do that. I think there are startups doing that, not enough, to be honest.

16:43Yeah.

16:44Hillel SolowThose mid-level, mid-sized organizations, I think in some ways are maybe in the easiest spot. And I know that's a counterintuitive thought, but it's just saying, you know, if I'm a 500-person organization, I've probably got an AppSec team. It's probably 3 or 4 people, but I probably don't have 15 or 20 different application teams developing applications in different languages and different cloud platforms. Like, I might have an environment that's close enough to, you know, homogeneity to be able to say, okay, here's what we're gonna do, guys. We're gonna run in Amazon and we're gonna use AWS WAF and we're gonna buy Palo Alto's this and Check Point's that or whatever. And we're going to have 4 tools. I'm going to write it. So it's like you're big enough to think about security, but small enough to actually try to solve the security. I'm kind of envious of those guys more than anybody else.

17:24Chris RomeoYeah, it's kind of the sweet spot, you know, is that mid-level, like you said, they, you think about like, you know, I think about my time at Cisco. How many products did we have? A lot. I don't even know. I don't know if anybody knew how many total products we had. Somebody probably knew somewhere, but I never saw the number. But there were a lot of them. There were probably more than 1,000 individual, and you talk about individual SKUs, there were probably millions of SKUs that made up all the products and stuff. And so, being able to secure at that level is, there's just an organizational data problem that you have to solve before you could even get to how do we do AppSec?

18:06Hillel SolowYeah.

18:07Chris RomeoThe question is, what are we going to— what do we need to secure?

18:09Right.

18:09Chris RomeoWhereas in the mid-level and startup, to your point, there's— you've got good visibility in front of you into here are the things that we need to secure. You know, that mid-level company with 250 people that has one product is really in the sweet spot because there's not, you know, we're not doing this for multiple, you know, even a couple of different products and stuff. So, yeah, that's a— it's good to think about these things in the context because I know we're going to transition to talking about kind of maybe even the most smallest of companies. Right. And with that in mind, hello, what's your most important advice for those companies that can't afford a security person? So it could be a startup or even maybe a midsize yet. They're still trying to figure out how do we do security, but they don't have a person yet. What's your advice?

19:01Hillel SolowYeah, so I often get that question from people and Usually, the question is phrased, well, I don't really have a security team. What should I do about security? And the simplest answer is you should have a security team, right? And it could be one person. It could be half a person. It could be somebody who's got other roles. The company I worked with, NetProtect, once, there's a guy who's in charge of security research. So, he spends about half of his time on securing our own product, and the other half of his time he gets to spend on researching how we can make our product better, creating more content for us, things like that. So it doesn't have to be a full-time person. It doesn't have to be 100% of the time, but there should be somebody who is knowledgeable in security and is responsible for security in the organization. So that would be ideal. Now, you still get pushback from people saying, listen, we're 6 people. We're bootstrapped. We're building a product. Let's be realistic. And obviously, that happens. And I've been in those situations, so I understand. So still, I would say, even if there's no security person, somebody gets the hat, you know, that you can't share responsibility. So you got to decide, maybe it's the VP R&D, maybe it's the CTO, maybe it's the CEO. I don't know who, you know, what everybody's capabilities are, who wears that hat of, okay, what are we doing to make sure that when we talk to a customer about our product and they say to us, is it secure? It's secure. Because remember, it's not just a nice-to-have. It's not a luxury, right? You're going to get those questions from your customers. You know, what are you doing to protect my data, right? And so you have to have something in place where you say, well, yeah, I'm doing something. I'm encrypting. I'm I've thought about it. I've got, you know, the right IAM roles, and I've got the right network configuration, and I'm using the right tools. And then the other thing is there are tools out there, and that's why I say it's a little bit more solvable today than it was in the past. I think in the past it was more forgivable that someone said, I can't really, I mean, how am I gonna, I can't run a network firewall. I can't do that. I can't run a web application firewall. You know what kind of energy it takes to configure that thing? Those things are still true, but there are tools out there that are, you know, designed for those scales. There are tools out there that have really good sane defaults. Do you get 100% security? We already agree there is no 100% security, right? So it's all about now, okay, how many layers do you have? How well configured are they? How much value are you going to get out of it? You know, what I say to people is, you know, again, even as a small organization, put the hat on somebody, decide what you're most worried about, think through what are a few tools that you can use and put together and the process around them that will still give you value, right? So if application security is your key focus, focus on application security. Find something that'll easily let you put security into the application. Put it in the hands of the person who can use it. Come up with some thinking about what's it doing for me? How's it configured? How do I know it's working? Can I test it? If you can't test it, you can pay someone to test it, right? There are people out there that will happily come in and spend a week or two with your product. It's not incredibly expensive. You can afford it even as a small startup. And believe me, I've done that thinking. In other words, I'm I'm often the guy in the office going, can't we just not buy the bottled water and save $1.50 a week? Right? You can afford today to outsource pen testing or security evaluation to a team that'll come in and help you. There's ways to do it. It's really about focus. It's really about saying, okay, this is important to me. I know I'm not going to do everything, but it's important to me. Let me think through about what the most important parts of it are. If it's application security, if it's cloud security, maybe you come to the conclusion that for you, You've got a really complex cloud deployment. You need to make sure your cloud security is in place. All right, there are some tools out there that can help you. There's some really great tools now, CI/CD. By the way, there's some open source out there that's fantastic. You can do some stuff with Chekhov today and Terraform scanning that's really powerful. Even without paying for tools, as long as you're willing to pay with time and effort, even as a small organization, you can get it done. And the last thing I'll say is, this is the one that it's really hard for a small organization to reconcile, is You can get attacked. I don't want to say you're going to get attacked. If you're small enough, you might be a small enough target, but bad things can happen even if you do everything right. And so, it is worth having a one-page plan even that says, okay, here's how I'm going to know that I got attacked. Here's what I'm going to do. Here's my big red button that I press. Okay? And it can be, again, it can be some managed service that you're using. It can be a guy that you have, you know, who's a consultant. You come in, there are plenty of these consultants out there that will come in and save your butt when you need it. But you don't want to go find them at 3 in the morning when your application's behaving weirdly and you're not sure. You want to know in advance that at 3 in the morning you say, hey, Guy, listen, I got a problem. Can you come in and take a look? 6 hours later, you know you were standing there. So, I think planning for that is maybe the hardest thing for an organization to reconcile because it's like all QA. It's easier for me to think about what my product should do. It's harder for me to think about all the ways my product could go wrong. So, sort of thinking, okay, what could really go wrong? It's hard, but I think ultimately the bottom line is you can do it as long as you figure out how to scope it and as long as you recognize that somebody has to be responsible for it.

23:41Chris RomeoYeah, I always wonder why does every incident begin at 3 o'clock in the morning? I don't know. I mean, I used to be a director of incident response and my pager, back in the days when we had pagers, we'd be on call and I was kind of like the second level of if it got through our on-call responder, They would, they would come to me and it was always somebody who hadn't done enough planning. So at 3, by 3 o'clock in the morning, they were, had reached the frazzled state of—

24:12Hillel SolowRight.

24:12Chris RomeoHardly being able to communicate other than yelling at you into the phone. So yeah, that's the, that's the world of incident response. But yeah, it's a great point that having at least even just a one-page description of what do you, what are we going to do when we get punched in the face? Yes, it's a plan. It may change. Things may be adapted. But sitting there, when you have that first incident and you have done no thinking about it, talk about panic. You have no idea where to go. And so, on the other side from thinking about what you were saying about with startups and the need for security, I think it even needs to be— I think startups need to just start They need to just start embedding security no matter what they're doing or where they are in their process. I think we've reached the point in the market, you know, we can remember back, I mean, how long ago was it? 10 years ago, 15 years ago where you could skate by without having a story for how you're protecting data. But even just getting, you know, for the people that have small startups right now that are trying to find product-market fit, like, Trying to get that first enterprise customer, if you haven't gotten there yet as a startup, and you guys on the line here have experienced this, you're going to get this 200-question security document you're going to have to fill out. And if you haven't, if you're going to have to go back and try to retrofit your product when you get that security document, you're going to be in for a world of hurt. So, it's better to at least— maybe it's a lightweight process for AppSec. Maybe it's what Hillel said earlier, it's adding a couple of tools. There are open-source things. It doesn't mean you have to go spend $1 million to build out a pipeline of security tools. There are some open-source. There's a lot of good commercial stuff as well that for startups is inexpensive. But having that strategy, that architecture from the very beginning, is going to make that getting that first enterprise customer, because what you don't want to do is, is get an enterprise customer on the hook and they're like, oh, this seems like a pretty interesting tool that might help us. And then they go through their security because you're not going to have SOC 2. Of course, you go through their security questionnaire and you can only answer 50% of the questions as we do this, we do this. The other 50%, you're like, nah, we don't do that. We don't encrypt data at rest. Oh, okay. Well, we're not buying your product. And so, that's been my experience as well. And so, I think we can push the bar. We need to push the bar in the startup world to say basic AppSec is something that is just a minimum bar of entry if you want to work and play in the enterprise.

26:52Hillel SolowYeah, I agree. Along with that, I was going to say, along with that, there's something you mentioned that I've heard as well is, I'm too small.

27:00Chris RomeoWho cares about me? And that's gone. You can't say that anymore because attackers like small stepping stone to get to the bigger fish, if you will. So absolutely, you have to take that perspective that it's not about being too small anymore.

27:17Hillel SolowEverybody needs to be thinking about this. And there's ransomware that'll come after you even if you're small. It's all automated. You know, the attackers have found ways to target small fish and make lots of money off of them. So yeah, absolutely. Nobody's too small to need security. And I agree with your point, Chris. I think There has been a good job done. We're not all the way there yet on holding even startups accountable, right? And saying, these questionnaires are really valuable in the sense that they do make it so that you can't get that far as a startup before somebody puts a big bar in front of you and says, wait a minute, do you have a plan in place for when employees leave? Do you have a plan in place for when you get breached? Have you encrypted your data at rest? No, I really don't. And mind you, each of these things is somewhere between 10 minutes and 2 days of work. But when you multiply it by 200 and you You need to do them over the weekend to get that questionnaire in, you're in for a world of pain, right? And so, for sure, I know it's a cliché, but for sure, doing it earlier is easier. The other thing is what we've gotten better at in some areas, but not enough, is the idea that developers and DevOps engineers and architects can be part of the solution, right? Because as a small organization, again, I have no security people, but I have 6 or 7 or 12 developers and DevOps engineers. And they can be part of the solution if I'm thinking about the right tools, right? And so, we've gotten good, like, with vulnerability management and software composition. We've gotten better now at not just creating tools that can work earlier, but actually helping developers understand that this is part of their job, right? And security is just another nonfunctional requirement for their product. And if security means making sure that I'm not running an old version of Log4j, then that's my job now. Okay, fine. Right? And the flip side of that is developers are not security people. Bringing them dashboard-based tools that send them messages to their Slack or something with problems is not the way they need to solve problems. Developers need underlined code in their IDEs, and they need pull requests in GitHub, and they need tools that speak their language, and they need tools that talk to them like people who understand they're part of the security solution but are not trained security people. Don't start throwing lots of OWASP jargon at me. instead of telling me what I need to fix, right? Show me where my problem is. Show me where the solution is. So, if you combine that, we're saying, well, I actually can leverage my development team to be part of the solution, but I can do that by finding a tool and a process that speaks their language. I think that can work really well for startups. Start with the things that you can do that way, do well. Eventually, you'll get a full XDR, incident response team, SOC, et cetera. But even as a small startup, you can do a bunch of those things. You can rope in those people. And make them your friends and make them help out.

29:49Chris RomeoYeah, I like that idea that security, and this is something that I believe and talk about all the time. I mean, security is everyone's problem, but in the small startup, it really is everyone's problem because to your point, you might not have a dedicated security person like we've been talking about here. And so, you have developers, they understand the technology, They can adapt and get these tools integrated and get you to that basic level of AppSec, which will hopefully get you over that first hurdle of answering that security questionnaire. And I've been through so many of those questionnaires that I'm starting to shudder a little bit.

30:31Hillel SolowBut— I'm starting to sweat from it.

30:33Chris RomeoIt's like, why didn't I just get SOC 2 earlier so that I could throw the SOC 2 card down on the table and go, nope, I'm good. I don't need to answer all these things. I've already done this with an auditor. But so, Hillel, from your perspective then, we like to leave our audience with some type of a key takeaway, a call to action. So, we talked about AppSec in this world where companies can't afford a security person. What should our audience do with this conversation? Like, what do you want to direct them to, or what do you want to, you know, leave them with here in regards to this conversation?

31:07Hillel SolowWell, the world that I'm hoping to live in at some point, besides being COVID-free and the stock market going back up, is a world where I think we found a way to bring developers really into the story, into the mix for security, but without trying to throw security at them as their responsibility. And I know I've tried that and failed, and I don't think that's a working solution. So, I think this world where we found a way to say, look, security is a feature of the product, And in the same way that we figured out that we can't separate testing from product development, we can't separate security from product development. More and more of our remediation happens with security people. More and more of our discovery happens with security people— sorry, with developers. And more and more of our remediation happens with developers. And so, being able to empower developers to be part of our solution, but without trying to say to them, oh, guys, hey, now security's your problem. There's no AppSec program anymore. Go for it, right? because that won't work. I think that's what we really need to solve. So I think we've, again, as I said, we've done that pretty well for parts of security, the things I think that are easiest to shift left in meaningful ways, but not just shift left, but really empower developers to be impactful on. I think we can do better. We're focused by us on doing that for the runtime parts of AppSec, putting those in developers' hands, which is, I think, a little bit more out there and a little bit, maybe a little crazier, but I think we've managed to crack that nut. But really, that notion of whatever it is I'm doing in AppSec, part of that impacts developers, whether it's how do I find out where the problem is, how do I solve the problem, or how do I react when the problem pops up, and finding those ways. So, I guess the key takeaway, if I boil it down, is if you're a developer, try to find a way to be part of the solution. If you're a security person, try to figure out what am I doing to make sure that my developers are empowered and motivated to be part of it without trying to be offensive or trying to sort of shift responsibility off myself, Because that just doesn't work.

32:56Chris RomeoVery cool. Well, Halal, thank you for taking the time to share with our audience this perspective on AppSec programs. And we talked about the different sizes and then this advice for companies that can't afford a security person at this point. I think there was a lot of good nuggets of information for both the startup and the large enterprise, the things they can glean from this conversation. So we look forward to chatting with you again in the future.

33:26Thank you for listening to Security Journey's AppSec Podcast. You can find us on Twitter @AppSecPodcast, on LinkedIn as the Application Security Podcast, or on the web at www.securityjourney.com/resources/appsecpodcast. Find Chris on Twitter @edgerow and Robert @robertherwatt. Remember, there are many application security paths, but only one destination.