Cutting through the "shift left" fluff: Practical solutions for developers

00:00:00

Speaker 1: Welcome to the Cutting Through the “shift left” fluff Practical Solutions for developer today webcast, featuring Casey Bisson from BluBracket and Tanya Janca, that’s me, from Bright Security. And basically I was hoping, Casey, would you mind kind of telling everyone who you are so they can know you?

00:00:23

Speaker 2: Absolutely. Yeah. So I’m with BluBracket. You know, we’ll talk a little bit about what we do, but we’re in the code security space alongside Bright. My background started in engineering, and even before that I had some background in operations. Now I’m in product, really focused on how do we make that developer experience great, especially around cloud, especially around accelerating, accelerating the work that we do in a way that makes us happy, makes us proud of what we do. And so really one of the things that I love about this is when we think about a job done well, when we think about code quality security, everybody says security is a really important part of that. And yet it is also one of the most difficult things, and that’s what makes me interested in this space. So, yeah, I’m excited to be here. I’m excited about where this conversation is going to go because I know we have had some good opportunities, I think, to joust very playfully on some of these points.

00:01:30

Speaker 1: Nice. So I’m Tanya Janca and I am a nerd on the Internet, also known as She Hacks Purple. I’m that person that started the We Hack Purple community and Bright just acquired us and so now we are still called We Hack Purple but we are the Bright community. I wrote a book called Alice and Bob Learn Application Security, but basically I was a software developer for a long time, like literally from when I was 16 years old and I’m in my mid-forties now. So it’s been a little while. And then one day I met an ethical hacker and he’s like, You’d be such a good pentester. And before I knew it, I was learning all these cool security chops I was really, really interested in and just like learning more. And then I figured out that there was a job in security where you could hang out with software developers all day and they’re like my people, if that makes sense. But then you still get to do security tasks. So you basically get to help everyone and kind of cheerlead a bit. And anyway, I was like, I’m in. I still get to write code, I still get to break things and I get to talk to everyone. This is awesome. Like as a super extrovert, Casey I don’t know about you, but like, I switched into security and did pentesting and it’s a lot of me in a data center by myself for like 8 hours wearing like a toque because data centers are really, really cold. And I was like, not really. I was just like, Where is everyone? It was not the right job for me.

00:02:58

Speaker 2: You know? What’s what’s I have to say? I am actually not an extrovert. I have to, I have to pump myself up for this, this sort of thing, which is fine because I love how technology is actually so broad and it defies some of the stereotypes. And I think your point is that it takes a lot of different people to figure these things out. People have gone through a lot of different paths and everybody can solve problems. And that’s, I think, part of how I think both of us approach some of these things. It isn’t who you are or what you are. It’s what you’re committed to doing. That said, I love it when you say toque, you know, I can’t help but…

00:03:42

Speaker 1: Yeah, other people around the world call it a hat. But in Canada we have names for different types of hats and the winter hat is called a toque. And we had a windstorm yesterday. So I was actually wearing a toque, because it was so cold last night. And then, yeah, anyway, I’m off topic. So in the chat someone is saying Edmonds saying you know echoing a previous speaker and he means you Casey. Security is the most complex aspect of IT grunge right now. But I totally agree. I feel like you get to learn something new every 4 seconds and I like that. Personally, I think that’s great. And today we’re going to talk about cutting through this shift left fluff. So, Casey, can you get, a lot of people talk about it, a lot of people say shift left this and shift left out and let’s push left and blah, blah, blah. But I have often been confused by their definitions because their definition is buy our product or else you can’t shift left. And so can you tell me what you think of when you think of shift left?

00:04:42

Speaker 2: So I think we all are like, you threw that question to me because I know we’re trepidatious about this particular thing. If we go back, I don’t know, 12, however many years when we started talking about DevOps and there was a really good argument about like DevOps is a process, not a product. There are some great conversations about that that I think are really valuable for us now. But there’s of course like the org chart or the process flow definition of shift left where like stuff is done over here on the left side of the of the chart and it’s going to move through the process diagram to the, to the right side of the chart. And if you have problems over here that you’re not catching, then until, until the end, that’s they’re just going to be bigger, more complex, more expensive problems to solve. And so that makes sense in that way. But in a human way, it’s we have to recognize that the left side of this chart is business strategy, business goals, followed by product stories, and eventually that turns into engineering. And so if Shift left only goes so far left as engineering, you’ve got a problem, you know, and DevOps, DevOps could do that. DevOps could be like operations and engineering. If we can get together, we can have DevOps and things will be better. But when it comes to security, if you only go so far left as engineering, you’re in trouble. And I think that’s where the fluff is because so many of these conversations in the word I, I sort of I try around other people to never say shift left and definitely never say DevSecOps because when you say DevSecOps, you ignore dev business, you know, business and product and all of those things that are in it. So I have just talked about all the fluff. We’re going to get to some solutions, but I want to stop now because I know how you how passionate you are about this. I want to I want to turn it over.

00:06:44

Speaker 1: I think I got really passionate about it when I was a penetration tester. So as a software developer, I was learning about all this. I got a professional mentor and he was a badass hacker. And he had like a snake tattooed on his arm, he taught me how to break the stuff. And then eventually I was like, I’m really cold in this data center by myself. And, and, and quite frankly, I feel like pentesters, like they have amazing attention to detail and they are like, perseverance is like number one, like, I am not going to let this go. I’m going to find a millimeter of ambiguity and I’m going to dig in and eventually there’s an exploit there. And I’m really glad that pentesters exist. But it turned out I was not awesome at it Casey. Like, I started meeting with clients earlier and earlier and earlier, like you said, I would say to them, okay, so I know you want to hire me in two or three months to do this pentest, but would it be cool if I came back later this week and I’ll just run a scan on your infrastructure and tell you what patches you’re missing, because then you have like two or three months to patch it, right? And so then when I come in and do my pentest, you’re going to be pretty cool unless you don’t patch that whole time, in which case you’ll get the Tanya eyebrow furrow and it’s very serious punishment. And then I would say, Well, while I’m here, can I just like, what is your design look like? How does this look so far? Oh, you’re using that version of this framework. Hey, can we. And then I would bill a few extra hours and then I’d call them and I’d be like, Did you patch that yet? And my boss was like, What are you doing, Tanya? This is taking so long. Like, you’re billing 14 days and other people can do this in ten. What were you doing for those four days? I’m like ,a threat model, a secure design review, I scanned all their infrastructure, then I came back and scanned it again because two of the patches hadn’t applied. Then… and he’s just like, that’s not what you’re supposed to be doing. And I was like, I didn’t understand because like you said, right. So software developers follow this process. I’m like, Why are you inviting me at the end? And so selfishly, you look so cool. If you were a pentester and you come in, and there was no AppSec person before you and the devs were given no tools and there is like no guidance or anything and you come in, and you’re like pew, pew, pew, like fish in a barrel. I would run a DAST and I’d be like, I look like a genius. But in reality it’s like, well, they were given no support, no one’s ever checked it, no one’s let them check it. No, they’ve never had training. There were no requirements. Yeah, of course there’s mistakes, right?

00:09:22

Speaker 2: Yeah. What you describe is really very true in my experience, where companies feel as though if security is this thing that has to be done occasionally, like so many companies view security as something that they have to do for their audit, which happens at most once a year, you know, for for X purpose, Y, Z, you know, name the name the compliance certification that you need to get. Maybe the audit is every three years for that one, you know. And so those are Yeah, exactly like.

00:09:53

Speaker 1: Those are just too much.

00:09:54

Speaker 2: Yeah it’s so much of this is driven by these external requirements. I’m sure we’re going to get into a lot of other things, but I’ve gotten a lot of questions in the past couple of weeks because of the new standards on software supply chain security, n’est standards on this. And it’s like, you know what, people who can food products didn’t have standards until there were government standards around that in a lot of cases. Some of them did it well, some of them didn’t. Right? Sometimes these external things are great, but if your organization is not focused on, if your business goals aren’t focused on quality in some way, you know, this is probably going to be an onerous requirement to hit. And I think you found that same thing where when you’re talking about these patches, I mean, what kind of feedback did you get when you talk like, why did people not do a patch X, Y, or Z, for example? Like, there are reasons we don’t, but it’s good to dig into, right?

00:10:51

Speaker 1: I don’t think that they realized that there were security parts in those patches or that it matters for security. They’re like, It’s fully stable. Like we’ve had zero problems with this server for three years. Oh, and, and sometimes, quite frankly, like people apply patches and they go out and they don’t actually stick. And Casey I totally realized I didn’t answer the last question about what I think shift left is like, uh oh. So my definition very quickly of shift left is starting security earlier in the system development lifecycle because Anglophones right and like Latin languages, write, left to right. So on the left side of the page is the beginning of the sentence or the beginning of the system development lifecycle. And just like Casey said, I totally agree. You need to start with the very first step, which is requirements and give them a whole pile of what you expect and sometimes what part of those requirements are. You must run this type of scan or this type of security tool, or you must fix these types of things if you find them. And then in design, applying secure design concepts, doing, etc.. But you can’t just, like Casey was saying, can’t really use very many engineering style tools, like you can use policy or documentation style tools that kind of give you hints and tips and help you do threat modeling or help you come up with requirements. And those are awesome. Quite frankly, I think they’re great, but you can’t really, like hack away at things and like analyze things and scan things until there’s some code. And so when I met Casey, I was like, Can you tell me what your company does? Because I had met one of Casey’s interns who had worked there for like four days or something, who had tried really kindly to explain what they do. And then I was more confused than I had been before. And so I was like, Casey, could you please tell me and like, just be clear his intern is awesome. But can you tell me what your company does and sort of like how you’re trying to solve some of the security problems, because that’s the part that is…yeah. 

00:12:59

Speaker 2: I totally need to jump into this question, you know, to make sure we get that marketing pitch. But I want to before I do that, you know what you…because we’re here to, I mean, as much as anything, we’re here to help understand some of these things. And the point you made about English language things moving from left to right is I don’t know if you’ve ever used this approach to try and change your viewpoint on something. If you take a DAG and render it from right to left or bottom to top instead of left to right. Have you ever tried that sort of thing just to see like, does it change how you view the problem at all? I am always looking for anything to help me see something in a slightly…like and so just phrasing something. And before this we do that instead of and then and then we do… anyway. So that simple approach is trying to change that thing. Back to what BluBracket does. We are really, really strongly focused on code. The two things that you’ll find in your code. There is both the code, the functional, the functional risks in your code, the behavioral risks at runtime in your code, but also the intelligent risks in the content of your code. You know, on one side we have what the code does or sometimes doesn’t do and how you can take advantage of that to get into to take advantage of a system. But when you get access to that code and as we know too often too often their secrets in code, the code gives a lot of hints about what systems it connects to. Sometimes, if you haven’t got dynamic discovery implemented, you know the code will specify names and or even IP addresses. We know that’s not good. And so we definitely know that when we have the passwords or keys in the code, that’s a huge problem. Those intelligent risks, intelligence risks of the content of the code that we take it, we which is to say, we are people who code and take advantage of systems. But there are some people who do that for nefarious purposes and they take those secrets. They take those signing keys. You know, imagine if you are a phone manufacturer that has secure hardware in your phones and you need to have keys to sign the code to use that secure hardware. And now your code has been distributed on the Internet, let’s say February 2022. How do you secure those that hardware now that the signing keys for the for that stuff are now out there publicly, That’s a huge security breach and we as much as we love open source, as much as we love things to be open and everything to be accessible, information wants to be free, we nonetheless, in order to secure some things, have to have some secrets. And the secrecy of our private keys, the secrecy of our passwords. When we put those in our code, we have to recognize that even private repos aren’t private repos. When you have to share those repos with tens, hundreds, maybe thousands of people to get the job done. And so our approach to this is make sure you recognize the risks in your code for what they are and help guide people to practices to eliminate those. So throughout that code process, whether it’s in your IDE, pre-commit on pull request and reviewing the history of of of all your code, helping you find those intelligence risks in the content of your code, whether it’s secrets, PII, non-inclusive language and other things, that’s the core of what we do and helping you find those, that adds up to about half of all of the risk in your code. And we’ve seen that in a series of attacks in 2022 where attackers have, threat actors have done a lot of adjacency attacks using secrets in code to jump from one system to another and really made 2022 a banner year for some, I would say objectively exciting, exciting tech stories. So that’s what we do. But what I heard when I heard what Bright does, like I got really excited about that. So could you share what Bright does?

00:17:09

Speaker 1: Absolutely. I also just discovered that all of the comments I was responding to in the chat I was only sending to other panelists so no one could see. So now you’re going to see comments from me in the chat. Awesome. We were discussing how Rust, the programming language, is really awesome and it has a lot of security built in. But anyway, Bright Security does two things. So at first we did one thing and now we do two things or we do the same thing two ways. So we built a dynamic scanner. So when I was a software developer and I switched into security, the very first thing that I learned was dynamic scanning or sometimes called a web app scanner or web proxy, or what we like to call it in the industry is a DAST, a dynamic application security testing tool. But basically. You point it at a web app and then it interacts with it and then it finds vulnerabilities. Or as me and Bar one of the founders like to say, you go pew, pew, pew, pew. And it’s true. And it sounds so silly, Casey. But the first time I ran a dynamic scanner, I’m like, I am a hacker now. Like, I felt really powerful and awesome and I thought it was great. And so traditionally, people would use that in various phases of the system development lifecycle. So it used to be, well pentesters come in and they’re the only ones allowed using those tools and blah, blah, blah. And then eventually it’s like, oh, well maybe we could have QA and they could be allowed using those. And then software developers were like, wait a minute, I could just check it and find those things now and fix them now. This is awesome. And so what Bright did recently is ,so the very we’re like, we want to be more left. We want to be earlier in the system development lifecycle. And they just… so when I started my first AppSec program, I’d been on the dev team and then I’d switched to the security team. I had managed incidents for months and the most of them were software incidents. We had a lot of legacy, there were a lot of problems. And so my solution to this was I’m going to teach all the devs how to use a DAST scanner. They’re all going to go pew, pew, pew, they’re going to fix the highs and criticals and mediums if it’s one of these important apps. And then we’re then we’re going to release to prod and we’re not going to do it until then. And our code quality went like this, like even legacy apps And like if you open a legacy app, I don’t care if you think you’re going to prod and you haven’t scanned it with my DAST scanner, I’m going to be really upset. And so Bright was like, Well, what if we could do it in unit tests? So, you know, it takes a while to run the whole scanner and do all the things, especially if someone’s not super like a ninja with it. And so basically when you do a unit test, so devs write unit tests to test tiny units of code for anyone that isn’t aware. Like what it does is it spins up a tiny little web server and it runs that little part of code and then it runs your little test against it and it’s like, yay, the code still does what it’s supposed to do. Or when you fix that bug, dude, sorry, you broke this part and it’s regression testing. It’s like, what if we. And so I’d been talking for a long time about taking a copy of those tests and manually creating security tests, and then it can test that it does not do what it should not do. It only does what it’s supposed to do and not my bidding as evil Tanya the pentester. And so basically they’ve automated that process. And so you just if you have the… if you’re doing JavaScript, there’s a JavaScript SDK and you just include it and you just tell it, okay, So point here and then it duplicates and makes its own tests and then does dynamic scanning right at the unit test. So every time you check in, it runs all of these things and checks that you did not make a security bug when you added that new feature or whatever you did. And so I’m pretty impressed. And I don’t know, we’ll see. Like we just started showing it literally this week. Casey And the first thoughts are like, woah, we’ll see if people do it right because like Casey Have you ever worked somewhere where they have 100% unit test coverage?

00:21:11

Speaker 2: No. Nobody’s ever…but I love, actually forgive me. I mean, let me jump in there, because what you just described, I think, is really, really important. If you ask, there are so many people who cite surveys that only 40% of developers cite security as a priority and or as the number one priority. And I’m like, well, that’s actually a little too high anyway, right? The number one priority is to deliver value. Security is a necessary but insufficient requirement. Right? And so and so we used to when you put it in the context of code quality, I think that helps really contextualize how we approach this. Everybody knows that you can ship code, that that solves a problem but is a poor quality. And then you get into a conversation about why do you not want to do that? And do you remember the conversations that that I don’t know, maybe it’s five years a little more ago that there was a lot of excitement about the TenX actually, let’s go further than five years, maybe ten years ago, but the TenX developer, right, who could deliver TenX more productivity than their peers. And that’s why we need to hire more of these people. We don’t talk about that anymore. And I’m really, really, really happy. Not because, you know, but I think that the TenX developer really promoted this idea that you could sort of cowboy your way through problems and not update unit tests and do one thing after another. And I think as organizations, we’ve recognized how it isn’t the individual productivity, like individual individuals matter, individual excellence matters and we want to find ways to promote that. But what really matters is a team TenXing their productivity. Right? And when you can get that whole team and the things that we do around unit testing and having and doing test coverage, measuring code quality by test coverage, like when you and I can talk about does anybody have 100%, nobody has 100% test coverage, but we measure test coverage now and and we know that better test coverage means the whole team can be more productive. We don’t have to find that one person who knows that part of the code and how it’s supposed to work. The tests are documentation and guidance to the people to jump in and solve problems, and that’s how you make really productive teams. And when we approach security that way with that kind of automation, it’s a huge help. And so thank you for positioning what you’re doing and what you’re talking about in that way. And it’s exactly what we do from the BluBracket side, like give people automation that gives them the guidance to see and evaluate code quality. And so, yeah, I really love that.

00:24:03

Speaker 1: In the chat, Edmund was saying I’ve seen JavaScript at 95% code coverage, but it still sucked. I’m sorry to hear that. That sounds not very good.

00:24:16

Speaker 2: And let’s be clear. Forgive me. I mean, code coverage is a proxy, but not a real measure of code quality, right? There is…it isn’t perfect. And how you measure code quality is a really subjective thing. The real question, I think, that we have to do is what are the ways that somebody can get in and make changes to the code and know if the code, if those changes have unintended consequences? And I think from both of us and this is what I love about Bright, is that it really does those two risks in code, those behavioral risks that Bright addresses with DAST automated scanning and those intelligence risks that BluBracket solves, solving that entire picture. And that’s why I’m so glad to have both of us here with that common, that really common approach like that automation around the developer experience to give that guidance like this is good stuff, this is bad stuff. And as we’re reviewing the code and looking for ways to improve the code, we get that automated guidance. So that’s great.

00:25:26

Speaker 1: In the chat. In the chat, Edmund is talking about how do you get quality into code unit tests? It seems like it could be language specific and just not sure that quality specifically can happen from there. But I would say that. When you write a unit test, the idea is that it tests that your code does the thing it’s supposed to do. And I don’t know about you, but I have opened up an old app before to fix the bug and then accidentally made a new bug or just made the bug act in a new way because I didn’t test it thoroughly and there were no unit tests. And quality is also weird, right? Just like Casey, so you’re so true. Like I remember years ago, I had this like a billion old apps that my team was supposed to support, and I opened one and it was 1000 years old and there was like, cobwebs. And I was like, okay, well, now the date format is correct. I’m out of here. And then one of my junior devs, I assigned it to him and I was like, You’ve been working on this bug for like three days. It was like the next month and there’s another bug and he’s like, No, it’s fixed now, it’s fine. And so then later I had to go back. He had rewritten the entire app because it was so crappy. He was like, I just couldn’t stand it. Yeah, he was really smart, but I was just like, okay, so that bug is really, really, really fixed now.

00:26:54

Speaker 2: And that gets to I mean, and I think it’s worth saying, like there’s no aspect of unit tests that are going to improve. If you’re not happy with using one language or another, it’s always going to be that. Or if your approach is always to use spaces instead of tabs, we can have those debates. What unit tests do is, like, is it passing this test or not? Regardless of style arguments and regardless of preferences about one thing or another, does it pass this test or not? And if those tests are sufficiently well written and that’s always a question, you know, but if those tests are sufficiently well written and that’s a little bit easier to judge than some of the style questions, then if it passes those tests, you have some confidence. Is it perfect confidence? No, but it gives people a lot more confidence that it’s going to do the job it’s supposed to do regardless of those changes. And that gets to probably why when you talk with people about applying patches or upgrading a library to X, Y or Z, you get a lot of resistance because so much of so much old, so much old legacy code just doesn’t have those tests around it. And it’s hard for people to make those changes. So, yeah, it’s an interesting thing.

00:28:08

Speaker 1: Yes. Yes. And like another thing with unit tests, unit tests are regression tests to make sure we haven’t added a mistake, and until like now, really? You’d either have to write your own security unit test so now you can automate it. That’s awesome. But on top of that unit tests can’t tell like, Oh, this was written 20 years ago and the dev put 400 secrets in it. And that’s why sometimes people are like, Oh, so I’ll just buy this one tool and then I’m good and I’m like, No, you have to look at your code from a few different angles. And I usually say like, there’s this three core angles you need, and one is like a dynamic scan. So basically like interacting with your running application and you can do that manually, You can do that with IAST. There’s like a bunch of ways you can do that, but you need to interact with it running. Then you need to look at the code your team wrote like specific, the custom part, and then all the code your team didn’t write. That’s still part of your app. It’s like a library, a framework, etc. And then if you want to talk about more, in my opinion, also, whatever it’s sitting on can’t be completely on fire. And so when you look at those things, your app is secure and then hopefully it’s sitting upon a thing that has been patched this centry and then and then you’re like, you’re doing a lot. But that’s the basics, right? And lots of companies I talked to Casey, they’re not even doing, they’re doing maybe one of those three, and they’re only doing it on a small percentage of apps. I’m like, You need to spend all your time automating, setting it up so that everyone is getting a report and everyone is getting this stuff and and stop obsessing over like, well, there’s 34 lows on this and let’s talk about those lows. You have 80% of your apps not scanned at all by any tool.

00:29:51

Speaker 2: Yeah. Yeah. You know, it’s interesting. In an earlier conversation, I think you and I were talking about how security is a process, not a product. But part of that process is automating where you can. And that’s one of the things that I think both of us are incredibly passionate about when we look at the known vulnerabilities, known risks. If you are not using some automated solution to scan for those things, I help you identify and prioritize them. You’re wasting time. You’re opening yourself up to unnecessary vulnerabilities and everything you just described. But then there’s the stuff you don’t know the architecture of your app, for example, which opens itself up to misuse and things that, you know, anything that you don’t want that’s harder to test for that requires a security mindset. That’s where you want to invest. If you’re going to have a pentest, if you’re going to have somebody look at those things, you want somebody to help you identify the architectural errors, right? And hopefully do that before it gets to a pentest. But when you can automate finding these known risks, whether it’s the behavioral risks in code that Bright can do with DAST or the intelligence risks in the content of the code that BluBracket can do. When you apply that stuff through the software development lifecycle, give people early feedback to make those corrections. I think you help position and what I’ve what I’ve definitely seen is you position more people to be thinking about and asking questions about real security problems. I’ve seen so many code review processes where they focus on style issues and not enough on functional and architectural issues. A style based code review is a waste of time for me and I’ve seen an incredible, actually it’s an encryption bug, pass through an incredible amount of code review that nobody caught because we didn’t spend enough time looking at the functionality. And instead there were debates about easy things. And so we could get into a great conversation about what is good code review versus not. But when you automate, if style is important to you, great, automate the style checking. We can do that. We have. There are a lot of solutions for that. But you know what? Automate security checking. For us, we integrate especially well at the pull request process. I know Bright integrates well through the SDLC, but when you can give people that feedback so that you can get, Hey look, this thing is not passing this test and that’s a security test. And with a relatively small improvement, you can improve this. And now people can talk about real stuff without having to invest arguments in whether that’s a real vulnerability or not. So that’s from my experience. That’s great. I’m noticing some of the comments.

00:32:43

Speaker 1: There’s a comment in the chat that automation does not mean that you’ve kissed the ugly frog and it turns into a charming princess. But I think it’s that you kiss the frog and it turns into a prince. But as the saying goes. But I agree. Automation doesn’t solve every problem. But automation, so I used to work with this guy named Steve Murawski at Microsoft, and he is like the DevOps guy. And I remember he made this slide for me of this dude pushing this giant boulder up a hill, like Atlas. Yeah. And he’s like, We do automation to avoid toil and toil is repeatable. Toil is devoid of enduring value. It is done like where it scales linearly instead of exponentially. And it’s like and it’s boring and we spend the time to automate it, so we get to work on the cool stuff. And I was like, This is why I like working with you, Steve. You’re brilliant. Like, just that simplification of the problem, if that makes sense.

00:33:44

Speaker 2: I used to be really, really adamant. Since I moved from engineering to product, I’ve changed. I’ve softened on this one point, but I used to pound my fist like, like young and arrogant people can and say, don’t do twice what you can automate once, you know, and I have a different calculus around it. But it is it is the point like if you don’t automate and and there’s a lot of alignment here that I’m hearing like if you if you don’t automate the boring parts of security and then you try to make those interesting, that’s a waste of time like and so either you’re making them interesting and that’s a waste of time or you’re not doing them, and that’s a real risk because if you’re shipping that kind of risk without the kind of automated checks, you’re opening a wide open door for people to just walk through and you’ve seen it through your pentesting activity. I’ve seen it from the other side in cloud where I’ve worked with customers who who I’ve helped discover, helped them discover some things as I’m helping them do this transformation into containers from previous part of my career. Like, Hey, did you realize this is going on? Right? And no, they didn’t realize that X, Y, or Z was running. And so, yeah, interesting, interesting stuff there.

00:35:03

Speaker 1: There’s a question in the chat from Trent that I thought was really good. Sorry, I know you’re on a roll, but I really like the question. And because there’s so many comments in the chat, like scrolling way off the screen, I don’t want to miss it. So Trent was saying, how do you promote developers’ mindset to develop more negative unit tests? So most unit tests are positive tests. It’s like, does it do what it should do? A negative unit test means does it do all sorts of stuff it’s not supposed to do? So can I hack it and manipulate it? There are some of the hardest to get into the mindset to write any recommendations. Do you want me to start answering or would you like to start answering?

00:35:38

Speaker 2: Oh, I think I think both of us are going to have some fun. But yeah, like I want to go for it from, from my perspective, I agree with the challenge. At the same time, it’s the sort of thing that progressive improvement, the use of the retrospective process, like when you see how things fail despite passing tests, it helps with that. But you do have to have a strong culture around automation and the use of tests to get to that. I don’t have a perfect answer, but I’m eager to hear what you’ve got.

00:36:14

Speaker 1: So usually, like when I work with software developers. So when I was a software developer, I remember I would ask questions, so why can’t I use store procedures anymore? And they’d say, Because of SQL injection and like, but what? like, explain? And they would never explain. Like, okay So if you use a stored procedure, basically it takes and, specifically a parameterized stored procedure, which they never specified way back then, but basically then it takes away all the power of the parameters and is treated just like data. And the whole thing about injection vulnerabilities is when your attacker code is accidentally treated as part of the code from the application, so then it’s trusted and it’s interpreted and it’s run and bad stuff happens. And so if you use a stored procedure, it disables that possibility. like okay, I’m in now, but they just wouldn’t explain that. And so quite often I’d say why this? And they just get so frustrated with me. They’d say, Because security Tanya. And I realized it’s because they didn’t know the answer. So. So the first thing I started doing was saying, I’m going to show you a thing and why I’m worried, then we’re going to talk about why it’s scary. Then we’re going to talk about how we can find it, how we can smash it and how we can make sure it never happens again. And so I’m like, This is a fake bank that my friend Nicole made. It is a web app that’s intentionally vulnerable and we’re going to break in and we don’t need a password. And then I’m going to steal their people’s sessions and steal their money. And everyone’s just like, We’re doing this at lunch. I’m like, Yes, and there’s bagels. Come join me, and just show them the thing I’m super interested in. So when it came to unit tests, I remember the team that I tried to start this with. They said, We only have 30% coverage. I’m like 30 is way higher than zero. This is awesome. I’m like, let’s just. So we had cross-site scripting at that place which makes it…

00:38:12

Speaker 2: Which you don’t you don’t introduce as a feature. To be clear, you’re not declaring that as a feature.

00:38:18

Speaker 1: Not a feature. And so I was really worried about it and I gave this deep dive into cross-site scripting because we had lots of it. And so I said, You can just take your unit test, any of them that take an input and any of them that put something to the screen, anything like that, make a copy for me. And then here are all the different, like there’s this OWASP XSS filter evasion cheat sheet that’s totally maniacal and I just copy these in one at a time. And if it passes all of these, you’re a monster. You’re totally awesome. And so one Dev wrote it, another one’s copying it. And then basically cross scripting started disappearing from at least 30% of our code. And so basically this might sound silly. I don’t want to say hold their hand, but I mean, show them an example, like do a proof of concept with them. And I wasn’t expecting them to test everything under the sun. But I’m like, we have cross scripting and 100% of apps that I’ve tested so far and that makes me frowny face, uncomfortable, stressed out. And so what if instead and so and, and then when I gave the deep dive and I was explaining you need to use an approved list for input validation, you need to use an approved list like stuff that’s cool is allowed in there like yeah so I blocked single quotes, I blocked double quotes. No, no, no, no, no. Not a block list. And like explaining the difference and I remember one dev we like went back and forth all day. I’m like boom got past this is what I use. And he just kept making his block list better and better and better. And I kept trying to explain, white list is what it used to be called, like an approved list. And so I was like, I don’t mean to be weird, but can we pair program? And so we’re just coding together. And I’m like, like this, like the opposite of what you’re like. You’re making it too hard, dude. It’s a username. It’s allowed this, this and this. So we just say, if it’s not this, bye bye. And then he was just like, I’m going to fix this in all my apps right now, I know exactly what to do. Go away. I got this. And from then on, he never, none of his apps like he would fix it in all the old apps and here’s like really awesome so like I tried to show them it doing something and make them feel empowered.

00:40:33

Speaker 2: I apologize. I stopped, but what I’m excited about is how you’re really demonstrating how some of these things really come down to, you know it’s a process, not a product. And I don’t think anything about this is intended to elevate the process over the outcomes. That’s not my point. But that’s not a that’s not a product thing. It’s the sort of thing where, yes, a product can help you identify some of these things and, and, and that’s great. But solving them and solving them in a real sustainable way, it really is what you did in a one by one progressive continuous improvement model to help people understand that, and it starts with exactly what you described. I like to talk about two types of CISOs. There’s the CISO that is out there identifying problems, identifying the best vendor to solve that problem, then working with the teams, including the engineering teams, to implement it. And sometimes that CISO moves a little too fast and doesn’t always get the buy in and the understanding. And then there’s another kind of CISO that you will never meet as a as a vendor in that space, because that CISO spends their time working with the with the engineers, role playing and and gaming out different threat models and doing the things that you describe and helping set requirements that then the engineering teams have to go figure out how to solve. And in that approach where the engineering teams are driving the solution after they understand the problem is a really, really interesting one. And what you highlighted there when in a moment when you said, Tanya, just do it. It’s a security thing. Like if your approach to security is that. If you can’t demonstrate, if you can’t take that unit test and show how you can inject an SQL attack or a cross-site scripting attack, it’s going to be really, really difficult to get that buy in. And so I think your answer is right on. And we have to. It’s true everywhere, across everything we do I think. If we can’t talk about why and truly and get buy-in on the why, it doesn’t matter what does not matter. And so really appreciate your story because I think it helped really highlight that I thought you were going to. Sorry. No, no, no.

00:42:59

Speaker 1: I feel if you’re going to work in AppSec and you can’t make just any exploits because there’s exploits available all over the OWASP site, like there’s so many places where you can get things that you can copy and demonstrate and show off, right? Like, if you can’t demonstrate anything, it’s going to be a hard battle because essentially, if they don’t feel you’re one of them and you understand their struggles and you don’t, because I’ve worked with AppSec people. Okay Casey, I’m going to tell you the most awful story. So I started working somewhere and I was joining an AppSec team and I was so excited. And so usually security is all dudes. It’s always me in a meeting with like 30 dudes. And so this team, the boss was a woman who was super highly technical, and there is another woman on the team who was just like, I own the DAST, that’s all I do. And I just scan everything that moves. And then there are a whole bunch of men on the team who had been transferred from policy and they didn’t know anything about coding, they didn’t know anything about the SDLC, and they would just like talk down to the software developers in this really awful way. And I was like, How would you feel if someone was super condescending and mocking of you in your profession? Would that feel bad? And I caught two of them in a hallway one day, and they were making faces at each other. And there I guess they had finished a meeting. And one of them was like. And the other I was like. And like, what are you guys doing? And I kept laughing and laughing. I’m like, No, what are you doing there? Like, it’s an inside joke. And I’m like, Tell me, tell me. And they’re like, We’re practicing the faces we make for when developers ask us questions in meetings so they can know how stupid they are and they can stop asking. And I was like, I have to go. I’m really, my mind, like a lot of my feelings will just fall out of my mouth. So when I told my boss, I’m like, They’re not allowed talking to devs anymore. This is why no one wants to meet with us. This is why no one wants to talk to us. This is why they’re not allowed talking to devs anymore. Make them write cool policies, make them do 100 things, but don’t let them speak to software developers. Like, how would you feel if someone was like, That’s so awful. Yeah. Yeah. 

00:45:16

Speaker 2: So many, so many parts of a company are there with the role of trying to turn strategy into something that is actionable value. And developers have that in such a real way. And when developers are faced with somebody who and things that I’m trying to ,I’m trying to… like that story, by the way, there’s no I mean, there’s no way around that story. But what I want to articulate here is like, let’s say it’s the perfect, you know, none of that happened because that is ridiculous. But let’s say that it’s somebody who’s really focused on policy, but that policy isn’t connected to the business strategy and the value creation. The developer is going to find a way to work around that policy. So in the best of circumstances, the best intentioned security person, security policy person is going to struggle to have a good conversation with the developer who faces one issue after another, one demand after another to create the thing that they have to create. When you add any of that on top of it, it is just truly impossible. And so it isn’t that the developers don’t respect security. They don’t respect people who don’t, who aren’t willing to have a conversation about here’s the path to value. And these are the obstacles that we have to overcome, to get to value. And security is one of those, but it is not the goal. And so if you add any amount of disrespect for the developer in their role in that, it’s a real, real problem. So, yeah, that’s crazy.

00:47:12

Speaker 1: Oh, it’s ridiculous. We have a question in the Q&A section from Oscar. 

00:47:16

Speaker 2: Yeah, we’ve got to go back to warm, we gotta get back to happy things because like little bobby tables, that’s happy stuff. But yeah.

00:47:25

Speaker 1: So Oscar asks, any tip, any tips on creating a security incident plan? And I’m going to start off Casey with, so with Bright acquiring We Hack Purple every single We Hack Purple course is now free. So if you go to community.wehackpurple.com and you look at the AppSec Foundation courses level three has an entire section about software security incidents, how to stop them from happening in the first place, how to prepare, how to get your toolset ready, and then what to do during a security incident. We also give you a post mortem report, an incident report, like all the things. So go to community.wehackpurple.com sign up. It’s free, all courses are free. There’s no upsell, you don’t have to buy Bright to get it. Although we will invite you to cool stuff like this from Bright but yeah, we have all sorts of events all the time that aren’t about Bright and so yeah, I hope that answers your question, Oscar. But Casey, do you want to add anything about security incidents?

00:48:22

Speaker 2: You know what, I’m going to be honest. You know, from my experience on the developer side, there are people who handle that much better. I think you’ve been, I think your work in planning that. So the availability of those things from We Hack Purple is a huge value to the community. So that’s really super exciting news.

00:48:44

Speaker 1: So cool there’s a secure coding course and a full three course application security program. There’s like how to use the Bright tool in a CI/CD, but there’s like all these totally unbranded courses available and anyone in the world can take them. You do have to follow the code of conduct and be nice, though. That’s it.

00:49:04

Speaker 2: Absolutely. You know that there was a question I mentioned earlier about the challenge, and I’m not going to read it exactly because I think but the challenge of shift left when it turns into, I think, new requirements for developers. And I think we kind of have to highlight that in terms of when security requirements are dropped on developers without changing the business requirements. That’s not shifting left. That’s dumping left. And it is. It is. I think there’s things that you and I have talked about today and are really passionate about, and it’s lucky that Bright and BluBracket both have solutions in this space that help automate. But real shifting left and security from it requires the security team to do the work of making security part of an expectation and measurement of security outcomes, a part of the business strategy, the business goals. And part of those stories. You know, one of the reasons we don’t get the negative unit test is that we don’t describe some of these things in our product stories. Right. You know, and and and so including those things, obviously security is necessary but not sufficient. But when we include those things and go that far left with these things, we do so much better with those outcomes. And I really want to call that out. And I know you have some thoughts on that as well.

00:50:32

Speaker 1: No, I, I definitely agree. I believe that we should change project schedules. So one of the things I often suggest to new AppSec people is become friends with the project managers, show up at the project kickoff meeting and explain there is going to be at least one sprint that’s just about security. It’s going to be two weeks or three weeks, whatever they’re doing. And in that sprint we’re going to go through all the things that I have in your backlog and you’re just going to smash those bugs. I’m also going to meet you for threat modeling. I’m going to do you’re going to be my golden child for those two or three weeks, and you’re not going to take that time to just fix other bugs in the backlog. It’s the security team’s time, because when we don’t add time to the schedule, I’ve seen it where they’re like, Oh, well, the software developers will just work overnight. You know, they’re humans, right? You know, they’re human. Oh, well, they’ll just work a bunch of weekends and they’ll do this and they’ll do that. I’m like, That’s not reasonable. And if I were them, I would resent our team as well. We need to be there at the beginning and plan for these things and make our expectations clear. When our expectations are unclear, they’re often not met. And does going to project meetings sound super thrilling? Not really. It’s not exactly like the movie Hackers. It’s slightly different. But then we don’t have a bunch of devs that are being crushed and trying to choose between, you know, my boss said this is coming out Friday and it just doesn’t matter. And you said this is scary and critical. I don’t understand it. I’m looking on the Internet. I can’t find an answer. I don’t know what to do. And it’s like that’s like a rock and a hard place. And if we don’t put people there, we’re going to get what we want more often.

00:52:14

Speaker 2: Yeah, Yeah. I don’t think there’s any company that wants to ship a product that doesn’t solve the problem. And we all talk about that. What is that minimally viable product? And when we can get the definition of minimally viable to include those security capabilities, we change the schedule so that it doesn’t, it isn’t necessarily, I want to be careful, of course, it adds time in some way. But it is, when you can approach those things early, It doesn’t add nearly as much time as it does to stop a project and then take the time to fix it at the end. So yeah.

00:52:52

Speaker 1: Okay, So we are almost at that time and I’m trying really hard to not go over because I talk a lot and when Casey and I met, we were just like. Like it was like. We get along. So, Casey, I wanted to ask one more question, which is totally off topic, but I think is important. Does BluBracket have free trials?

00:53:13

Speaker 2: We have free trials. We have a complete freemium model. So you can try BluBracket. You can try BluBracket completely free, use it as long as you want, and we encourage you to take the time you need. Because really, when we talk about something that has to fit into the SDLC, something that you have to get comfortable with, with that, reviewing your pull requests and giving you that kind of feedback, you want to be able to, you want to be comfortable that you can do that and try it out for a while without having to make a snap decision about whether you want to, whether you want to make that paid part of your life. So we encourage everybody to go to BluBracket.com, add a repo. It takes just a minute to start improving your code security with that. So thank you for giving me the opportunity to let people know about it. 

00:54:06

Speaker 1: Well, I feel like there’s a lot of, I guess the old guard of AppSec tools where you have to make an appointment and sign an NDA in order to see their product. And when I was making training videos that made life really hard and I’m like, Well, I’m not going to show your product. So I’m going to use all of these free products and all these other things. And I remember I would take training on DevOps or DevSecOps, and they would just be showing me these, these free tools and I’m like, Well, what about these paid tools? And they’re like, It’s going to cost us like $30,000 to have a license to that and we’re going to have to sign NDAs. So that’s awesome because quite frankly, I want to try it. So Bright also has a free version, so you can run 5 hours of scans a month for free. You can use our API schema editor because your API won’t scan very well if your definition files are kind of a mess and the unit testing all for free up to 5 hours a month and it goes really fast. So 5 hours does a lot. So awesome sauce. So you don’t know this Casey but you do know we, so BluBracket and Bright and Salt and Snyk and with the Wiz.io, and I always blush when I say the name of that company, we’re having a party in RSA on the Tuesday at RSA in San Francisco and we’re going to meet there and then I’m going to ask you 10,000 questions about your product. I fully intend to corner you and be like ok Casey, what does it do about this? How does that work? So if you are going to RSA and you want to corner one of us and ask us for all the details, you totally can, there’s also going to be snacks, from what I’m told and all sorts of other cool things happening. But yeah, I’m really looking forward to that. If everyone wants to come to the conference, like if you’re coming to the conference, you can come to the party for free and you can sign up. Just follow Casey and I on social media or go to our site. Like basically if you go to Brightsec.com or BluBracket.com and that’s B-L-U and then bracket, there’s no E there, then you can join up and sign and come see us and hang out because I would love to answer more questions because there’s even more in the chat. I’m like just losing track of it, which is awesome. Thank you everyone for your questions. But thank you, Casey, do you have a closing thing you want to end with?

00:56:25

Speaker 2: No, I really, you know, I think we need to do a QA session at the party, that would be a lot of fun. I’ve really enjoyed this time, this opportunity to talk about the things that BluBracket does, things that I think I’m passionate about, and to discover the shared passion for automating, automating security for the developer experience. Really, really appreciate this chance to talk with you. So thank you so much. Excited to meet everybody here who will also be going to RSA and wish everybody a great day.

00:56:59

Speaker 1: Everyone at Bright wants to say thank you to you and BluBracket for coming because we invited them to come do something with us. And they said yes! And that is always awesome when you invite someone and they say yes. So thank you and thank you everyone for attending. We really appreciate it. And I love it when people ask a lot of questions and have a good conversation in the chat because it helps us decide what to talk about. And we don’t…we had like this short list of questions and we didn’t even get halfway through it. So it’s really awesome. Thank you for making this like a great conversation. And Casey, I’m still going to follow you and bug you on social media.

00:57:34

Speaker 2: It’s mutual. Truly, really appreciate this time. Really appreciate all the questions from everybody and huge love to Bright for helping pull this all together again looking forward to seeing everybody at RSA.

00:57:48

Speaker 1: Awesome. Thank you. Bye, everyone. See you all later!