BSidesSF 2026 - The AppSec Poverty Line: Minimal Viable Security (Tanya Janca)

So, good morning everyone and thank you so much for your patience. Um, TA Jen is here. Um, and so TA Tanya is um, aka she hacks purple is the best-selling author of Alice and Bob Learn secure coding and um, Alice and Bob Learn application security. She is currently the CEO and secure coding trainer at she hacks purple consulting. Over her 28y year IT career she has won countless awards and that includes oas lifetime distinguished member and hacker of the year. So let's welcome uh Tanya today. She is going to I'm so I'm so sorry. >> She's going to I've got it. >> She's going to give us a talk on the ABSC poverty line minimal viable

security um MVS. So, let's welcome Tanya with a round of applause and thank you so much for being here today. Hi everyone. I should have sang like Katie. That was so amazing. Um, thank you so much for coming. I want So, I've had lots and lots of companies and lots of times where I've given talks where people say, "Well, we're not this giant company, you know, we're not part of Fang. We don't have this huge budget. What do we do? What what do the rest of us do?" And a lot of startups, a lot of small businesses, what do we do? And so, this talk is for the minimal viable security. So I I'm calling it the

abstract poverty line. Um originally in the program there was a different talk listed but it was there was some confusion between me and besides I'm sorry I can't do that talk because I'm doing at RSA and you're not allowed to do it at both and I said yes to them first. So then yeah so sorry about that but thank you for coming. Um, so we're going to talk about the fact that not everyone has any budget at all for security and how not every project has one of you to give its attention and how everything that is publicly exposed still actually needs to be secure anyway. We like if it's not, we're going to have some real bad days. And so I

want to talk about the minimal viable amount of security that I feel we must provide. And I feel like um for every talk that this meme is very very very actionable. Um briefly the who am I slide. So I'm Tanya Jen. Uh I give secure coding training. I wrote books. I've worked in tech a long time and started some things. I give some advice. I helped write the new OAS top 10. Um and hopefully you're like she seems tolerable. I will totally sit through this. Um, and with that, most teams are not Microsoft or Google or Meta or whoever with like lots and lots of huge giant budgets. And it shows in our security posture and like yes, I

I wish that I could have a budget like they do, but for the rest of us, what do we do? I did a survey in 2024 about you know where we are in appsac um of 60 companies and as an industry we are not doing very well um when people call me in to consult and give training and stuff they're already here usually right like even if I'm the first time they've had training they're taking security seriously enough to engage someone like me right so I kind of thought that the industry was doing like pretty great and then I did the survey and I was like, oh, my viewpoint had been quite biased and doing the survey really opened my eyes.

Um, in 2025, I helped a a big company that you all know the name of start their first APSAC program. So like we are we are not all on board this train yet. And so what is the poverty line? So I'm going to explain the poverty line in general and then I'm going to explain how I'm using this analogy to apply to security. So it is the threshold of poverty below which someone's income does not cover the necessities. Okay. And so the absc poverty line is the minimal threshold of security investment knowledge and practices below which we're not able to adequately protect ourselves from common threats. Just the basics. We can't protect ourselves against the basics.

And wait, there we are. If we put something on the internet, unless it's completely static, we're being super grossly, ridiculously irresponsible if we're not just at the poverty line in my opinion. And I know I have some biases as I discovered with that survey, right? And clearly I'm kind of obsessed with security. So what what do I mean by minimal viable security or MVS? So I'm sure some of you have heard of a minimal viable product. So like what can I build so that I can prove to you the value that this thing actually works? It doesn't have all the bells and whistles. It's not perfect yet, but I've showed you this concept is true and that I can build this and it

can solve your problem. So minimal viable security would be the minimal minimal the smallest set of security controls, practices and processes to meaningfully reduce risk and to protect an app or a system from common credible threats without impeding its core functionality or delivery. So that doesn't mean some great big huge zero day like the big React vulnerability that came out. Like we are not defending against nation states here. We're talking about the minimum. Okay. Um and so to be clear, I want to be super clear. Um every app that goes on the internet needs to be MVS or better, but obviously preferably way way way better, right? And just to be super 110% clear, Tanya is not telling you

This is how much every app needs for security. I'm telling you, this is the absolute bare minimum. All of us want to do way better than this because sometimes I'll give a talk like this and people are like, "Oh, Tanya said this is how much security we need." And they're like an enterprise or something. I'm like, "No, no, that's not what I said." So, just to be super clear, I had to have the silly pink slide. So, I want us to prioritize what actually matters. So I've broken this talk into sections and then at the end of each section there's a QR code where I have a PDF summary of each section and then at the end there's

going to be a QR code where you can just download a PDF of all the slides immediately because I like sharing. So um when I pause at the end of each section that's so that if you want you can take a photo of the QR code. You don't have to do any of that. It's just that I'm a person that loves taking notes and I took notes for you. Um, so prioritizing what matters, like what are the the bare essentials in my opinion for being exposed to the internet. So not a static site. It's not just HTML. This is an app that does something. Um, so the first one is input validation. So we want to validate whatever we're

getting is safe. And if all of us did this perfectly, oh my gosh, the internet would be so much safer overnight. like so many things are we don't realize it's input to our app or we sanitize it instead of validating it. We don't really check properly. We we do check after we used it, right? Like we get this wrong. Um and so validating what we get and then either sanitizing or escaping if we must accept something potentially dangerous like special characters. And basically if we get something bad we just reject it. We don't try to fix it because we get that wrong a lot as an industry. If we all did this, oh my gosh. Um, number two, if

something's going to go out onto the web and we're going to look at it, we should output encode it for the web so that we could just say goodbye to cross a scripting. So the o the new oas top 10 2025 cross a scripting was folded into injection. It's no longer its own section. Yay, because we're doing it less. We still are not good at it. We're still not good at it. Um, number three, if we are going to talk to a database, we want to talk to it safely, right? So we are going to use parameterized queries. We're not going to take a bunch of random things from the public usually like from a user concatenate it together

and then send it to be executed by our precious precious database. No, no, we are going to use stored procedures, prepared statements, whatever you want to call it so that we take away its powers. Whatever's in the parameter is treated only ever as data. There's no confusion. Right? If we did this, if we did these three things, oh my gosh, the internet would be so good. um use modern tools, right? Like let's use LTE so supported whatever the latest supported version is, whatever it is, let's not use old stuff. If you're building something new, we should use something new. And I know you're like, "Of course we do." Not everyone. Okay. Number five, thorough logging and monitoring. So many

companies are like, "Oh, logging is expensive." I'm like, "You know what's way more expensive? responding to an incident where you have no logs and no evidence and you don't know what happened and your data is on the internet that's way more expensive not having monitoring your clients call you and you tell they tell you your app is down instead of you knowing and putting it back up before they can call right of course of course we want that like even on APIs even on serverless like even there's no app that's too small that we don't care if it's up or not right of course we care okay number Six, secure authentication, authorization, session management, identity, buy a

system. Don't write it yourself. I have so many devs tell me like, "Oh, I can do it." And I'm like, "Microsoft's one of the oldest companies, like IT companies in the world, and they made Active Directory, and they measure their profit in trillions, and they've been working on it like what, 30 years, and there's still bugs in it. I'm sorry. You can't do better." Right. Right. Um, I don't think I'm better than all of those people in all of those years and all of that investment. Why do you like let's let's just trust me on this one. Like if we're going to do an extremely complex security control, if we can transfer that risk, we should. Um, dependency

management. This is something that I think there's a bunch of talks about that I'm excited to go see that most of them are in this room. Um, we want to not use terrible dependencies. I could talk to you about this forever. If you want to talk about it after, I have lots and lots of advice. But basically, we want to verify which dependencies we're using, if we feel they're trustworthy, if there's a vulnerability in it, are we managing that risk, etc. Um, and we need to check regularly because software doesn't age well. And then number eight in this section, transfer risk, like I said two slides ago. So, if you are going to handle payments, you can pay to be PCI

compliant and jump through 4,000 hoops. And don't get me wrong, the hoops are important. Um, or you could get some other company to do it for you, like Stripe or whoever. I really feel this is worth it, too. I have talked so many clients out of like unless you're doing like huge huge tons and tons and tons of credit cards, like maybe someone else could manage that risk for you. It life is so much better when we don't have to sweat it. Um, I asked the AI to make a picture of Troy Han and Scott Helm, like the HTTPS guys. Um, and this is this I don't know if any of you know what they

look like. They do not look like this. But anyway, they look very excited about about HTTPS. And so I'm like, well, that's true. Um, but we like everything on the internet should be HTTPS, but I would encourage you to have things behind your firewall also have encryption. Encryption's awesome. And there's the EFF folks here and they've made it so that it's basically free now. And I just don't feel there's the same excuses as before. But if we don't do HTTPS appropriately, Chrome will embarrass us. Okay. Number 10. If we are not doing basic security hygiene, we shouldn't be worrying about zero days. We should be worrying about someone pew pew pew our app with like zap or burp some free

scanner and finding big bugs. If if a basic scanner can be pointed at our app on the internet and it finds a real a real vulner we should be fixing that right. I feel like we should fast we should be able to pass a basic D scanner. We shouldn't be on the internet. Um I feel like that is a problem. Um by DAS I mean dynamic application security testing something like Zapper Burp or um Nuclei or whatever. There's many many choices and there are lots of free ones to choose from. And then, oh, actually I have a few more things. I know that like this is like I feel the the minimum and I was

like, oh, you should make it like 10 or less. And then I was like, 10's not enough. I I would like to encourage you all to consider doing just the most basic threat model, just one conversation about your system, what could go wrong, what you're worried about. If you can do the four question frame by Adam Showstack of like what are we doing? What could go wrong? Where are we going to do about it? And then the guilty question, did you do a good job? Because if you accepted all the risks, spoiler alert, the answer is no to that question. And so having a conversation, just a basic conversation, not being exhaustive. And then if something

worries you, fix it, right? And then lastly, let's assess the security of our system, which is four questions. So each question, if it's true, you get a one. If it's zero, or if it's no, you get a zero. And then you add it up to four. So is this app on the internet? Like is it public facing or no? If so, one. Does it have any sensitive data? Oh, now it's a two. Is it mission critical to our company? No. Three. Uh or yes, three. And then is there legislation or compliance that applies? Now you're at a four. If you're at a four, you're certainly not at minimal viable security. Right? If you're like basically anywhere above one, you need

to do better than this. especially if you're two or above, right? And so you can do this and then very quickly decide how much security something needs. Um lastly, number three, if you guys could stop talking, that'd be great. Thank you. It's very distracting. Um let people report security issues to you. You don't want them to put it on pace pin. You want them to tell you, right? I find it um internal and external. So, I really really want the staff and my devs to tell me if they see something, I want them to say something. But making it super easy, like just having security.ext with an email address of how to report something. I was training

a company last week and this very nice young lady intern was like, "Yeah, I was using like this app in her personal life and I found this big security bug. Um, and I don't know how to tell them that I found it. I want to report it to them. What do I do?" And then we had a nice discussion about it because there was no way on the company's website to report it. So this is just a way to very simply say like if you see something say something and I I won't sue you. Yay. And so this is the summary for this part. And that was that was the longest part. And now we're going to get into

what does not matter for small teams. Um and then we're going to talk about a couple of other things to like boost you up even more. So this is just a summary of this part. But so what doesn't matter to small teams? So this is why Tanya says if you're really little, you are allowed to ignore if you don't have the time, the money, or the team to address these things. So which version of TLS you are using? A nation state company is not going to hack your little recipe site. They don't give a crap about you. If someone is trying to break like TLS uh 1.2 down to 1.3, it's like I mean don't

use SSL. That's silly. But like if you're using 1.1 versus 1.3 or 1.4, like don't you're going to be okay, right? Like do you want to fix it eventually? Yes. But don't stress out, right? We try to use the latest version, but you don't need to flip out. Um zero days, right? Unless So you need to handle all the common security hygiene issues first and have a basic apps program first before you worry about that. So unless it is actively being exploited in the wild. So like when that React vulnerability came out in December or during log 4j. So like if it's making the news you want to do the thing but you don't need to worry

about like oh you know like this random thing that was on the dark web and blah blah blah like if if you haven't even passed the dask in like this is not where you're at yet. Um, number three, creating your own custom like cryptography, PKI, SER management, arbback. Again, like literally last week I was talking a client out of writing their own encryption. Um, I have to have this conversation like a bunch of times per year that like you're we're not that important, most of us. Um, and these things are really hard. And instead, what we should do is buy the thing, right? Like we we don't need to like do all these things from scratch,

especially for small teams. like this is not where we're going to get our value. Again, highly complex, like locked down 25 different like I had this company when I was a dev and they had eight people that were going to use this app and they wanted 12 different roles and I was like, "No, you get three." And they're like, "Oh, but we want I'm" I'm like, "You get three. That's it. Stop being stupid. Just you don't need 12 roles for eight people." Like what? My boss was like, "You need to work on your soft skills." Um, but we need to create simple roles, right? Complexity breeds flaws and problems and we want to avoid that. Um security through obscurity

efforts. Again, this is like a more advanced thing. We if it's on the internet, an attacker is going to find it like if they're really after you, right? And we shouldn't stress over, you know, hiding endpoints, code offiscation, etc. If we are just barely covering the basics, this is an advanced thing that some of us should do. And like maybe you're like, "Oh, well, we have nation states after us." Well, then you're not doing minimal viable security. You should not be doing this, right? This isn't for you. This is for the teams where there's like only eight devs that work there and there is no security person and their budget is this big, right? So then we're not talking

about you for clarity. Pentesting. Oh my god, I said it. Yeah, that's right. You can't afford a pentest, right? Instead, use a free desk, pass that scan, right? Like pentesting is awesome. It's very high value, but not at this stage. At this stage, there's basics you should do first because the pentester is going to be like pew pew pew pew pew find like five billion things and they are going to feel like really good at the end of the day because they're going to find lots of stuff. But this isn't where you could get your best value. You want to work really really hard on improving things and then you call the pentester and then they get to have you know like

really interesting work. um advanced tooling like runtime application security protection, interactive application security protection, DDoS testing, niche exploits, etc. Like we are not there yet. This is like we want to focus on the basics instead like the rest of the talk said. Um I have two more things you don't need to worry about intense and strict governance. If you don't have a security team, how are you going to do that, right? Who's going to enforce that? You don't have money or time. You're not going to get huge value over that at this stage. And the last part is obsession with perfect coverage of every line of code. Instead, like burning cycles on that, that's really intense.

Like doing 100% of lines of code. Let's look at the most important things first. The things that are on the internet first, the things that are mission critical to our system. We want to focus on critical flows. We start there and then we work our way down. So 100% perfect coverage is not necessarily where you're going to get your value right now. And so this is the summary of that section. And then I'm going to talk about how you can really super cheaply or freely train all your developers because they're the ones building the stuff. And I know everyone's like AI is building the stuff. Yeah, well the developers are driving the AI. We want them to drive

safely, right? And so how can we train them? So, how can we have security when we don't have money for specialists? Um, and so I want to help developers spot unsafe code patterns before they shift. And so you can work with them by doing hands-on code review, right? Giving them so I'm going to give you um some free like tons of free resources in the next slide. So like giving them secure coding training, teaching them about secure design handson like they read code and lots of the code is crappy and you help them spot why it's crappy. You help them fix it so it's better so they understand how to fix the slop that Katie told us all about this morning.

Right? So some free resources. Um, so there's so many free thing. There's way more free things on the internet than just this, but all of these, but so I think um, Cyber has started charging. So some of their stuff's free and some of their stuff isn't free, but I think this specific course is free. Um, so there's some things in there that cost money, but most of these things are completely free. Like, so that is a list. Um, the OASP top 10. Did you know that OASP has 37 top 10 lists? Isn't that like that's a lot, right? We apparently love lists. Um, but there's so many so many amazing things from OASP. Not only are they a

wonderful community that I love very much, but they have, you know, intentionally vulnerable apps for learning. They have the secure coding dojo, which is free. They have all the 37 top 10 list. They have ASBs, the application security verification standard. They have free books. Um, they have my old education project. They have over 300 chapters around the world including in this city and they're just absolutely wonderful. Have many great things to say about them and besides Besides is also like you're already here so clearly you know but this is an amazing community. Um so books and yes I'm biased because two of those are mine but there are so many good books and books are not free

but they're almost free. Like for $40 to have that much knowledge is such a steal. So you could buy a couple of books for your team and then you could share right you could go to the library some and if you go to the library you can ask them and they'll buy these books for you. um secure coding communities. So like OASP, ISC squared, Stack Overflow, Reddit, Security Stack Exchange. There's like tons of different places online that you could join. So you could learn more, get them to join with you. Um create like a Slack channel or Discord or whatever you use um where people can like ask a security question safely and get an answer so that we can

make security visible daytoday. That's what we want, right? Another thing is embedding security when we do code review. So every time we review code, we learn something. And if you So yeah, how do we do it without slowing it down, Tanya? So if you can automate some things, that would be nice. But giving developers a checklist of exactly what to look for. Make it easy. Make them literally have a checklist. It's like, oh, did I check this thing? Did I check this thing? Yes, I did. Oh, I did a good job. Train your reviewers. Um, only if you're doing secure coding review, look at for security controls. Try to keep reviews short. If you give someone 20,000 lines

of code, you think they're going to read the whole thing. No, they are not. So, be realistic. Um, and ideally, we rotate this role over time so everyone learns. Every time you spot a bad problem that I'm just going to give you the summary sheet, every time you like spot a bad problem in someone else's code, you are never going to make that problem again, right? cuz you're like, "Okay, so security culture for small teams." Oh, sorry. I saw some cameras are still up. So, security culture for small teams, right? How do we change the way that our team and our company thinks about security? Because if you So, who here has worked at a

place where the security culture is awesome? Yeah. Okay. So, I see a couple of hands. Who here has worked at a place where there is no security culture? The security culture is apathetic and terrible. Oh my gosh, a lot more hands. Right? If you can change your culture. So this is how we do it here. This is what we are rewarded for. This is what we receive praise for. This is what we are respected for. Everyone behaves differently every single day. And that is a gigantic win. So we want to make security part of our engineering values, not compliance, not a stupid sign that is in the lobby that everyone ignores. Apparently Enron had integrity as one of their values and it

was in their lobby. And well that is not what matters. Culture is what we hire for, what we fire for. It is what we are rewarded for. And rewarded can mean compliments. It can mean getting invited to more meetings. It can mean all sorts of things. But like it is not words on a stupid wall that we ignore. Those are not our values. Those are marketing crap that we show customers. It's what we actually do every day. I feel really strongly about this. Values guide every single decision that we make. And in your personal lives, there are values that are important to you that shape the way that you are and you bring them to

work every day. And so if we can change the values where we work, we will get better results. And so we want to stop like we want to normalize if there's a security emergency we stop and it's okay. Not only is it okay but we appreciate the fact that someone brought it up, right? We want to make that okay. We want to celebrate security wins. So even small ones. So like someone did a dash scan and it like only found some informationational stuff. High fives all around. Let's get pizza. Like so many p like so many security teams we just show up when we have bad news. We are the bad news bears. Let's be the people that

show up and give high fives. I'm not kidding. Like you criticism like really doesn't get us anywhere unless we're trying to alienate people in which case like it's a great plan. But for the rest of us if we're trying to change behavior you get so much more bees with honey. So let's invite people. Let's invite them to besides with us. Let's invite them to the OAS chapter, the ISSA, the Isaka chapter meeting. If there's a topic that you think applies to them, bring them with you. Yes, OASP to the rescue, there's Defcon chapters. There's like so many amazing communities that want to meet you and welcome you. Um, this would be like a bigger thing as you are

expanding perhaps a security champion or a community of practice. So, this again is not really minimal viable security, but I love those things, so I had to talk about them. Um, but these are things that I would suggest like for a small company to start with and then I have just like a couple of more things and I swear I'm going to wrap up. I know I always want to say more than I'm allowed to give time. Yeah, 10 minutes. Yes, I'm doing so good. It doesn't say zero. Um, okay. So, open source tools that I feel punch above their weight. So, these are tools that I like and I know that there's a list and maybe I

used to work at one of those companies, but I think they're awesome. So there um so for uh static analysis I like sum grip I like um well I haven't really used codeql but I have heard very good things um for secret detection like truffle hog git leaks there's a million secret detection tools that are free that are good dependency scanning that is hard I am sorry but all the dependency scanners that are free are like kind of so so so so compared to the paid ones right now um that is a place where spending money in my opinion maybe worth it. Dynamic scanners, I just don't buy one. The free ones or like for me

burp $500 like that's free. Um I wouldn't pay for like a really big expensive task personally when we have such amazing free tools for us. Um this is a great place to start with your security program. Lots of big companies use these tools like they're good. Okay, so what do we do when good enough is not enough? When is minimal not viable? when is it quite frankly completely irresponsible? When do we need to level up? Right? Because that was the first question I got after I gave this talk the first time. So first, if you're handling sensitive user data, MVS is not enough. Right? If you're like health information, private information like home addresses plus names and things

like that. That's it's not enough. We need to do more. They're trusting you with their private data. We need to be trustworthy. payment systems, authentication flows, high-profile exposures. If we cannot outsource it, again, like minimal viable security is not enough. If we can't transfer that risk, we must do it ourselves. We have to do better. Um, some signs that you need to level up or escalate depending. So, you have security incidents and your team does not know how to handle them. I have had to do this one time when I worked in the government. It was very scary. And so we luckily could call the GCERT. Uh in this country, you have a cert as well, a

security or sorry, a cyber incident response team that's like part of the government. And they came in and oh my god, they were so amazing. I was super wowed by them. Um and they did a great job and they helped us clean everything up and I'm so glad I called. Um, if your org is growing super quickly and needs to scale, if like everything's changing all the time and everything's growing and you're exploding and you're a startup, like you you have gone past MVS and that's awesome, right? Um, the security team cannot keep up with development and so like the security you're doing is just not keeping up. You need to hire someone at this point. Like

you need a nice cuddly appseac person is going to make a security program for you. um your threat model has changed significantly and you know what that means rather than me and if you want to talk about what that means after we can but if your threat model has changed significantly MVS probably has changed too um your threat surface has greatly expanded and specifically usually because of a merger or acquisition this is a super danger thing if you are doing mergers and acquisitions you are not MVS and you need this is a time when attackers are like oh yeah this is the best time for me to get in. I am going to cause problems. This is very

dangerous time. Um, okay. So, how to scale security gradually as your So, MVS isn't good enough anymore. I've got to do better. What do I do? So, we want to do automation. We want to automate boring stuff. That's why we work in tech. That's why we learned to write code because we did something, we're like, that was boring. I'm never doing it again. Um, so we want to automate all the things we feel we safely can. Um, ideally we would start doing advanced testing like pentests, security assessments, risk assessments, things like that. We would want to invest in perhaps more than free training. We would want to make sure that all the developers are getting some sort of

knowledge transfer and support to choose better choices. Um we want to start h first of all having processes and we want to work on improving those processes and maturing those processes. Maybe we're going to look at a framework right like DSOM ASVS etc. There's lots of application security frameworks. We want to have comprehensive monitoring. We are not shooting from the hip now. We have every app monitored and we know what's going on with them and we feel confident our apps are up and safe. Eventually, we're going to get big tools, like all sorts of tools. Yes, they cost money, but maybe they're better or they do more features and more things that we want at this point.

Maybe we create a security engineering team and we hire a whole bunch of apps nerds. Yes. Uh, and we build up like a bit by bit, right? We're not going to do it all at the same time, and that's okay. And this is the summary of this section. I don't know why the just wait back back. Um I don't uh sorry I lost my train of thought. Yeah. So sometimes good enough is not enough. Thank you. Um and so you don't have to do all of this overnight, right? No one expects you to do this overnight and that is okay. Um so what did we learn? So we talked about you know the poverty line. We talked

about and I made an analogy to apps. We talked about what I feel the minimal level of security is and when it's appropriate. We talked about what matters for small teams and what does not matter for small teams. We talked about free ways that you could get some training and how to build better culture, free tools that are actually really good. Um when you need to do better, which I feel is really important. So all the slides are there right now. Um and I'm going to show you the slide link again on the very last one when we do the one minute worth of QA time that I have left. Um, but first I have a call to action. Also maybe

known as a road map for you. So if you're thinking I'm MVS, that's where I am. I have no apps team. I do not know what to do. I would like to ask you to consider just run a dash pew pew pew pew at like your main app that is on the internet and then fix the things that you find, right? Like if if someone can just run Zap on it and find an exploitable bug, that means any can find one and and it hurt your company and your team and you don't want that. Add if there's no way for people to report security problems for you, just add security.ext to your web server space with an email and it's like see

something, say something, email me. And then please don't sue people that report bugs to you. Um, and then number three, start asking what's the worst that can happen and plan for these things because if you are on the internet, you are already getting a pentest every day. You are just not getting the report. So, like we are already having people look at us with not very necessarily friendly eyes, right? Um, and so with that, I'm going to give you a couple of free or a couple of resources very quickly. So, I wrote books and I think they're good and my mom said they're okay. So, you might like them, too. Um, I have a newsletter

with lots of free content all the time. Uh, and it's supposed to go out tomorrow if I get myself around to writing it today. Um, and with that, these are the presentation slides and I would like to ask if there are any questions. Wait for >> Thank you so much. That was Tanya Jena. And, uh, we do want to redirect you to u besides I'm sorry, besides SF.org. org uh/Q the letter N and then the letter A if you want to submit your questions. Thank you so much Tanya. We're going to be taking questions for 5 minutes um as per your request. We already have one question here um and it's coming from Ian. So even is asking,

"How should you prioritize creating an MVS posture when integrating security into pro-services organizations that operate in their customers IT environments?" >> Proer like do you mean like a managed service >> professional services? >> Okay. Professional. Okay. >> Wouldn't you have like a professional services group? Like if you've hired a professional services group, do you do you mean to do security like or you've hired them and they're just they're general devs? >> My question is somebody offering professional services to incorporate security. >> Okay, >> I'm interpreting. >> I believe the question asks if I'm running a professional services team or offering, how do I sprinkle in some security in there? >> Okay, >> I think that's what the question.

>> I thought you were even, but thank you. I mean actually like I appreciate you trying to help us understand because sometimes we get questions and I hear one thing but they've asked a different thing, right? Um I would say that if you are offering professional services, I'm assuming they're probably offering software developers and they're like I I would just train the software developers on secure coding, on application security, on how to review AI code to make sure that it's safe. So you train your team and you loan them out and then they have that culture and they understand it's important. So they're arriving prepared for their job so they know what they're doing. That's what I

would do personally because when you get there, you have to follow whatever program your client has for better or worse. And consultants usually don't get paid training on the job and other things like that. So if they show up trained, it'll be better. Um I when I first started giving training, like I would never train consultants or you know like I'd be like we have 80 people but like 20 of them are consultants so they're not allowed coming to the training. I'm like, "Well, if they sit in, I like I don't see them. It's fine with me." But like, what happens is now companies are like, "We won't hire your team unless we know they've had

training." And so things are changing now. But before it used to be they just assumed they showed up good. And it turns out not everyone was. And so, um, if you're going to hire an MSP for devs, I would say you should specify that they have a certain level of knowledge before they show up because you do not know what you're getting. That is awesome. Do we have any other questions? >> Yes. Uh we do have a question here. Um the question is um if it's not an online app, uh would you do a SAS um scan instead? How does MVS change in that case? >> It depends on what your threat model is. So let's say it's completely offline,

but it's a medical device that goes on someone's body. That seems pretty important to me. And for me, MVS would not be good enough. So I I realize this is very web focused, but I I feel like so if you're building like a little fidget spinner and it it does have code in it, but like it can't possibly hurt anyone, MVS would be fine. Like you don't need to be that secure versus there are lots of things that aren't on the internet, but that we all depend on every day that are mission critical, life critical, critical to the government or whatever. So, I would say that you would have to do a four-point safety check and ask those four

questions. And it's like, can someone die if this malfunctions? Could someone be injured? Could a person's life be altered? Right? And ask those questions. Have that very minimal threat model. And then decide where you're at. But that's a great question. Thank you. >> Yes, amazing questions here. Um, I have another question and I think that's you this is a question you'll probably get a lot. Um, so any recommendations for lowcost alerting, monitoring or sims? >> Yeah, I'm sorry. Um, that's really hard. So, usually I write the stuff into the code, but it would be really hard if you're a small company. I've worked at like a lot of like government organizations that are bigger and so we

wrote like a little service and then we sent all of our errors there and then it would email our dev team and we'd be like, "Oh, the app is down." Um, and doing customization like that can be quite expensive. You can have so like ideally you would do logging and monitoring the same way all the time, but again I'm thinking of larger companies and so you would have a module or like a function that you call and you send a certain format to it and it goes somewhere to a service maybe of the elkstack for which is free. It's law of work so you pay with time. Um, but I I would have to say that I don't really

have a great answer other than like you're writing it yourself, which is like expensive in its own way. >> That's fair. Yeah, that's it's a very difficult question to answer just in a few minutes. So, thank you so much for your input. So, that was Tanya Jenka. So, thank you so much for your time. Thank you for sharing um wonderful and valuable insight with us.