mnemonic security podcast
The mnemonic security podcast is a place where IT Security professionals can go to obtain insight into what their peers are working with and thinking about.
mnemonic security podcast
FINN.no
In this episode of the mnemonic security podcast, Robby is joined by Emil Vaagland, Security Manager at FINN.no, Norway’s leading online marketplace.
They discuss the unique security challenges of a cloud-first, developer-heavy organisation, covering everything from vulnerability management and secure coding, to fraud detection and access control. Vaagland shares insights into their approach to bug bounties, DevSecOps, and balancing security with developer efficiency.
From our headquarters in Oslo, norway, and on behalf of our host, robbie Perelta, welcome to the Mnemonic Security Podcast. The best things in life are free, as they say, and finnno is one of my favorite almost free things in Norway. An integral part of the Norwegian circular economy, it is the one-stop shop where users can find jobs, real estate, vehicles and second-hand goods all in one place the Norwegian Craigslist basically Just much better. So whatever you do, don't throw it away. There's always someone on Finn that wants it. More interesting and relevant for this crowd, however, is the fact that Finn has over 500 developers, 1,100 applications and over 2,000 deployments per week to support their mission and, if I've understood correctly, all that is running on this infamous cloud somewhere. So when I saw their head of product security on stage at a conference, I just had to ask him how all of this works behind the scenes. Emil Voglund welcome to the podcast.
Speaker 2:Thank you, thank you.
Speaker 1:I have to admit it made my day today doing my research on you because I was looking at your LinkedIn, right, and it was like, yeah, okay, master's degree in communications technology, did some freelance developer stuff and then worked for a consulting company with Java and then it was like DJ slash, promoter for an organization called Raw Juice slash Ballamuth, and I'm like oh what Is it? The same guy Booking artists, designing flyers, curating weekly mix series, interviewing artists and running a record label.
Speaker 2:Yeah, so that has been the hobby since 2007 or something. Just having fun with friends playing the music you love in clubs and booking artists and stuff.
Speaker 1:Awesome. This is usually two different worlds that kind of guy and a developer guy.
Speaker 2:Yeah, like you have to do something in the weekends as well, right?
Speaker 1:Yeah, you like being awake in the nighttime. I guess those two have those in common.
Speaker 2:Yeah, well, now I have a small baby, so I'm also awake, but for different reasons.
Speaker 1:I was going to say. I see that you ended that record, or that part of your thought, on LinkedIn. It's not a current.
Speaker 2:Yeah, I assume. So what else have you been up to? Not much. Just been working now in the Shipstead group for like 11 years soon so and part of that has been in central teams, both as a software engineer and then security engineering and then more like a security manager.
Speaker 1:I've been telling people like, yeah, I'm going to have Finn on today, and they look at me and I'm like Finn, like Finnno, and they're like oh yeah, so I realized that to Norwegian you have to say Finnno, or else they're going to think that I'm talking to somebody named Finn if you have had a couple of guys there that were named Finn, so they had like Finn at Finn, nice, then they get a lot of spam, as well, right, yeah, of course, of course, of course.
Speaker 1:So I mean everybody in Norway. They have to know what Finn is. But for our international listeners, who is Finn? The opportunities market.
Speaker 2:Yeah, so it's basically the one and only classified sites in Norway where you can go to buy and sell whatever, but also like your house, your car and also applying for jobs, right. So it's the one-stop shop for all of that.
Speaker 1:I guess, yeah, you call it a classified site, huh or like a marketplace site. But yeah, it's like the Craigslist of Norway, but just a nicer design right More features. What is the business model of that? I've kind of? I mean I would guess it's advertising. Is there anything more to that?
Speaker 2:No, so we basically earn money on the real estate agents or people selling their car or house and stuff. That's where the big box is. And jobs, and jobs, yeah, yeah. But like the re-commerce, like the things you sell yourself, is mostly for free, right? So we don't earn that much money on that. It's mostly the car industry, I would say that we earn the most money at the moment.
Speaker 1:Interesting, so you were one of the first sort of organizations in Norway to be like okay, as long as we get people there, we can figure out how to capitalize on it, right, yeah, is that kind of how it went?
Speaker 2:Yeah, and it's usually like the biggest or the one that owns the market. They own the whole market, like there's no, like 50 percent there, you know. So we're lucky in that in that sense I love finn nice and I see, when did you start out in?
Speaker 1:like 2006 or something?
Speaker 2:the company finn, I think, was before that. So like it started as visa, visa way before that. So they took like the ads from aftenposten and just printed them online. Okay, so that was the inception of Finn, but I think it was like around year 2000 or something. Well, it makes sense.
Speaker 1:Yeah, the good old dot-com bubble. Yeah, yeah, internet. People started figuring out what that was. Yeah, I look at you now as like the cloud company, like cloud first, finn, you know, but you haven't always been like that because there was no cloud back then. How was that sort of?
Speaker 2:like yeah, so like Finn was quite late to go to the cloud. Actually I think we migrated in 2019, 2020. So that was after I started working for Finn. Actually, we did start very early with like Kubernetes and stuff. So we were deployed to like an on-premise Kubernetes thing in like 2014, 13 maybe. So they have been very like early to adopt like those kinds of technologies. But the cloud journey started later for Finn and then they moved to GCP and the rest of the chips organization. They were big on AWS. So now we have, like both of them Multi-cloud now, yeah, multi-cloud for real.
Speaker 1:That's interesting, that just that journey. What was the driver behind that?
Speaker 2:Also, they did run Kubernetes on-premise because they had an on-premise data center and they could just run it there. But that also made it easier to migrate to the cloud, because they could just spin up Kubernetes on Google and then just push everything over there. So that made the call-to-cloud journey way easier. I would say.
Speaker 1:I feel super stupid right now, but, like Kubernetes, why did they use that?
Speaker 2:Because they wanted some easy way to deploy containers and manage them in an easy way. And we have about 1,100 applications or containers, so there's a lot. So I guess the trendy thing at the time to how to manage and applications or containers so there's a lot. So I guess the trendy thing at the time to how to manage and run your containers.
Speaker 1:So then the containers, though like when you say 1,100 applications, I'm thinking like jobs, or like you don't have 1,100 services on Fin. So like, how does that, how does the containers work to your services?
Speaker 2:Yeah, well, we have too many microservices, right? So like there is a service for this contact button, so there is a service for everything, basically. So it's split up in many, many small parts.
Speaker 1:I'm going to learn a lot from this episode, that's for sure. Okay, so today, from your standpoint, you're the security manager. What does security mean for you guys? I would assume that you have development security, and you have, yeah. What is the scope of security for you?
Speaker 2:Yeah, so for me and my team we basically focus on the product security, so anything security related to the end user, finlite, endo services and we don't focus on the corporate IT or the IT security thing. That's handled by a different team. And then we have the CISO and the GRC team as well. So it's basically anything from software security to cloud security and in between that we focus on.
Speaker 1:I just had a chat with our mutual friend, håkon Sudum, and he was giving me some context about the term CNAP and the clients that have a cloud-native application, cloud-native applications which is you right that it's a whole different world than the corporate IT sort of world that a lot of people are used to.
Speaker 2:I think it's way easier to do security in the cloud context, for example, because there's APIs for everything, right? So it's easier to get information and then analyze stuff automatically, right?
Speaker 1:I've never heard anybody say that, but I guess that's usually. I'm hearing this from people that are used to the on-premise way of doing things and they think the cloud is hard because it's different.
Speaker 2:Yeah, yeah. Well, the cloud is sort of documented and you can use APIs to automate everything, right, so it's easier to do things at scale, I would say, whereas on-prem stuff might be a bit more trickier and more like non-standard solutions maybe.
Speaker 1:The corporate IT stuff is just a different department. Do you guys talk to each other at all?
Speaker 2:Yeah, we do. We have a security organization, but we are not like sitting next to each other, but we do collaborate on a bunch of things that are common. Overlapping, yeah yeah overlapping.
Speaker 1:Interested in that? What is?
Speaker 2:overlapping. So example, I would say identity and access management for, like, personal identities right, they are owned by some teams, hr, and then we come in the mix to give them access to cloud resources, et cetera, and that can overlap with other services on your local machine, et cetera.
Speaker 1:I was just thinking like what would the worst case be for Finn? That would kind of be like fraud and or that your systems go down right.
Speaker 2:Yeah. So I guess if the system is down for a long period then we don't make money right. So that's bad. But I think we have an appetite that it's okay to be down as long as we have a plan to fix it right. And we get DDoS attacks all the time. But the tooling we have right now usually it's quite good to mitigate it and to detect it, so I'm not too worried about that.
Speaker 1:Is that under your umbrella of responsibility, the DDoS stuff?
Speaker 2:Yeah, sort of. But I think the cloud infrastructure team like the team that are handling the load balancers and setup there, they are owning that feature and are handling those incidents themselves, but we do get a lot of fraud and that's another team which basically is like a user safety team that focuses on detecting fraud and also investigating fraud and building tools to find fraudsters.
Speaker 1:Basically, I would assume that they're the ones that have the most incidents, if I can call it that. They must be busy.
Speaker 2:Yeah, things that happen daily with scammers trying new stuff, right.
Speaker 1:Just the DDoS. Maybe that's not your team or your responsibility. It's the Cloud's team. But like what? How does that world look like these days?
Speaker 2:I would say it's been the same for the last six years. It happens from time to time, but every time it happens we can easily mitigate it. So it hasn't really been a big issue, I would say, and it's not something I'm very worried about. So there are good tools in every cloud provider to prevent these things and detect it.
Speaker 1:So do you use a cloud provider you don't use, like Telenor or Cloudflare or whatever. I'm trying to figure out who's supposed to address it.
Speaker 2:I think most of the cloud providers. They have their own built-in solutions that can handle these kinds of attacks. Either it's layer three attacks or layer seven attacks, etc. And I think that's good enough.
Speaker 1:Well, apparently we never know the fraud team. Is there anything you mentioned about them? That's not really security, I guess at that point. Huh.
Speaker 2:Yeah, that's not really security, I guess at that point. Huh yeah, but it's basically two different teams. We have one team that is building the tools that the other team is using. So they are building message control and detecting spammy links in messages etc. And then finding the phishing sites, taking them down, etc. And then the other team that is working with these tools to investigate different things and if some customer complain, they will investigate those types of incidents. But, like quite often the scammers, they take the communication outside of Fin, so they send them a message or like email and then we can really stop it. So that's the problem, the biggest problem, I would say.
Speaker 1:Yeah, I spoke with the CISO LinkedIn a while back and he said the same thing Once. You, if you're a self-respecting e-commerce site, they're like, in that area where you have a lot of users, you need to put a bunch of things in place, but then the guys just bad guys, just take them out. Yeah, it's easier out there.
Speaker 2:Yeah, it's easy to be an attacker these days or a fraudster.
Speaker 1:I would say, yeah, I would assume that your team has maybe helping them with the tooling that they use to, I don't know, dissect the messages or.
Speaker 2:This is basically more like homemade tools that they made. So it's basically up to that team, like what tools they build to detect the different types of malicious activities. Or they add like a phone verification thing in the flow, for example, to prevent mass sign-up of users. So it can be product design features as well.
Speaker 1:That must be a very varied team, because you have to be security-minded, you have to be fraud-minded, you have to be able to develop it. You have to have a lot of resources in one team. Sounds fun.
Speaker 2:Yeah, they have enough stuff to do at least. But speaking of these fraudsters, we have rarely seen fraudsters misusing security vulnerabilities application security vulnerabilities to do fraud. That's quite interesting. There was one time where they found a bug to bypass the phone verification and then we saw that they actually skipped that step, so then they actually misused a life-style logical vulnerability. But that's the only evidence we have of a fraudster misusing some sort of security vulnerability to do fraud.
Speaker 1:Is that just because it's easier to not have to do all that?
Speaker 2:Yeah, I think so. So it's easier to just send a message to an old person and say hey, I'm from Finland, Give me money, yeah exactly, instead of doing some zero-day hacking stuff.
Speaker 1:Yeah, yeah yeah, so it sounds like a rude question, but what do you do at work if you have all these different teams doing all this stuff that I would define as security? What does your security day look like?
Speaker 2:Yeah, so basically anything from code to cloud is basically the catchphrase. So we have a lot of services like code security tools, we have dynamic tools, we run bug bounty programs and we do a bunch of cloud security stuff. Other than that, my team also wants to contribute on the security engineering part. So making sure that our platforms are secure by default, that we do the right things when we're building the platform A bunch of different things actually.
Speaker 1:What sort of projects have you been using your time on? Lessons learned have you had from all those things that you just mentioned? Yeah, where to start?
Speaker 2:So I guess for the code scanning we have been using GitHub Security now for about three or four years and we still have a very low coverage on the code scanning and the main reason for that is it has historically been quite hard to roll it out because you need to change each and every code repo to add this code scanning and sometimes it doesn't build automatically, which means that you have to talk to developers. You have to talk to developers, you have to destroy their workflow, basically. So we don't want to be disruptive or block people. But CodeGirl is getting better now so it has more automatic features for rolling stuff out. So we'll see how that goes.
Speaker 2:But we still have good coverage on the finno prod applications, but there's still a lot of other stuff to cover. It's nice to have but it's not super critical either. So we get a lot of findings from it, but they are not very often exploitable in prod. But they are still real findings. So we try to focus on the findings that have impact, like real-world impact basically. So we don't pester developers with fixing up like 100 vulnerabilities that have no impact. So try to only communicate stuff that is important, I would say, to fix.
Speaker 1:Yeah, finding the vulnerabilities that actually are a real problem. How do you?
Speaker 2:get to that point in practice. Yeah, so like, if you get a military report and you know that this application is not exposed on the internet and there is no way for the attackers to reach that vulnerability, then that's not really exploitable in production. So then we can just forget about that. Even though it's nice to fix everything, not everything needs to be fixed, and that's one example of that. So, like we basically, even though it's nice to fix everything, not everything needs to be fixed, and that's one example of that. So I could basically try to filter out what's exploitable and not exploitable and try to focus on the exploitable stuff.
Speaker 1:Yeah, so I saw you speak at a conference, so I kind of know which tool you're using for that. But is it possible to do exactly what you just said without having a tool for it? Or I know possible, but like man hours or woman hours, physically possible, how'd you do it before?
Speaker 2:You mean like the?
Speaker 1:code scanning part. Yeah or no. The prioritization part, the code scanning part's one thing, but to figure out which to go first, yeah.
Speaker 2:So I guess you could have some sort of magical application inventory with all this thing attributed, so you can attribute the finding there and you can see oh, this thing is not exposed online, then it's not exploitable, right, and there are a bunch of tools in the ASPM world, or I think we can even use a CNAP for that stuff, but you still need to map your vulnerabilities from GitHub into that platform, onto the right thing, right. So there are solutions for it, but not very mature at the moment.
Speaker 1:Okay, so you can't just buy a tool and it becomes easy?
Speaker 2:Well, you can, if you like. So, if you ask the vendors, you can do it, of course, but in the real world, in a complex organization, it's not that easy. Yeah, but for sure we are getting there.
Speaker 1:And what is that Like to go through that whole process, then You've done this for multiple years now, so you've kind of perfected it.
Speaker 2:No, it's quite quick for us because we can easily look up where this application is deployed and where it is exposed on the internet, if it's exposed. So that's quite quick with the tools we have.
Speaker 1:Yeah, the importance of asset inventory, I guess.
Speaker 2:Yeah, for sure, for sure, but that's for free in the cloud, right? Because you can just use an API to get all that information.
Speaker 1:But if it was so damn easy, why does everybody suck at it? I don't know. I guess it's not just the cloud people. I guess it's the ones that have on-prem stuff.
Speaker 2:Yeah yeah, yeah, I don't know. Well, you still need to manage it somehow, because it's quite a lot of information and you yeah.
Speaker 1:And then going back to the code scanning part, how much code?
Speaker 2:did you guys produce? Hard to say, but we have maybe 2,000 deployments per week At the moment. We are ships in marketplaces now, so we're working for all the marketplaces, not just Finn, so the scope is way bigger. But for the Finn part I think it's like 2,000 deployments per week at this stage Wow, and there's about 500 plus developers in the whole organization.
Speaker 1:And in your teams. When you have all these developers, do those teams have their own security resource, or is that kind of like they go through you, or how have you guys structured that?
Speaker 2:Also, they are totally free, but of course they own their own things from operation stuff but also security stuff. But we are trying to help them and enable them into fixing the right things. So when we get a critical bug-once report they usually fix that quite fast, whereas if there is 50 critical vulnerable dependencies that's not that important because they're often not exploitable.
Speaker 1:Does everybody on your team actually come from development, actually understands how they're working?
Speaker 2:Well, I guess at least over half of them are like ex-developers and the other part is more like operation background. But yeah, we have also tried to like scale security champions in Finn like three different times, but it always fails because people are too busy doing other stuff than doing the security stuff. So it's hard to like set aside time to do like a security project where you're actually working on something else. But we have tried doing this to have like some sort of community where people can talk together. But yeah, that's about it.
Speaker 1:Did you guys just kind of give up on that then?
Speaker 2:Yeah, but that was mostly because we have had this VR for a long time. So we are going to join the marketplaces together from all these different countries and at that time we just stopped it because there was so much going on in the organization with the VR and stuff. But we do have plans to relaunch it when we find a format that works for this new organization.
Speaker 1:And I'm asking these questions not to like make Finn look bad or anything, just here are these things at conferences all the time and it's like it's interesting to hear how. Why does it work in practice? Like that's where we need to spend more time focusing on like, how do you make this shit work in practice instead of on a PowerPoint?
Speaker 2:yeah, but to make it work at our scale, we have 30, 40, or 50 different champions. Then you need a full-time position to follow them up or several persons to follow them up, right. If we're going to do it like project-based champions and if you have just a monthly sync or weekly sync, then maybe one third of them will show up right. So it's even hard to scale information in that case as well.
Speaker 1:Do you have any other cool, interesting things to say about the code aspect of your work that you find interesting in that world?
Speaker 2:Yeah, so we have all the programming languages in the world because the developers can basically pick and choose the languages and framework they like. So we have a lot of different stuff. But that also makes it harder to buy some code scanning tool because it doesn't support all of the languages, right. So we try to just get stuff that fits for most of our common languages, I would say.
Speaker 1:Bug bounty. I guess that's kind of along the same lines. Right, then you have external people telling you things going on. Anything to say about your bug bounty.
Speaker 2:Yeah, so we've been doing it since 2019, and I think I spent about over $200,000 on bounties so far, and it might sound like a lot for a Norwegian company, but if you compare it to big US companies, they pay more than that in a week. So it's pennies basically, but it's still. The average bounty is around $300-$400, so it's quite effective in terms of cost, I would say. And over the years we have found maybe over 400 vulnerabilities that were real in prod right. That has been fixed, so that has been also very effective. I would say that the developers they also like the program because now we send them reports that are real all the time, not just false positives.
Speaker 1:Exactly yeah.
Speaker 2:And that helps, and they also like to read vulnerabilities from a hacker. So it's like a cool report, I get it to see it Hacker yeah. So I think it's been very successful in terms of both the vulnerabilities we have found but also the awareness about the program and the vulnerabilities we have. Do you do the open program, the vulnerabilities we have?
Speaker 1:Do you do the open program or do you have what do they call it private program?
Speaker 2:We have been private all the time and mostly because to keep the report quality high so not the whole world can send us spammy stuff.
Speaker 1:Are they Norwegians, the researchers, or most of them?
Speaker 2:Some, but I think most of them are from other parts of Europe and the world, but there are some Norwegians, the researchers, or most of them. Some, but I think most of them are from other parts of Europe and the world, but there are some Norwegians there as well.
Speaker 1:I know Visma has a bug banning program, but I guess there can't be that much more than you two in Norway.
Speaker 2:No. So we have Sparbanken and Oda. They also have programs and Kahoot, but Shipstead has six programs. So we have one for Finn, one for Shipstead News Media and then two for the other marketplaces. So we have more bookmoney programs than the rest of Norway, I would say.
Speaker 1:Yeah, so it's kind of funny. Yeah, because you have to be a certain maturity level to actually have a program right and actually be able to.
Speaker 2:Not really People say that, but what you mean by maturity, I think like the only thing you need is basically to be able to fix the vulnerability within a reasonable amount of time. Yeah, but like, if you talk about like app sec maturity, I don't think that's that important because you can scan all the code you have, or like run 10,000 pen tests but you still will have unknown vulnerabilities in production because, like, the code scanning doesn't find everything Append. This is more like point in time stuff, right, so it's more continuous and more effective, I would say.
Speaker 1:Which is why you do a little bit of all of them, I would assume.
Speaker 2:Yeah. So my recommendation is that don't do all of these AppSec thing before you launch a program. Just start it and you will do some real risk reduction from day one instead.
Speaker 1:Of all those things that you've been talking about, like your bug bounty program, the code scanning pen tests, what do you think reduces the risk the most?
Speaker 2:Of course it's the bug bounty program, since I've found like 400 vulnerabilities over the last five years. The code scanning I. I found some, but it's more about like 10 to 20 real vulnerabilities, I would say, than 400. So it's a different scale. Of course the pen test will also find stuff, but it takes so much time to scope every pen test and it's way more expensive. It's also like, point in time you get fewer people looking at the site. So yeah, like we still people looking at the site. So yeah, like we still do it for the things that cannot be tested in the bug bounty program, but it's more for that special use cases and not testing the whole site.
Speaker 1:Interesting. So bang for the buck bug bounty program. Yeah, for sure, for sure. Cool, interesting Vulnerability management. Is that under your umbrella or is that like a best spread out function?
Speaker 2:So we do our own vulnerability management for everything that we think needs to be fixed in the products, so anything that we verify as a real vulnerability. That is something we track. So most things from the program, some things from the code scanning thing, and then some from some other tools as well, and those are the metrics we try to use basically, but we don't really follow up on all the false positives and that stuff. That's more just hidden away and we don't really have one solution at the moment where we get all the data. But we have some work in progress on that to automate all that stuff.
Speaker 1:I just realized when I asked you that question vulnerability management it kind of covers all this that we were just talking about bug bounty and that's the same thing in your world, right?
Speaker 2:Yeah, so it's a source that can produce some sort of vulnerability, right, that's basically anything. But I think in a classical sense it's more like some sort of vulnerability, right, that's basically anything. But I think in a classical sense it's more like some sort of scanner that finds some outdated software like that type of thing. But I guess all the tools find vulnerabilities, but I'm more focused on the verified vulnerabilities than the outdated software type of reports.
Speaker 1:So you've never even probably I know you've seen one, but you've never really worked with some Nessus scan report Basically. That's just way too old school for you.
Speaker 2:Yeah, well, I have, but I don't find them that interesting because it's usually not something that it has low impact usually, or it's not exploitable, et cetera.
Speaker 1:Interesting. Is there anything that like under the vulnerability management or like that umbrella that you think will be more useful moving forward, and for companies like you that are you know, that have like cloud applications and like what kind of vendor pitch would actually work for you? What do you want to hear that you don't see today?
Speaker 2:Yeah, well, so we do see today. But, like when you have everything in the cloud, you have information where things are deployed, where they are exposed. But, like when you have everything in the cloud, you have information where things are deployed, where they are exposed, and then you can annotate all the different applications with different vulnerabilities in different call paths. Then you can easily ask the question like, okay, is this vulnerability exposed and can it be exploited? And if it can be exploited, you should fix it right away. Right, and then you can also try to filter out more easily the noise and stuff of things that are not exploitable, right?
Speaker 1:so do you have? You know the concept of like breach and attack simulation, like automated pet testing, sort of stuff? Is that bullshit or what do you think about that?
Speaker 2:well, so we haven't really done it. I would say like we do. I would say like the bug bounty is like they're hacking us all the time it's real shit, though, yeah, and also like the dynamic scanners. They are scanning us all the time. So like we do get all of this traffic but we don't really test like your breach simulation stuff. But we have like different tooling that hopefully can detect that stuff. But yeah, I'm like.
Speaker 1:I realize I'm basically asking what all the buzzwords mean and if they're actually real. I feel bad about that. It's cool. What are you using your time on these days? What do you think is important and difficult to handle?
Speaker 2:Yeah, so we are like a marketplace company and we are so lucky that we are under this new EU cybersecurity legislation called NIST 2. So we are mostly working on figuring out what we need to do in order to comply, and one of the topics we are looking more into there is basically access management stuff for access to code repos, access to cloud resources and how we do that, how we can improve that, basically. So get more just-in-time access privilege access management stuff. That is something we are working on and also giving the development team more freedom to use cloud resources in a secure way. So basically giving them some more guardrails on how they can use different cloud solutions, because now everybody wants to spin up the latest AI cloud thing and just put some data in there right, but we need to make sure that they can do it in a secure way without blocking them, of course.
Speaker 1:But I would assume that you were probably one of the most forward-thinking organizations when it comes to guardrails and developers, wouldn't?
Speaker 2:you say so. Yeah, of course, that's what we try to do.
Speaker 1:But is it like the AI part of that that's adding an extra thing, or is it just that you have to prove it for NIST too? Or like what's the gap there?
Speaker 2:No, not really, but like we need to improve on access management, basically to like lock down things a bit more and to have more control and also give them, yeah, easier access to stuff.
Speaker 1:So yeah, and I guess the challenge there is actually, like you went back to earlier, just like you're screwing up their workflow sort of thing. That's what you want to not do, right? Yeah, yeah, so do you remember? You're like your security guys coming and tell you to do something. You're just like fuck off man yeah, sometimes.
Speaker 2:But yeah, we can work around it, of course did you learn all this?
Speaker 1:the hardware where did you go to actually find smart things to do and implement that like? How was that journey for you?
Speaker 2:not sure, like just learning by doing, figuring out what works, and I try to have some guiding principles of what you should or should not do. For example, one thing that we've been saying for years is that we should not block the development teams. So when we are introducing code scanning workflows, we try to do it in a way that are not stopping their builds or stopping them from doing a deploy, because there will be too many false positives still. So basically, try to follow some principles to guide how we approach security work and then just figure out what works by doing it and testing different things.
Speaker 1:So you're going to have to learn by doing. That's actually the solution, the only way to do it.
Speaker 2:You have to test stuff. You cannot just buy different products and then just enable them, and then you have a checkbox security thing. So you need to actually use them and figure out what works or not.
Speaker 1:Do you have any tips to share about how to make the security people and the developers actually like each other?
Speaker 2:Well, just be nice. I would say Just be nice and don't be a dick, Just be nice, that's hugely. Yeah, A lot of people missed that one apparently we are very close developers and that's also because we know how developers think and we are a bunch of our ex-developers, right, so it's way easier, I think, when you've been there before.
Speaker 1:So, last but not least, ai what's your viewpoint on that and how it's applicability to a huge development heavy organization?
Speaker 2:yeah. So I would say it's a very nice tool for many different parts of the organization. So people use it to write stuff right or to rewrite stuff, and the developers use it a lot when coding. But I take coding assistance. So our code scanning tool now has has this AI autofix feature so we can automatically fix the vulnerabilities it finds. So it can help on a lot of stuff, I would say. But I wouldn't say that it's a one-stop shop. You have to use it carefully and figure out what works and also steer it in the right direction.
Speaker 1:But didn't you guys get a bunch of pushback internally? What if you just start blindly trusting what that thing is doing and it just changes things because it's auto-fixed? Hasn't that been like a concern?
Speaker 2:Yeah, well, so the way it works is that it will create a pull request, so you have to like review it, like it won't just go around fixing stuff and then push a production. It doesn't give you the best fixes sometimes, right? So you have to suggest a new review.
Speaker 1:I guess the difference is that it suggests, but it gives you like the suggestion. Now it writes all the code and you just gotta make sure that it's all good, right, yeah?
Speaker 2:so it's a buddy, not like a mentor. I would say.
Speaker 1:The concept of AI agents. What do you think about that? I've seen like some demos online where they're like yeah, they're like make me a website, whatever, and you can just see like the screen going doing stuff. I can just kind of see in the future where developers kind of like what am I supposed to do at work? I can just have this thing do it for me.
Speaker 2:Yeah, yeah, if it's more effective, then just go for it, right?
Speaker 1:Well, can you do me a favor, emil, if that ever happens, to let me know so I can get whoever has some experience with that to come on and talk about it. But, as of now, it's not usable. Yet I guess it hasn't reached your table.
Speaker 2:Yeah, I think so I could use all of these tools, but not to automate everything. I would say I could still need some human in the loop to quality assurance and stuff like that.
Speaker 1:Yeah, I think it's really interesting to hear from you and from Finn. I've actually never had any bad experiences on Finn's and it makes sense you just have your stuff under control.
Speaker 2:Yeah, that's good.
Speaker 1:Thank you for sharing your expertise, emil, and take care. Happy holidays. Thank you, alright, ciao, bye-bye. Well, that's all for today, folks, thank you for tuning in to the Mnemonic Security Podcast. If you have any concepts or ideas that you'd like us to discuss on future episodes, please feel free to hit me up on LinkedIn or to send us a mail to podcast at mnemonicno. Thank you for listening and we'll see you next time.
