How Not to Roll Out a Security Tool: A Tale of Broken PRs and Regret - James

very much. So, Wednesday afternoon, an open plan office. I have a spreadsheet of vulnerabilities in front of me. I've been triaging since 8 about 40 findings in several hundred to go and there's product that has to grab today. Customers are expecting [laughter] then a tap on the shoulder. James, can we just turn it off? >> [laughter] >> It's the CTO. My reaction, no, absolutely not. This is really important security work. This is literally what I was hired to do. I switched on a new security scanner that morning, roughly 9 hours earlier. Nothing had shipped since, not one service. Every pipeline was red. And it was red because of me. >> [laughter] >> I'd argued, I'd lost, and it was off

before the end of the day. The CTO was right, and it took me a long time to understand why. So, before I start, this is not sponsored. Um, this is a previous employer for my history, not my current one. And everything here is mine, the opinions, and unfortunately the decisions. So to explain why the CTO was right, you need to know who was standing there. And it wasn't a security team. It was me. I'd been a software engineer for most of my career. 6 months prior to this event, I had moved into the dev sec role. I was the only security engineer at the company. So very small team, very aligned. Security wasn't something the business

was heavily invested to at the time. There was no tooling at all when I got there. which gave me two things. Everything was green field. Nothing to inherit, nothing there already. And there was nobody in the book building qualifying to tell me I was about to do something stupid. The company was mid migration from a monolith to microservices and nowhere near done. New service on the left, small, modern, someone actively cared about them. On the right, a decade of old PHP in AngularJS all baked in to the same deployable. That monolith was the main product. So I bought a software composition analysis tool, SCA. Sea reads the dependencies and tells you which ones have known vulnerabilities.

I was genuinely excited. First real security tooling the company had got. Felt like we're finally doing security properly. That being said, default configuration is a phrase I'd now like to see carry a health warning because the default configuration was fail the build of anything medium or above. So what did I expect to happen and what actually happened? I was expecting two very different afternoons. What I'd expect is was developers would understand the findings. A few broken builds clearable an afternoon and honestly I thought people would be pleased. What actually happened was the tool had no concept of whether anything it found mattered. Medium or above build failed. That was the entire decision engine. The output wasn't written for humans let

alone developers. Just a wall of things that were technically true. And then the monolith 10 years of PHP, AngularJS, jQuery, all baked into the same thing. Not fixable in a month. Definitely not for lunch. The newer services were patchable. Uh some of them we did patch by hand at that day by speed, which felt heroic, but was in fact just a very expensive way not to have a process. So the damage from this was every pipeline in the company was blocked. Nothing shipped. The product was meant to go out didn't best part of engineer engineering day gone. Mine a lot of people who hadn't asked any of this and by mid afternoon a CTO asking why we

could not release. And the last one that was a new experience for me and I'd rate it poorly. [laughter] Honest admission, I can't tell you how many hundreds of findings were genuinely exploitable. I never measured it. Educated guesses a fair few were front end issues. I honestly couldn't tell you about the back end. I'd introduce the control that produced a number I couldn't interpret and I let that stop the business. I hadn't secured the pipeline. I'd trained the engineering team to route around me. So, some of you told me that you have um rooted around the pipeline, root around the control. So, it's good to know. Um [clears throat] but I reduced no risk that day. What it

did was teach a group of very good engineers that security is the thing that stops you shipping and the correct response is to find a way around it. That lesson stuck a lot longer than the act did. How we think about it now is you have uh like a modern car uh you have lane assist that nudges you back in when you drift, brakes that come on when you're about to hit something. What it doesn't have is a handbrake that engages at 70 because a warning light came on. [snorts] I fitted a handbrake and I fitted to every vehicle in the company the same morning. So what do I do? What I do instead? Know the output before it's live. Seems

simple, but definitely know the output. I switch on the control ever having read what it was going to say. I could have shown the warnings, but I chose just to enable it to block everything. That's the actual mistake. Everything else is downstream of that. Read all the findings. It will cost you an afternoon, maybe a bit longer. Well worth your investment of the time. If a number's in the hundreds, you don't have a tooling problem. You have a program of work and you plan it like one with dates and people, not with YAML files. And it's the same rule for infrastructure as code, secret scanning, dynamic scanning, etc. Never enforce a check whose output you haven't read.

Second mistake. I treated one estate as one problem. It was two problems wearing the same continuous integration config. In a modern application, the baseline is zero. Every finding is new and new findings are cheap. You can block here from day one. On a 10-year-old monolith, the baseline's in the hundreds. Blocking there isn't a control. It's a freeze with extra steps. So, a legacy, hold the line. Hold the line on what's new and work the backlog on its own schedule. Separate plan, separate dates, separate conversation. I didn't see that at the time. It was all or nothing. And I went with all because I was 6 months in and full of ideas. And sometimes there is no patch. The

front end was AngularJS. Um jQuery some parts of it were end of life. No maintainer. Uh no security releases. No road map. There was no version to upgrade to. So just patch it isn't a sentence that means anything here. The maintainers aren't coming back to fix this for you. Maintainers have moved on. Some of them have children now. [laughter] Any policy that assumes every finding has a fix breaks the first time it meets dependency like this. Every legacy estate has one. So what you actually do is write down write down why put a date on it and get the rewrite under somebody's road map. That's a risk measure entry not a shrug.

So, this is what we eventually ran on the monolith. Uh, it worked our time, so your mileage may vary. Uh, step one, uh, non-blocking by default. Uh, the scan runs in every PR. Um, on its own, a finding never fails the build. Don't just yolo a tool on. Note for the best like I did. In the PR, comment the findings in line next to the code where the developer already is, not a dashboard. you have they have to remember to visit three report uh high and below visible never enforced nobody's ever fixed a medium I've checked um mainly because a control that fires constantly gets ignored and a control that's ignored protects nothing at all

and severity in its own was never the right control anyway the question isn't how bad is this in theory is is this actually vulnerable here is the vulnerable function ever called Is it public facing? Is there customer data behind it? I couldn't answer any of that when I rolled out the tool initially. Point four. Um, blocking by exception, critical only, narrow, agreed, and only for the things worth blocking a release over. Nobody should be designing an exception process at the moment they need one. If the first person to ever hit your blocker rule past a design escape hatch at 5:00 p.m. on a Friday, you've lost them permanently. Most findings by your visibility, a very

small number are worth spending enforcement on. So three rules. Uh read the output before you enforce it. If I had done one thing differently, it is this one. Everything else that day was downstream of it. Rule two, never give legacy the same rules as new code. Two estates, two rules, and be honest about which one you're standing in. Three, enforce by exception, not by default. Visibility is cheap and you should buy a lot of it. Enforcement is expensive, so spend it on almost nothing. and a small number of things that do you do need to enforce um they need a written way out before the gate goes live not the day that somebody needs it.

The developers never trusted the tool again. Not the configuration, the tool. It had a name and the name and the name meant the thing that stopped us shipping. We eventually replaced it. a different vendor, same category of product to earn loosely the same or broadly the same thing. There was nothing wrong with the first one. I made it unusable by the way I put it in. That's the real bill, not the day, the years afterwards where perfectly good control can't be used because of how it arrived. I didn't secure the pipeline. I taught a team of very good engineers how to route around me. And honestly, they were right to fit lane assist, not a handbrake.

[clears throat]

[applause]

Thanks, James. Uh, does anyone have any questions for James?

funniest talk. >> Sorry, >> that was the funniest talk. [laughter] >> We have a question before the tabletop >> talks about assessing exploitability of discover vulnerabilities. Did you what did you do beyond manual verification of CD vulnerabilities? Did you find anything that was able to automate any of that or is it still looking at things by hand and assessing against the code base? >> Yeah. Um so back then it was very much assessing by hand and going through each CVE and making sure that is it public exploitable um is the function actually called that kind of stuff but nowadays with AI you can just say is it ask [clears throat] AI to go actually find

or prove that this is exploitable obviously it's not infallible so don't 100% trust AI to go and say this is not exploitable there's also the cost element of AI as well um but generally it can cut down the noise by about 70 to 80% roughly you still have you still there will always be an element of manual investigation in finding these issues but at least with newer tooling new LLMs that noise can be cut down by like 70 80% and it's so much easier to look at five or six CVS rather than 20 or 30 a day. >> Any other questions? um given the technical things you learned about like when to deploy these tools and stuff,

what like sort of communicative and sort of teamwork things did you learn as well? >> Uh question [clears throat and cough] I need to talk about what I learned was that I can't just throw a tool in and hope for the best. I have to go and speak to engineer leadership, the engineers onetoone if I need to shout about it in all the Slack channels if you in Slack or Teams or whatever it is actually go and talk to people. That's probably one of the biggest lessons I learned from this was you actually need to talk about this and make people actually understand what's going to happen rather than just talk about once I go this is coming in people go okay

cool do that. Um and then when you actually add it in people go what's this? Yeah, I didn't see any of this. What are you on about? Talk about it. So, let's make sure people actually actually understand what it is and what it's going to do. Show them what it's going to do. Um, show them how it's going to block the pipeline. Show them it's going to do x, y, and zed. That's really really spend probably 3 months talking about it before you do anything. Um, which being security people is difficult, but you know, it's all good. So, so you turned it on at the beginning of the day, you know, block bills and then you didn't turn it off because you

thought you just fixed everything. >> Yes. >> Fair enough. >> Yeah. [laughter] So, he's been a hero that time, you know, so we're finally doing security and it's going to be an absolutely fantastic >> opposite of that. It was probably one of the most stressful days of my life. Do you think there could have been a scenario where the original tool that you procured could have like you could have won people back around because it you know on the face of it one day I suppose and I hear what you say about it's more people lost their trust in that tool by extension but it sort of seems like your motivations were right and that sort of tool is something is

used in loads of organizations and it's a great thing to have. Um, so do you think it could have been a different outcome?

>> Honestly, no. Is the answer to that one? Um, it was because after that happened, whenever the tool flags something up, it was always James, go look at this. It's broken again. It's broken again. It's broken again. Yes. No, it's not. It's actually flagging actual things. It always had that stigma attached to it of it's broken. It stopped me shipping. It's your problem. um because the tools broken again. Whereas when we introduced that new newer tool um spent a lot time talking about it three months beforehand roughly thing um when they actually flagged the issues they didn't come to me immediately. They tried to fix them themselves first. It is that tool had that stigma attached to it and the name

um which given enough time maybe for a couple of years we could have run people back but it would had that narrative attached to it that this is the thing that stopped us doing work >> and also being said the one person in the team like looking at security like as part of that's a difficult place to be in as well because I worked at a tiny charity last year no one had any security background this team of three engineers um And you know it's difficult when you're the one person buying the flag security. Everyone's got their day jobs to do. So that's also a tough place to be. >> Yeah. Yeah. And the key part of that is

that you're the customer success manager, right? For for security at that point, aren't you? Rather than anything else that's your primary thing is to say this is security and this is why it's important and why it really matters. >> A couple questions there. Yeah. Um so first thing um I really wanted to give you a kudos for the talk because I feel like we all know that we learn the most when we up but it's not that common that people will put themselves out there and be like this is how I up so you don't um like people really like I don't know why they're like against us so kudos to you for that. >> Um secondly which is my question you

mentioned that visibility is cheap and you should enable it. what uh value or how do you attract value from that visibility even when it's not leading to you know fixing patches or or actions or remediation like can you observe I don't know problematic development practices or is there anything else that you can see through visibility only that you get value out of >> sure you can't secure what you can't see >> right so um if you can see everything you got you got your SAS tools you got your dash tools you SCA all the sort of you know um bread and butter sort of tools you have all that visibility in that time and you can look and you can

narrow your focus down right what actually matters like this deployable it's public facing or internal tool internal tool and for now we'll come back to at a later date >> if you have if you haven't got the visibility you can't make that judgmental call so get that visibility allows you to really narrow down about what actually matters does app one or app two where do you where do you rank the risk on these two things. >> So getting that visibility is the most important thing or one of the most important things. Sorry. >> So you've kind of already answered my question through other questions asked. Um but you mentioned at the start that the company wasn't particularly security

focused when you first joined. In fact, you were the only security person there. Do you feel that after what took place there was more of a mindset shift towards being more aware of the security or do you felt like it still continued staying away? >> Yes, the latter. So that that being that um they still weren't very they weren't heavily invested into security and after that event they were even more a bit um hesitant to [clears throat] to invest more in security until it proved the value which it did eventually. Um but that took then time to rebuild that trust by replacing the tool um and proving to the engineering team and leadership there this tool does provide

value. Um sorry it was it was a mixed bag that >> any more questions. >> Yeah. >> Um yeah so talked about this your example is quite a small company. Do you have any thoughts or ideas for how you would navigate especially this communication aspect of you were not that switched on cyber security and you're looking to roll out your tools and things but it's a much bigger company actually going about that. I assume at bigger companies you have like all company meetings, you have Slack or Teams just you feel like you're being annoying when you're posting all the time on these on these on these Slack channels and teams channels and you join the old co and

talk about security a whole company meeting every month or two weeks where it is you feel like you'd be annoying at least I do anyway right um but that that is the only way that you'll get the the breadth of audience that you need for them to start actually I've seen this before. I know what this is. And even if it is just that that little bit, they're aware of what it is. They know what it is and they know who to come to if there's an issue or a problem. They want they want to learn more. >> Any more questions? >> I just say I think you also need an ally as well because it's not easy being the

only person doing security and you can't sort of try that on your own. So it's like you need an ally who can also champion the cause but it's not you as an individual like as a dependency making sure that taking on all that risk on your shoulders on behalf of the whole organization. So yeah if you can find someone anyone who's interested in security and get them on your side and help get them to help convey that message. I think that's also good. I went through a similar exercise, not software competition analysis, but the charity I worked at never used any vulnerability management tool and that was one of my tasks was helping them procure and choose a tool and embed it.

But luckily the head engineer was really supportive and was like my buddy on this project and you know was able to sense check whether the tool was going to work from a development perspective before it like went go live and stuff. So I was very lucky in that sense. [clears throat] So yeah, if you don't have someone else you can lean on that. So I think you've been really hard on yourself. [laughter] I think a lot of people probably find themselves in the shoes. Questions a hard one, aren't they? [laughter] Okay, let's thank James again. [applause]