Hi. I'm Ciara Carey, and welcome to Cloudsmith's monthly webinar on all things cloud native package management and supply chain security. Cloudsmith is your cloud native universal artifact management platform.

We support all your packages from your nuggets to your docker images to your Python wheels. We also integrate with all your CICD. So today, it's gonna be a look back on trends in DevOps and supply chain security in twenty twenty three. So what kind of year has twenty twenty three being for DevOps. Are people generating a sponge?

Are people asking for them? Were there any mad crazy vulnerabilities like Log4Shell? And are we all using AI in our workflows? So we have three wonderful panellists. We've Glenn Weinstein.

He's Cloudsmith's new CEO. He started in September. Delighted to have him. I'm gonna bring you on stage.

Hey, Glenn.

Hi, Kira. Thanks for having me.

And we also have Josh Brezers. He's VP of security at Ancore. He's also a podcaster of Open Source Security podcast, totally recommend.

Hi, Josh. Hi there.

I'm excited to be

here. Yeah. Glad to have you.

And last but not least, we have Luca Lanziani. He's head of DevOps and platform engineering at new at NearForm, and he's also a blogger.

Hey, Yigal. Nice to

be here, everyone. Hey.

So we have of few bloggers and a CEO. I think we might have trouble keeping this under thirty minutes. I love it. We'll try. We'll try.

We'll make it. Yeah. So let's kick off. So I'm gonna start with Glenn. So investment.

Twenty twenty two was kind of a tough year for tech. How has investments in DevOps and supply chain security been in twenty twenty

three? It may have been a tough for tech, Ciara but DevOps continues to steam along as a major priority of software companies, of corporate spenders, and so forth. At least from my perspective investments are way up. We've seen companies in the DevOps space funded.

Startups are getting additional rounds of funding and attracting funding that maybe is getting shut off from other sectors into what's considered maybe a more a more manifest and legitimate sector. Cloudsmith is a great example that we took a significant round of funding earlier this year and had a ton of interest from VCs. But, Honestly, I'm not surprised at all because our customers and I think software organizations generally are learning that they need to take a much more defensive and approach control of their and to protect their software supply chains. We are living through dangerous times. I mean, open source public indexes are I wouldn't so go so far as to call them cesspools, but there is a lot of stuff out there.

Hold back

them. I mean, what's the good with the bad? There's huge value, of course. Like, we're never going back to, you know, not using open source, but The malicious or code or code with more more broadly, code with vulnerabilities, it is just rife With problematic packages and problematic projects, and it's getting a lot worse. It's getting worse very fast.

There's a huge number of open source projects that aren't maintained. And even if you look at projects that were maintained in twenty twenty two, a large drop off In what's being maintained in twenty twenty three. Many projects don't have proper code code review processes in place. They're not doing branch controlling. There's just vulnerabilities that are so bad that companies are and software organizations continue to download And use packages with known vulnerabilities months or years after the vulnerabilities are well known, and patches are widely available.

So this this space is definitely getting investment. And the reason to me is clear. We have suffered enough Problems from an insecure software supply chain, and I think the world of DevOps is collectively waking up to the real the real issue.

Yeah. And on that, on software security, Josh, has there been any mad vulnerabilities like Log4Shell or are we was twenty twenty three a little bit calmer?

So I think from the AppSec perspective, it was pretty calm. I mean and this is obviously we're looking at this through the window of Log4Shell, which was Completely bananas for many of us. Right? However, if you look at the security news, there have been an enormous number of high profile breaches That weren't necessarily AppSec related. Right?

You had, you know, you had twenty three and Me, and even LastPass happened in in twenty twenty three, which feels like it was a million years ago now because there's just so happening, but there have been a lot of things going on. So by no means has it been boring. I just think it has been Less on fire, which feels boring sometimes.

Yeah. Why am I being called up at three in the morning too?

Exactly. Oh, I miss those days. No. No one misses those. And do you think part of the reason why it's a bit more boring is that There has been we've taken on some DevSecOps practices, apply them.

No. I

think I think I think we're lucky. I mean, look, I'm gonna be honest. Open source is what it is. I mean, Glenn mentioned, you know, all the vulnerabilities in abilities in in all of this.

And we've been doing this for decades at this point. And I think for the most part, we tend to get very lucky. I don't think a lot of the quiet we've experienced over the year is necessarily because of positive practices. There's Things that are getting better, I think all of the arrows are pointed in the right direction, but we are on step one of a million step journey. Like, there's a long way to

go.

Like, do you think that, um, at the moment, we're we're a lot lucky, but eventually, that look is gonna like, we're gonna get less lucky and less lucky as the attackers kind of learn how to figure out who is vulnerable?

To a Three. Sure. I I think you can argue that. I mean, it's the perpetual cat and mouse game of security where Attackers learn things.

They take actions, and we have to defend against them. And I think just in general, The world of computer security has gotten very lucky over the years. I I think there I mean, I remember so I played American football when I was young. I was very, very bad at it. But I'll never forget, there was one game that at the very end of it, the coach walked up to us and just said, boys, sometimes it's better to be lucky than good, and he turned her on and left.

And I'm like, I don't think anyone's gonna argue that.

That's something to take with you for life, you know? I think of it a lot. Yes. Hey.

And so do you find this are people one of the big things that's come out over the last three years is this idea of using SBOM, supply chain bill of materials, like an ingredient list of all the packages in your in your software, including the open source, how people started to generate them, even bad s bonds. How how are you seeing that?

Yes. Absolutely. So, I mean, SBOMs are kinda Anchor's bread and butter.

We have an SBOM scanner open source called syft that that's widely used. It's used by lots and lots of projects. And we're seeing a lot of kind of internal SBOM use where an organization brings in some software. Maybe they're building it. Maybe they're buying it, whatever.

And they're creating SBOMs of it, and they're using that as just a historical archive of what they have and what's going on. There's talk of how we can start sharing these things, which I think will be a topic of twenty twenty four, I suspect. But For the moment, it's almost entirely internal use that that we're seeing in the in the industry.

LUca, you're involved in helping a lot of companies kind of scale up their their DevOps

You seeing people take on are they worried about their the risk with supply chain

security?

They're They're definitely being worried in the past. They're less worried right now. Unfortunately, we get more worried when there are big vulnerabilities that's the cycle. Right?

This hack is a new vulnerability comes out. Everyone is worried, and then their worries goes to lower and lower and lower until security takes some of the side And, eventually, when there's a new vulnerability, there you go. Now we want all the patches and everything. But, yeah, definitely, there is a little bit of bigger A bigger push before after, sorry, the latest vulnerability on security. And the SBOMs are definitely coming out Of the shadow.

Right? And we have seen that used in many companies. Are they being used effectively? That I don't know. I definitely see that there is an exercise to try to use them.

They they try to make the best out of them. Are they using the best tools for the job? I'm not sure. Right? But, Definitely, there is a movement there.

What I what I noticed and after the discussion you just had, right, is that We think there are less vulnerabilities. There is less noise. Probably there is less vulnerabilities that we know about. That is my perception. Right?

And remember that We never were gonna run out of vulnerabilities. There was an interesting discussion ahead with the security expert that was complaining that every We had every month. We had more than the one before. We never were running out of and was like, that is to be expected. We're never gonna get to zero.

Right? You can only patch so much. And that's the story of this industry. It's it's gonna keep happening. Right?

You're never gonna go to zero, And that's why more effort is needed. You get you need to get better off finding out vulnerabilities. You need to get faster at patching them. And the only thing that you can do is to reduce that time between the discovery, the vulnerability, and you applying the patches. That's the only thing that you can do.

You know, Luca and Josh, you both you you you both sort of described us as having a lucky year because it hasn't as much in the news as as in the past. I totally agree with you, by the way. But my concern for the ecosystem, Luca, is It it the time between discovery and remediation of the vulnerability is really just step one. Step two is getting people to stop using the vulnerable version and they continue to do that. I I wish we could sort of omnisciently scan all of the code running in production in the whole world right now.

And how many how much of that code has known vulnerabilities still running in production, almost these lurking time bombs that are out there? I bet you that would be a number that would scare everybody right back into compliance. I

don't know if it would scare anyone into compliance. I think At least alarms. Humans humans are marvelous at ignoring problems until they

can't.

Well, security experts are gonna scream, but are they gonna be listened to? Right? That that's that's the thing. No. I think Sure.

We We're gonna patch it next week. It's fine. It's gonna stay there in a little bit. Right? So this

just do you think that, like companies can be trusted to self regulate when it comes to vulnerabilities.

I know there was a recent legislation, like, not passed yet, but coming close to being passed in the EU the Cyber Resilience Act, where it mandated some security like, no vulnerabilities when you release or something like this. And, also, I think your s bombs and all this kind of thing. But do you think we need legislation because businesses, that's not what they're driven to. It's not their purpose. Like, that's, you know, you patch when you have to, but maybe you're exposing your customer's data.

And you need to be pressurized into being more secure.

Anybody?

Take that. I'm I'm happy to take that. I talk about this a lot.

So I I have a podcast called the Open Source Security podcast, and we I talk about This exact topic on a regular basis where I think expecting organizations to self regulate is Not a real it's just not practical. Because if you look at every regulated industry on the planet, every one of them has Said they're going to go out of business if they have to follow some rules imposed upon them, and none of them did. Now at the same time, this is not a problem we're going to see solved Overnight or next year or even in the next decade. And the example I like to use is air brakes on trains. There was a guest I had on my podcast a long time ago.

Her name is Carol Nichols. She wrote the Rust book, and she gave this marvelous presentation about train safety. It took eighty years from the time the air brake on trains were invented until they were implemented across the world. Eighty years. And this was a problem that was literally killing people.

Right? We're not killing people constantly with our software. And if it took them eighty years, like, we have a long way to go. I'm not saying it's gonna take eighty years, but it isn't gonna take one either. Oh, I think we also need we we need we need to set that

expectation.

Right? Software moves faster. I'm sure we can make it less than eighty years. No. But I I agree.

I agree. I agree. And we we are from the regulatory continent. Right? EU is famous for regulations, right, to put regulations up.

And, If you look at the industries, I agree with Josh. Right? You you have to look at the other industries. Look at the car industry. Look at the, I mean, health system.

Right? Look at all of those. They have regulation. They have to be regulations have to be in place for industry to adhere to those, to respect those, and so on. There is nothing better about a little bit of regulation.

Not

too much, though, lads.

Of course. Of course. I mean look. That's a valid point.

Bad regulation sometimes is worse than no regulation, So you do have to be careful of that.

I do like Josh's point, though, the the direction you're heading, which is that regulation is essentially a shared cost that If we agree to impose it equally on all parties, then it we can move forward. If it's that's the fundamental problem with a voluntary scheme is you know, there's a It's just incentive at the individual level to comply because of the cost. But, you know, software engineering, ever since I got in this business, and I'm pretty sure looking at the four of us, I'm the oldest person on this Podcast webinar. It you know, we've been talking about software development as an engineering discipline Ever since I was in graduate school, it's we all kinda know it's not.

Like, blink blink, nod, nod. It's not really software engineering. But, You know, moving more towards an actual engineering discipline, I think, is the kind of the pursuit of a lifetime of anybody that's in this business. At least moving a little bit closer to making sure the bridges don't fall down or, you know, the equivalent of that for civil engineering in the software world. So, Kira, you raised a great topic.

Like, I just think that even trying a little bit is good, you know, you know, to make software safer.

Yeah. So let's move on to, to the complexity in in cloud native development. And, actually, that's sort of ties into security. And I think twenty twenty three, There's been more talk about making it simpler to create Cloud-Native applications.

Luca, you probably know a lot about Kubernetes. It's it's such an amazing tool, and it's It's so flexible, but that flexibility leads to difficulties for engineers. Do you wanna talk

about that a bit? And maybe more work for us. Right?

That is not a bad thing. It's a joke. So, yes, it's definitely it's definitely I I like to say that it's not complicated. It's complex. I just came back from a workshop we ran for a company on Kubernetes, and you could see at the end of the workshop how both developers and DevOps were more aware of what The system was and how that worked.

Right? And it makes the difference. When you know the tool you're working with, it's like for everything. Right? You don't go and just swim without having some swimming lessons and and so on.

And so that was the same for Kubernetes. What Kubernetes has done From my perspective, though, it's more than giving you a platform. It's giving you a common interface that is very useful in our business. Now we can talk the same language across clouds. We can talk the same language even on prem.

That is amazing from a perspective. Is solving some of the fundamental problems that we have for many, many times, like out of scalability and self healing and so on. And that is all packaged for you. Oh, sure. There is a little bit of an a learning curve.

But if you wanna get better at it, again, you have to spend some time there, Learn how it works and then go ends win between the billions of tools in the CNCF landscape. That's probably the most challenging

part. Over there's over a thousand. There's like It's

yes. It's a lot.

Yeah. And we're gonna get more. I'm sure we're gonna get more.

Yeah. So I saw Microsoft had their big conference there, and they have this new framework for called Aspire.

And it's been to you know, it's one of those opinionated tools, but it's for cloud native development. So you you cut out of the box, it's configured and with some defaults that are secure, but and so you can just create your cloud native applications straight away, and you can easily pull in your message queues or whatever you want. So I can I can see twenty twenty four, I can see that continuing on?

I think there are gonna be more tools like that. We're trying to move there is the big the there's this big movement of shifting left to right, moving closer to developers, where we're pushing some of the complexity to the developers.

And while doing that, we're trying to simplify the way they can build infrastructure build systems. bUt at the same time, we're not giving them enough tools or enough abstraction to, Let's say forget about what they're building and just focus on what they do best, right, creating software. So, again, it's a to me, it's a cycle. Right? We're gonna go through this cycle.

We're gonna try to simplify this. We're try to put it in front of developers, and then we're gonna realize that it's too much. And so we're gonna go a little bit back and try to push a little bit more DevOps, VEX infrastructure and then again and again and again because, as Glen said, we are not engineering yet. We're not in the engineering phase yet. And,

actually, on this, platform engineering.

Is this the new DevOps, or is it the same person? Is it just it's just like the culture has been changed. I understand.

So I was running a blog post about that where I was actually the title was DevOps are hurting themselves. Right?

It's We DevOps was never meant to be a role, and yet it is a role. Right? We keep talking about DevOps as a role. And I love the fact that developers can be we have different type of developers. Right?

Developers is not the role. Front end developers are the role. Mobile developers are the role. Back end developers is the role. And yet DevOps is the role.

DevOps is the one that is gonna configure your your cloud native environment, the one that does AWS, the one that write Terraform, the ones that does AWS, the one that does CICDing GitLab, GitLab, Jenkins, whatever. Right? And then the one that does platform engineering is gonna set up the old platform for you, the same person, The unicorn DevOps. Full stack

developer. Right?

Yes. So DevOps is the real full stack developer Without writing software, though. Right? And now we also have to write to have to write software because, apparently, SRE is a thing and SRE writes software. Is there a DevOps?

So yeah. So a little bit of a rant.

So DevOps is the new full stack developer.

We we have to change that. That was the end of the of the blog post.

We dev ops have to change that. Cloud transformation is another one. The the fact that we believe that everyone is in the cloud and we realize that most of the companies, there is such a long tail of companies that are not in the yet, and they have to still do that migration. Sometime I I admire how we think we are in such a state where everyone is using web two point o and the latest technologies and everything, and it's not like that at all. Right?

It's not like that at all.

And where do they normally start when they're doing their transformation? What? Like

It's easy. You take whatever is in on prem, and you move it to the cloud exactly up.

The way it is on prem. Exactly. Yeah. Yeah. That's the way you do it.

You so you just take a bare metal machine, and you transform that into a virtual machine, And everything's gonna work fine. Yep.

Mhmm. I see some issues.

Oh, yeah.

Yeah. Yeah. But that that is for the CFO to solve. Right? That is for the The the course The DevOps.

I must say. The notes is all together. No. It's amazing because you you do that, and then you see a big increase of cost because you you haven't done things the proper way. And so you, again, you step back.

I don't know if you realize, but there is a big movement right now to go back on prem. Yes. Yep.

Yep. And so and also at the same time, there's this fin ops movement.

Have you like they're kind of like you were saying, this tried to as, like, the pressure is maintained to wrangle these cloud native costs and to to get, like, more to figure out how much it actually costs when you're doing a daily build and that kind of thing. I think it's I think it's FinOps. I'm calling it FinOps.

Yeah. I mean,

look, I think that ties into what Glenn opened with is there's a huge push right now in the whole industry to, you know, watch costs and cut costs wherever possible.

I mean, this is one of the things I'm seeing in in conversations with customers and and prospects is, you know, how can we buy less tools. Can you do two things for us that that we're doing today with two tools? And so I yeah. I think the whole FinOps idea is it's very real, and it's probably gonna get more real to your for sure. And

and I love what you say, Josh, because we we started FinOps thinking about reducing the cloud cost, and now FinOps is turning into reducing any type of Cost from tooling to everything else.

Right? The thing that I don't like is that we still talk about FinOps as reducing cost when it should be managed cost, Not

reducing. Yeah. You're you're right, Luca. Well, this ties in.

I think it's an extension of the trend towards everything as a subscription service. You know, there was a recent piece, and then I think I just saw it this morning, where Broadcom is pushing VMware away from perpetual licensing and forcing perpetual customers to move to subscription. You know, on the one hand, it looks like corporate overlords are back at it. But, you know, on the other hand, it's just reality. Like, we pay for the drink, as we go.

And, you know, you pay for the deployments. You pay for every time that you kind of blush at AWS. They charge you a Practical percent. So Yeah. Better know what we're doing.

Yeah. You just have to have more

controls over Is it yeah. It's even worse than that, Glenn. It's not just subscription. It's Per use.

Right? So the granularity went so fine that it's very difficult even to understand how much you're gonna pay. We have client asking us, okay. Can you predict how much it's gonna cost us to build this thing? And it became almost impossible to them to tell them the exact number.

And we try to get closer and closer, but there is always something more that you can have to add there. And it's valid for everything. It's valid Every single part of the system. Yeah.

I would like to think I think the the the perspective you gave that it's not really about reducing costs, it's about managing costs.

And that's a That's that's a really important point here because Yep. In the long run, I there's no reason you can't be just as efficient, if not more efficient, In a FinOps managed world or a subscription or per usage managed world, the analogy that my dad has made for me in the past has been it's very expensive, Glenn, to own a car. You know, if you take an Uber or a taxi often, it feels expensive because you're paying per drive. But Over the course of the month, probably cheaper to ride share than to own a car and all the expenses. This is very similar, and it's just a matter of controlling and understanding, standing what you're what you're doing and just making sure that you're being efficient, which is good.

We always should have been doing

that. Yeah. There you go. And, also, if you move to the cloud, it's gonna cost you more, but it's also giving you more flexibility. It may be delivering to you more value because it allows you to create new things faster, to move faster in general.

Isn't there a value? Is it the value I mean, that is worth paying maybe? Of course, it depends. Right? The answer is It depends.

It depends on the type of organization you are. If you're running a stable business, you don't wanna do anything else, go to on prem. It's fine. Right? You it's you're fine with that stable infrastructure.

It's fine. But if you have someone that you wanna push the boundaries, innovate, and so on, maybe you're better in the cloud.

Yeah. I I also think organizations are typically challenged to calculate a true TCO on That's a universal problem. At the very least, the, you know, the the software as a service model is a little more transparent that, You know, these are your costs.

And every time you you take an action, there's a cost and there's a benefit. Just just simple. For sure.

Now let's finish up with what everybody was talking about in twenty twenty three. It's AI.

Have have we finally started using it and INC, incorporated into our workflows. I know when I'm creating content, I'm like, basically, just me and chat GPG all day. Food how are you seeing, like, it actually working in real life?

I can I'll jump in first. Yeah.

Go for it. This is it's always like a dicey question. Right? It's so from my perspective, there's tools like GitHub has Copilot. Right?

You're seeing these kind of assistant AIs emerging here and there. And I know from a developer perspective, Things like Copilot are amazing for productivity. Right? There's a risk aspect of that that as a security person, I you know, I've got my risk hat on all the time That we don't know we don't know all the answers to yet. And I think there's gonna be a lot of interesting conversations that happen over the next around some of that aspect of it, around some of the safety angles where what kind of where's this contact coming from?

How's it getting produced? Like, what are my rights To use it or not use it or whatever. But I think all in all, the I forget who said this, but, you know, the saying is basically a human with AI is going to replace a human without AI. AI isn't going to replace humans. And I think that's kind of the all of the things I see are pointed in that direction because I find even from my my perspective, and I don't I'm not, like, a super heavy AI user by any means, but I can get so much more done Using this technology as a tool.

Right? It's not magic. It's not replacing me. It's not doing a better job than I can do, but it lets me work a lot faster, I find.

I love and I hate it, unfortunately.

I Oh. I'm it I realized that it makes me lazy, And that that's the part that I hate it. I hate it. The dream. No.

I don't. I mean, I I love solving software problems, but I also realize that I can ask DAI, right, or whatever, to give me the algorithm is gonna, I mean, bring it up Ten times faster, if not more, right, than me. And that's why I love it because it, yeah, allows me to solve problems faster. Of course, I'm gonna double check what is produced, Uh, but at the same time, I hate it because it doesn't allow me to think. Right?

It's it's it's the same for for content. Whenever I content, I asked for the first draft to AI. Yes. I'm doing that. And it's the same thing.

I hate it because it means that I'm not thinking as hard as before.

yOu know, from a software supply chain point of view AI is real. And it's actually a new type of ingredient going into software builds. You know, you're deploying a language model or a data produced by it as part of your build. It's really just another type of artifacts.

And it's a rapidly growing type of artifact. And you know, not to make a Collins with corporate picture, but, like, you know, Something we're we're trying to figure out is how do we help companies manage the ingestion and the deployments as the safe management of that as another type of artifact. So Yeah.

Sometimes those machine learning companies have the worst workflows to to

That that's that's one thing that we're trying to do in NearForm is to try to help clients to understand how to best leverage AI because there is a danger there. Right?

As as is is the the old where the information is coming from and what type of information this tool is gonna push out because we don't understand how those tools Generate information with a no we are unpredictable. So especially if you're putting those tools in front of your clients, you have to be very careful what you do there.

I think disclosure is the watchword of the day right now. And, you know, that's a pretty important line in your SBOM is exactly what AI is being deployed with.

That's right.

Yeah. So with that, I think we'll try to wrap it up. Thank you so much to Luca, to Glenn, to Josh, And I hope you enjoy today. So talk to you later. Bye.

Take

care.