Ilkka Turunen, Sonatype | Open Source Summit Europe 2022

This is texturing TV. Hey guys, welcome back to open source summit. We're here in lovely Dublin and we're talking to Ikea tournament.

Who's the field CTO for sonotype and we're gonna have a chat about what exactly does it mean to shift left in this exciting world of Open Source that we're living in he can welcome the show. Well, thank you very much for having me. We hear a lot about okay, we want to shift things left.

But last time I talked to developers they weren't all jumping up and down and saying, oh boy shift that left to me. We'll see where we are. Well, well, you know funny enough that's kind of been the talk for the last couple of years.

You know, we've we've kind of moved so much burden on to the developers that they're saying. I don't want to do this anymore. I've got like a million tests.

So so when we talk about this stuff really what matters is finding information that's meaningful about a process that needs to occur outside of development for development. So it's a great example for for example is, you know, you need to manage your dependencies dependencies might have a known compliant license. They might have some security issues something like that.

Give me the developers information about what's a better version to go to at the time that we're making that decision can be an easy thing sort of ham-facing that process and just for example breaking their builds with no feet back about what's going on. That's usually Where the burden comes from so if 2/3 of their time is spending managing tools, for example that inhibit them from doing their work. That's usually where that sort of blowback comes from.

So what we're really trying to get to is something that feels more like actionable intelligence for the developers so that they wind up doing the right thing because none of them got out of bed this morning and said let's go build something. That's insecure. It's just that for the most part.

They never took a security course in their life. So they don't know it was an elective back in the day. So we have to find a way to make it simpler for them to do the right thing.

Yeah. I mean, I mean that's definitely a part of it right? It's it's getting the right info in front of them as their working.

Right but there's so much of this information. It's not actually just security that a problem here. It's also things like decisions about licensing, you know, if you've got something with a restrictive license that used to be open source five years ago.

How would you know, right? Well, the answer is you would in unless you spent the time every day looking up licensed text files looking at the metadata and nobody really does that in real life. So so kind of a model that works is trying to find ways of presenting that as they're doing it.

So as a part of the IDE as a part of a poll request as a part of Their normal build flow just giving them information. Hey, wait a minute. You're looking at this component.

Here's the update cycle. Here's the Oxford release diagrams of all the versions. Here's licensing.

Here's the security and then giving them some sort of indication of what's acceptable and what's not so there's not about hey developer, you know, this random faceless test failed, you know, now you're gonna call someone it's it's empowering them to make the right decision and you're absolutely right. Nobody want no one in development wants to be in security and nobody in security wants to be in development. So finding these sort of happy paths that we're where you can feed information from one to the other really helps everybody be better at their jobs.

And that's kind of the golden point, you know, where s*** left starts to actually work out. When we also be able to tell them that if they download a component that there might be a more secure version of that component that's been updated and they should go use that version versus the one that they're playing at because it just seems to me a lot of these issues are we're repeating the same mistakes over and over again people are downloading components that are insecure and they're not even aware and they replicate them everywhere and then maybe if they go fix it on one side, they go back to the same registry and download it again and then they get the same issue all over again. Well, you know, I I think you're lending on a very important Point actually because it's not just one of those days.

It's not a point in time check that you need to do is actually a check continuously part of the challenge of security is security occurs as a function of time, right? What's good today might not be good tomorrow and also it operates as a function of the use case. What's good for me might not be good for you because you know, I might work on an internal tool you might work on something Revenue critical.

It might be okay for me to use something completely insecure because it never sees the light of day for you. It might be a big deal. So So security also is a sort of you know, you see onion method analogies or other sort of ways.

It's a series of actions that help us inform, you know the right choices. So for example, it can be very beneficial to audit dependencies that coming in for example, one of our products which we call nexus firewall does exactly that, you know, as a developer you request a new component in it audits it for any sort of really strict non-compliant the reason why that might be useful is because when you're acquiring something for the first time there's this sort of old adage in development, right, you know earlier you'll find a box the faster and cheaper and easier it is to fix. Well, what's the cheapest way of fixing a security vulnerability?

The answer is not having at all. So so really the largest sort of larger sort of greatly you can have is creating out the really really bad stuff at the door, you know, if you're trying to acquire a new dependency or a library and he's going to sort of 10 out of 10 cve it's too much trouble for what it's worth to even have it in. If you're having to rip it out later down the line the same kind of logic applies as for bugs, right?

It's more costly or the further down the line you go. So shifting out the sort of really bad things in the beginning can be really beneficial. Also.

There's a there's another issue that's targeting developers nowadays, which is outright malicious. Packages not necessarily open source per se but Bad actors pretending to be open source typos quoting them publishing malicious code upstream and what they really rely on is they don't even pretending to be working packages instead when they land under your developers machine. It invokes build scripts on the build manager and it's just drops back door or a crypto minor or one instance of COBOL strike that we've observed so far.

So so these are kind of scenarios where you can prevent some of the very very nastiest coming in and there's a whole another bowl game of okay once it's in it's good today, but tomorrow something might change there might be a new look for Shell tomorrow or you know, something comparative to that. So when it comes to that really what's important is also keeping track of the catalog understanding what's going on knowing where it's across your sdlc and then having the feedback loop for example in back into your development into your PR workflow or something else to react to it very quickly because time is really off the essence in these particular cases, so Kind of a common mistake. We see is folks make the mistake of hey, I checked it once at the door.

It's good. It's approved. The real problem is is all of these functions as a pro function of time.

So you need to kind of do both you need to start at the beginning. We don't the worst stuff and then like shift deeper as you go along, you know, depending on use case and things like that and it gets so complex very quickly. There's no one easy solution here.

You really get automate and think about this more as a sort of test almost on a per application basis that that really helps kind of unstick the problem. If I dress more of this at the IDE level does that mean I got less stress and my ci/cd pipelines or do I still need to figure out how to secure that in addition to what's happening at the IDE side? Well, I what's the quickest way of getting picked pitchforks and torches with your developers?

Well, it is it is breaking their builds the very end of the day, right? You know when you're trying to deploy something into production. So the reason why I D and sort of even earlier SCM, you know get hopgate lab that survey interaction with the polar merch request can be useful.

It's because it really just gives the developer a Paving path to what would work when you push it into CD. So with continuous delivery, you still need to have those tests but what you really doing in the idea is helping them understand when they're working on the thing what would help them prevent for a failure to happen. The worst thing is you're working a thing.

It works it compiles on your machine. It's perfect in the development. Environment you send it out to be to be deployed and then it fails out of some mysterious reason that causes a lot of heartache and a lot of heartburn and that's usually when the revolves happen so IDs can be a great way of informing you early about what what's potentially happening down the line.

So what they really want is just a danger Will Robinson kind of signal that says, hey, this is not a good idea. That's it. That's it our door the Explorer.

Are you sure you want to do this? What? Is the role of the security team in this because they're the guys in the back end that clean up a lot of this mess.

So do they have a vested interest in having this conversation with developers and saying hey if you guys would just do this, I might send you fewer CVS and be yelling at you less about various vulnerabilities. So I think that's a that's a emergent property of doing something right but really what we're doing here and what we're dealing with it's almost like in New engineering discipline emerging, you know at the conference here today. We've heard talk about open source program office is we've heard, you know, see so Incident Management workflows we've spoken about look for Jay and things like that.

That's Incident Management. That's when something hits the fan and we have to react fast what we're doing with this shift left. Analogy is really saying hey this stuff requires a little bit of work every day, right?

You can minimize the work down to five seconds kind of like washing your hands before you eat or or something like that, you know small little action that can help prevent a lot of Of heartburn down the line and it might not even be that doing this stuff helps you prevent CVS from emerging Downstream, but what it will do is increase visibility of where the security vulnerabilities might exist. But the problem of security handing over those cves is really that they feel like they don't have visibility of what components are being used in development where they are at and they don't understand the implications of for example upgrading a component because sometimes it's dropping replacement. Sometimes it's an API change.

So creating this sort of mutual understanding of hey developers. Here's what's coming out of you. Here's the dependency tree and the s-pom app that's being generated here is important and then from a security perspective that can be a building that muscle of hey, I have this information available for me and in development can help them agree to it when it happens, you know, it might not even be a I'm handing you over a cve just literally is a build failure like that's a beneficial.

Where when as a developer you see more as a sort of testing regimen and security feeds data into the test set that can be beneficial because now we're both finding the machine, you know telling me it's a red X not, you know me as a security person trying to convince you as a developer that you need to drop everything and remediate this Random TV that I've just come up with. How on I mean will all this get because you can imagine developers in many cases, not all but many are going to be like can't just the machine go fix that for me. I mean, it's it's in a small issue.

It's an update to a container and just automate that end in or do I need to like sit and improve every little thing that goes on? Well, the fastest Factor hell is pressing approve on every PR, right and just because you know, these things change the fastest just give you a little bit of color, you know in the last year alone. We've uncovered just 88,000 malicious packages along right and that's without them having cve CVS come later in that sort of process.

So so the volume of this stuff is huge and you know, there's over 21,000 new version so dependencies being published every single day. Across all over source that we track as far as we can tell so so the reality is the volume is always going to be high and that's part of the reason why this is not a thing that ends it's not a one-time activity is much more of an engineering discipline of hey, we have this the third party dependency chain, we have to manage and we have to learn to find ways. It's just a part of being a good engineer is to do a little bit of management theory is that if you get really good at that then when these incidents happen is not really a big issue, you know, we for example work with companies that had look for Jay incidents that lasted two weeks because that's all they needed to understand exactly where the dependency trees were and and where are you know updates to happen and they go understanding they had a good way of working relationship with development to understood what the burden of updates is.

The caveat of all of this is that updating sometimes can be more Troublesome than you think and on the face of it, you know, if there's been a huge version number Decay, for example, you've not updated your dependencies free for a while. The projects have moved on the apis have changed that might be a big heartburn and you really don't want to be caught out in an incident having to burn down that Tech debt because fundamentally that's what it posts down to is you you're crewing that Tech that and you know burning it down so really that's why that's why all points to dedicate a little bit of it every day and that will avert a lot of that sort of heartburn down the line. Do you think we're getting to the point where organizations are going to say?

Look if you don't have good security engineering skills, you can't work here because they're going to say to developers. You know, what here's the bar and you got to be here. Um, I think that it's definitely going to be I wouldn't necessarily go that far quite yet, but I think it's definitely going to be a you a part of a skill set of an everyday engineer, you know kind of a good indication is what the dod's pushing through in the American legislation where they're actually saying saying we will not buy software from you unless you can point to me every single dependency that you have and that you have mitigated every known security amount of reality on every one of those dependencies.

That's a tall ass, right and that isn't of the face of it seems impossible and it's very ambitious and the only way that any organization is going to be able to fulfill that requirement is that everybody has a clear understanding or what that means on a day to day basis. So I do think that it is becoming a part of our part of our everyday skill set and as time goes on Yeah, absolutely. I do think that there's going to be a sort of minimum level of awareness that people probably will require.

All right guys, you heard in here first if you were to school, I mean too cool for cyber security School. You need to think again eka. Thanks for being on the show.

Thanks very much for having me.