Hello, everyone. Welcome to Cloudsmith's first monthly webinar of 2023. Thanks for taking the time to join us today for what is sure to be an interesting and hopefully a thought provoking discussion around predictions for DevOps in 2023. So I'm Dan McKinney. I'm a technical account manager at Cloudsmith.

I'm based in Belfast in the UK. And I will be your host for this webinar. I'll do my very best to keep things moving along and at a pace that suits us all. We've assembled a great panel for this discussion, but before we get started, let's go through a few housekeeping notes. So we will be randomly drawing a prize, a prize pack actually at the end of the webinar.

So be sure to watch right to the end for a chance to win. I will let people know who the winners are when we close things up. We're also streaming live on Twitter, YouTube, and LinkedIn, and we really, really want to hear from you. So please do tweet or post your questions in wherever you're streaming or right here in the chat.

And Hilary is working very hard behind the scenes, checking all those platforms for questions. So please post in. Participation is... It's what we want. It's really great. So again, our topic today is predictions for DevOps in 2023. Now, the caveat here is that predictions are exactly that. If we had a magic crystal ball with all the answers, we probably wouldn't be here.

However, that's also what makes them fun and interesting things to discuss and debate. So some of the topics that we will discuss include what it looks like to do more with less in 2023, so reducing tool chain complexity. And how can we make SBOMs more useful and actionable in 2023? We'll also talk a bit about how we should prioritize developer experience and improve productivity with that.

And also the rises in distributed engineering teams. How does that impact and what does that mean for tooling and tool chains? And a favorite one of mine. Platform engineering versus DevOps. I'll also add that this list is not exhaustive. And this is meant to be an open discussion. So we may veer off the path a little as we get into some things.

And as I said earlier, please do post your questions or talking points and we'll try to address those also if we can. So I'm very excited to be joined today by representatives from ourselves at Cloudsmith and also from two other organizations. Buildkite and Acqua. So this is the perfect time for me to bring our guests onto the stage.

So hi everybody. Hello. So yes, joining us today, we have Alison Sekelka, a VP of product at Cloudsmith, Sam, Sam Cochran, principal engineer at Buildkite and Chris Hughes. CISO and co founder at Acquia. So I'm glad to see everybody has joined. I just wanted to say originally Mel Kalfas from Billkite was scheduled to join us, but unfortunately she's, she's sick.

So we wish her a very, very speedy recovery indeed. And hopefully she can join us for another webinar. in the future. However, Sam has graciously agreed to step in. So thank you very much indeed, Sam. Really appreciate that. So if I could just ask everybody just to give a quick introduction about yourselves and your organizations, that would be great.

I'll randomly choose somebody to kick things off. So let's start with Chris.

Yeah, I'll jump in first. Chris Hughes here, CISO and co founder at a company named Acquia. We're a cybersecurity services company working in the U. S. with public sector and department of defense agencies, as well as commercial companies.

But before that, I've been in the sector in cyber, I should say, for about 15 plus years. Started off in military, have been a federal employee with a couple different agencies doing cloud and DevSecOps and cybersecurity. And yeah, just happy to be here and chat with you all.

Awesome.

Thank you very much, Chris. Allison, I'll throw it over to you.

Yeah. Hi, I'm Allison Sickelke. I work at Cloudsmith. You got to watch a wonderful introductory video of my the, that organization before the webinar started, but Cloudsmith's universal artifact management solution. So one place to centralize all your software artifacts that you use throughout your software supply chain.

You said that so much better than I could have, Allison, to be honest. So thanks very much. And finally, you know, last but not least, Sam. Please.

Hi. Good morning from Melbourne, Australia. I'm Sam. I'm a principal engineer at build code. I've been here nearly the whole journey and in various bits and pieces, we are started off as a CI CD provider.

We have a tool for creating CI CD pipelines. And we're working on some new products, including things like test analytics visibility into your test suite, the application of of

what you're building. Awesome. Thank you very much, Sam. I'm a, I'm a big fan. Actually, I, I wrote a lot of the documentation at Cloudsmith for using.

Cloudsmith and Billkite. So I found it great. So yes, thank you.

I've read some of that documentation. It's fantastic.

Oh, brilliant. Awesome. I I'll meet up with you and thank you in person for that at some point But yes, well look, thank you everyone that those introductions are very helpful. So look I know time is short so let's just jump in with the first topic.

I'll just throw this one out there for the floor to sort of whoever wants to pick it up first can go. I'll probably pick these at random as well but let's let's start with the one I mentioned earlier. So coming into 2023 I think that we are finding, and certainly the discussions that I have with some of our users at Cloudsmith, is that there is a drive to reduce toolchain complexity.

So there's multiple reasons for this, but I just wanted to sort of take the temperature of the room and get feelings on that. So yes, reducing... Toolchain complexity in 2023. I'd like to start with that. Who wants to go first on that one?

Yeah, I'll jump in there. I'll say I definitely agree with that, you know, leading and working with various teams and DevSecOps environments.

You know, we're looking to shift security left and bring all these, you know, great capabilities around SAST and secret scanning and SBOM and so on. But it becomes quite a bit to manage, especially if you have disparate tooling in that tool chain and everything is producing you know, findings in different formats and schemas and so on.

So bringing all that together in terms of tooling and output and artifacts is really important and it's causing a lot of cognitive overload on, on security teams. So I definitely think it's going to be a key area.

Yeah, I would, I would second that you know, for Cloudsmith, when we talk to our customers, they're really interested in being able to centralize.

How they're, how they're managing those software artifacts and not to jump ahead to some of the other topics that we have, but you know, part of that's trying to figure out how to do more with less than 2023 and really streamline your operations. And so I think there's a cost pressure and a bandwidth pressure to also streamline that that tool chain and reduce complexity and that cognitive overload for your DevOps teams.

The prolific number of products on the market I think embody a lot of this it's I went to KubeCon last year and it was interesting seeing a physical expression of the CNCF landscape in all of the booths around me, like it gets a bit overwhelming, the idea of the number of products, number of things you have to care about there's this Cambrian explosion of, of tools and capabilities and things to, to worry about during software development and how can we help teams.

Not have to worry about so many of those things, like to pull the abstraction layer of where you're providing

value up higher. Yeah. Actually, Sam, I too was at KubeCon last year KubeCon in Detroit. Was that, I was, I was amazed at the number of. Boots just, and I think some of that is being away from in person conferences for quite a while.

But I was stunned and certainly in my role as a technical account manager, I spent a lot of time talking to users. Customers of Cloudsmith, and there is definitely an overwhelming drive to streamline things, to work more efficiently, and also of course, I mean, to reduce total cost of ownership. It's a big concern the landscape's always shifting, but it is, it's definitely a thread that I find increasingly across more and more conversations that I have now is It's, things have got a little bit unwieldy and people want to work more efficiently.

And, and look, even internally, we, we've done the same in Cloudsmith. So we have slimmed down tool chains and tried to work smarter with, with better tools rather than, than a larger amount.

I think some of that's very interesting, like the, the way you know, e everyone runs applications and containers or, or some sort of nobody caress about hosts anymore like that.

Yeah. That abstraction layer has been dragged up. Right. And, and I feel like the same is gonna come through in, in DevOps and dev tool chains. It's, people are gonna care less about where things are run or how they're run, or, or they don't wanna understand the interoperation of, of each of the tools within a tool chain or a pipeline.

They're more interested in seeing the value out. That thing above. This idea of, of simplifying the offerings that we have and the capabilities that we have. Yeah, it's got to be the thing this year, I reckon.

Absolutely. Well, actually, Chris, this is probably a good thing to flow to you. So, I mean, I, just before the, I started this webinar, I came off a call with another user and their big focus, you know, is, is getting away from.

Managing their, their sort of on prem instances, getting away from hosts, getting away from applications that they are running in house and managing themselves. So they're very much looking, you know, sort of cloud native transformations for, for lots of, of their tool chain. And I think that very much plays into this topic, you know they're looking to consolidate, but also do not have to.

Well, own isn't the right word. It's still their tool, but just not, not have that management and cognitive and operational overhead. And I know Chris cloud native application development is sort of sort of one of your foretaste. So you, you must hear similar to this quite

a bit. Yeah, when we've seen quite a push where I am in the United States with both federal agents, Department of Defense and you know, commercial sectors in terms of cloud adoption for the reasons you're talking about is, you know, organizations are increasingly realizing that, you know, managing underlying compute and networking and hosting and so on is not their core competency.

They want to focus on their core competency, which is delivering value to their stakeholders and business customers. For example, that's kind of the allure of, you know, the cloud native paradigm and the shared responsibility model, for example. And they can lean into those cloud service providers, whether you're talking IaaS, PaaS, or SaaS, and you kind of offload some of that responsibility, that administrative overhead, and so on to the CSP, which is a major, a major improvement in terms of the burden and, and overhead that they have to manage on their end.

Yeah,

that's absolutely true. Allison, any final thoughts on that topic just before I, I, because I know we're, I know we're going to revisit revisit this when we talk about reducing complexity. We maybe won't. But anyway,

I think it's interesting the point Chris made there about organizations wanting to focus on their core competencies, you know, it's We're just reaching the end of January, and I've heard that from several customers already this year that as they're looking at reducing that tool chain complexity a big part of that is they want to make sure that everything that their developers are doing is value add to what their company is trying to accomplish.

And they don't want those engineers being system admins or spending time maintaining systems or processes that don't ultimately benefit those organizations or contribute to their core competency. And I actually think that is sort of interesting as you lead into the platform engineering side of the the platform.

Side of the conversation to, you know, some of that's in that same space of saying, you know, we want to make sure that our developers that their time and energy is focused on advancing our business and our, our core competencies.

Absolutely. I noticed an interesting comment in the chat just from Neil that cloud hosting takes a lot off us admins plates quicker to change instances with less downtime.

I totally agree with that as someone who in a former role was an old school sysadmin. With on premise servers and racks and things like that to watch the evolution to where we are now is it's fascinating actually I know it's not a role that I do anymore, but I actually agree with Neil there that it frees up you know, frees people up to focus on core competencies.

I think I said a line in a keynote talk. a year or so ago that said you know, if it isn't, if, if the, the application that you're looking at isn't core to your, you know, your own sort of product, if it's not something that you're going to sort of acquire and build in, then just buy it as a service, you know, don't try and build it yourself.

Don't try and run it yourself in house, but, but just buy it as a service. And that, that was advice that I think is still standing today. So awesome. Well, in that case, Let's just change it up a bit because Allison, you mentioned something there that I would love to touch upon, so it's a little bit of a sort of side path here, but this is something that the people say.

Actually, people said to me at KubeCon in Detroit, so I was. I was saying everywhere, platform engineering, platform engineering was everywhere. I even got refused a ticket to a platform engineering party on one of the nights, which I was incredibly upset about. But so but basically platform engineering versus DevOps, it's 2023, we're moving forward.

So is, is platform engineering just an evolution? Of DevOps, right? Is it, or is it a rebranding of DevOps? What do people think of that? So that's, that's an interesting one. Because I've read a little bit about this the last couple of days and there seems to be all kinds of opinions on this. So I suppose I'll throw that one to, I'll throw it to Sam, just, just, just to kick us off for a bit of fun.

I was thinking about this over the past couple of days as well cause it's, it's been thrown around a lot, but, but forming an actual opinion cause you can call it any way you want to call about it, right? But to me it's, I think you still sort of practice DevOps on a platform, right? Like it feels to me like it's about shifting that bar up, shifting up that abstraction layer.

So you see tools like Spotify introducing stuff like backstage and, and providing. Centralized places for developers to go in and use standard patterns means that there's less complexity in the tool chain because it's already chosen for you and the security can be pre vetted, like you can have a set of tools that is known to be up to date and reusable To not have to have the right vulnerability checking in place and all those sorts of things.

So like, if you can engineer a platform that is safe for developers to then go and build your core business value on top of and share as much of it as possible, like that feels like the inflection is it's dragging that abstraction layer up, letting your developers focus on the thing that's actually valuable, being sure that you've got good security story and all the right pieces in place below.

As a centralized effort and then like, how much of that can, can you get away with not having to do yourself? Like how much exactly can you find great tools hopefully like the ones that we're talking about here to, to, to plug in there and provide that value and know that it's secure and by default and all those things.

Absolutely. To be honest, I think it was a bit of an unfair question to just throw out. Do you like that? I do now and I'll put my hand up and admit that it was a little bit of an unfair question. Because it's, it is, it isn't, it is, well, it is like you said it, it is like you said it. I wonder, yeah Chris, any thoughts on that before I pose my, my little twist on that question, I suppose.

No, I actually

like his take on it a lot. I think, I think you opened your can and worms. I've seen like a lot of heated debate of, you know, is is this the new age of DevOps or is it, you know, different than DevOps? And I think they're complimentary, you know, in the sense that it's A new form of engineering and it DevOps methodologies and practices.

For example, when we talked about, you know, how cloud can abstract things for customers, we're seeing the same thing with platform engineering. They're trying to do that internally for development teams is abstract, allow that administrative overhead and nuance away bacon, security guardrails, compliance requirements, things like that.

So it's very complimentary, in my opinion,

really actually really like that. I really like that. I see comments in the chat. Jonathan says the platform engineering seems more encompassing. That's an interesting take on it. Yeah, I'd like to think about that one before I comment on that. I suppose here's something just, just for the wider group and Allison, I know you didn't get to comment on that.

Maybe you can comment on this. It sort of ties into what you said, Sam. Do, do you think that platform engineering kind of has some ties to like, you know like platform as a service? You know, you mentioned about giving a common tool stack for developers where you can bake in security, you can bake in sort of best practices and things like that, maybe not in the terms of the platform as a service that we know and love, like we've all used it, I suppose, at some point, but maybe sort of almost, almost like an internal take on that.

Does that sound like, does that resonate? You know, what do you think about that, Alison? Does that sound reasonable?

Yeah, I think, I think it resonates and, you know, I, I'd build on what Sam and Chris were saying, you know, it ultimately feels like an evolution of DevOps. I also think it's really easy to blanket say what DevOps is or isn't, but really each organization, it's a little different and each organization's on their own journey to embracing DevOps.

Platform engineering seems like an evolution for folks who are a little more further on that DevOps journey and whose, you know, software architecture might be getting more complex and harder for the development teams to be able to manage or want to manage some of that infrastructure side of the, side of the house too.

And so, you know, platform engineering is really just an evolution of DevOps and also basically saying, how can we make sure that our developers are you know, doing the thing that is within their wheelhouse and, and matches their expertise and they don't have to become an expert on the full stack and all the tool sets that's being used there.

I think that's absolutely true. So I was going to just say, but you said it already that and one of the comments in the chat actually is that DevOps just keeps improving and that's completely true. I mean, as far as I remember. I remember the first time I saw DevOps being sort of thrown around as a phrase.

It was, it was really just developers automating their, their, their build and deployment pipelines at the very start basically. And then it expanded out and it started encompassing these bigger, more complex tool chains. And there's so much more going on that it needs to become bigger and all more all encompassing.

As we said earlier in the chat as well. So I don't know, everybody has an opinion. I suppose we're all entitled to them. But that was, that was, it seems to me that that is, is kind of what platform engineering edges towards. I have no doubt that when I get off this webinar, I will be inundated with people that tell me that I'm absolutely wrong and that it isn't that, and it's something else entirely, but that's what makes it, that's what makes it interesting.

Right. And it sort of happened at the same with, with DevOps at the start as well. So I suppose just to spin this in another direction. And maybe this is relevant to both toolchain complexity and platform engineering evolution versus whatever way you want to phrase that. The rise of distributed engineering teams and maybe not just engineering teams, right?

Maybe just the rise of distributed DevSecOps teams or, you know, development teams in general. What does that mean when we think of the toolchains that we're used to? The way that we build sort of applications and, and internal pipelines and things like that. Obviously, and we've spoke about this at length now for, for over a year, more than that, because distributed working really obviously accelerated.

And we're all very well used to that now. But I think we've all had the time to evaluate the changes that we've had to make to accommodate that. Maybe some of those changes were by choice. Maybe some of them were sort of enforced. But what do we think? That rise in distributed engineering teams has what kind of impact has that had on on toolchains and complexity and experience?

Who wants to volunteer to start that one?

I'll jump in there first again. I guess you know, from my perspective, I always think of it from the security perspective very often. So, you know, I think that the distributed working situation in terms of toolchains has the biggest impact when you think about access access control. How people are navigating into the environment, accessing those tool chains and, you know, the permissions associated with it, whether the device they're using is, you know, a corporate owned device or B.

Y. O. D. For example, and I understand I start coming from where they're located at device posture in terms of the posture of the device are connecting from. I think those are all key considerations, especially when you think about software supply chain security. And you realize that you know, malicious actors are increasingly targeting those build environments, those tool chains to compromise downstream consumers of software.

It's definitely a key, a key area that organizations need to pay a lot of attention to.

Yeah, that's, that's, I would agree with all of that, Chris. I would.

Allison.

Yeah, I guess you know, just building on that a little bit for us, we see a lot of folks emphasizing the value of cloud native tools when they start to talk about those distributed teams to so that ability to ensure availability, reliability, scalability of the platforms that your internal teams are using is really important as you're talking about having those engineering distributed across the globe.

And it can really be a differentiator for customers who are able to leverage those cloud native solutions. Okay, thanks.

Sam taking, taking Buildkite as an example, you know what's, what's the sort of challenges that you've seen, both, both, both internally yourself accommodating other distributed members of Buildkite and also obviously your, your, your user base is distributed globally anyway. So, you know, what do you, what do you think there?

Yeah, it's an interesting one. So, so Buildkite is a company internally we've, we've been around first forever and, and have always been a distributed engineering team. It's been interesting to be on the, on the front of that. Yeah, I think just, just communicating, coordinating seems like the biggest challenge, like, being really effective as an organization.

They're, like, we use a tool called Basecamp, but, but that's probably beyond Scopia. It I'm, I'm very interested in the, like the securing the the actual endpoint devices, how you access your product infrastructure, how you access all of the tools that we're talking about here, like how do you access the platform securely if you are constructing your own platform and engineering it.

So, so Buildkite is we have an interesting Stance on this. I guess because we are a hosted platform, we're only a hosted platform. But we we don't run an in compute for, for actual ci cd workloads. We, we leave that entirely to you and your own infrastructure. But what it means is that we secure the endpoint that most users are coming to interact with the system.

We have a hosted platform. Which has benefits here, like if you're using hosted platforms, like I presume Cloudsmith might have an offering that's the same. Then you're offloading a lot of that security story and, and like all of that stuff, you've got a trusted third party that has a hosted platform that's been through rigorous compliance requirements and all that stuff up front.

And you don't have to worry about it. You can focus on your core competency. But for us, like then letting you run the compute also means that, for example, Bilkite can't see source code. But it doesn't have to interact with those tools that might be. On your side of the boundary, within your fence.

And so you can have the strong security story where it's there, where it's valuable. Around your IP and around whatever you might be doing within that platform itself. So it's just interesting. I think different people explore this in different ways. But yeah, it's as we mentioned, like, the complexity around this stuff seems to be ever increasing and I think people are wanting to own less of the story if, if possible and so having having done this hybrid model for a long time, sort of starting to see more people try it out and do it in different ways because it means Yeah, you can trust someone else to do it securely and well, as long as security is built first into the product, like it always has been with Billkite, it can be a good option.

Yeah, absolutely. You are, you're not wrong, Sam. So Cloudsmith also is hosted only. So we are hosted only as well. And we obviously are very, very focused on security. One thing that you mentioned there, which I thought was really interesting is it also matters. Compliance and regulatory reasons. So, you know, a lot of our users they, they need to have a vendor that has, you know, ISO 27, 001 certifications, SOC 2 certifications and that goes a long way, you know, towards that point of securing.

The platform and that that carries a lot of weight with those with those users. So we put a lot of a lot of stock in the security. Obviously we do. We have to. But I think that that's what people that's what people want. That's what people want the their vendors to do. And with distributed teams as Cloudsmith as well.

We're remote first same as same as BuildCite. That's where we all are and we have. Both Cloudsmith team members all over the globe. Allison is in the States and I'm in Belfast in Northern Ireland. So we do have to, we do have to meet that challenge. Interestingly enough, one thing that you brought up, which I thought was interesting because we had a talk about this ourselves lately is not just the tool chain, but communications communications is, is a bridge, you know, something that needs to be, to be bridged properly with fully distributed engineering teams, fully distributed teams for that matter.

Okay. So we are. It's sort of chock full of communication tools and we actually slim those down. So we, we, we now have less places where we collaborate and we communicate in Cloudsmith because it was, you know, reducing the noise and it tends to do that. So, of course, we do a lot of calls and we do a lot of chat, but it's very much in the same vein of just reducing complexity in the tool chain.

I know it's not a DevOps tool. I know chat is not like that, but It was, it was a really really core part of, of getting us to work together better. I thought, so that's my, that's probably

more in that thread because so our, our CEO Keith, who is one of the founders of Billkite and built a lot of the early products.

Gave a great talk recently about storytelling in DevOps. Which is about communicating, right? Like we sort of treat it as a thing that happens externally, like outside our tools. And then the tools are full of information, sometimes too much information that we can't, you know, find the actual signal amongst the noise.

But what if those tools helped us? Navigate them better and communicate with our colleagues about what we're seeing and actually tell the stories about what's in that data. I think there might be something there that we start seeing 2023 as well, where the tools can help us, like the tools are where Our work lives.

And so if we can talk about our work in the place where it lives, tell better stories in the place where it lives visualize it in new ways, collaborate in new ways that might be helpful too.

Alison, I think this is one of your one, probably one of your more favorite topics.

Well, I mean, I've been 2019. So pre pre pandemic, I was opting into this lifestyle. And I do think, you know, it's interesting, a lot of DevOps is practice and philosophy and culture, and that's really what we're saying, is that when you're a remote first organization, you have to define what those practices and culture is, and, and, and how you can leverage that to get the best work and the best outcomes for your organization and your team.

And so, a little outside of DevOps, but I do think there's some overlap. And, you know, what Sam's saying there, for us internally, I can speak a little less towards our engineering team, but within the product organization, you know, Making sure we're really intentional about leveraging tools like notion or things like that and saying, this is where you go to find the information for what you're working on.

And just helping build up that, that clear practice and standards for our organization really helps with that collaboration.

Yeah, absolutely. It's something that we're all trying to get better at, I think. So, it's not exactly a prediction for DevOps in 2023, but it does impact DevOps in 2023. There's no doubt about that.

I think, anyway. So, awesome. Okay, well, just to move things along, time always flies on these webinars. Time moves quicker than you think. So, this is probably a big one, and I'm going to throw this one straight away. The, the Chris, because I know that this is in his wheelhouse, so to speak, but I think we'll all have something to say.

So software bill of materials. This is not a new phrase. It's not something that we're just talking about for the first time now, but this may be the year that it really rises to prominence. takes on more importance for a lot of organizations and a lot of teams. So how, how, what can we do? How can we make SBOMs more actionable and useful in 2023?

Yeah, I mean, I definitely agree with you. This is going to be the year or coming years, I should say for SBOM. You know, we saw a lot of traction, obviously in the United States around cybersecurity executive order. Efforts with agencies like NTIA and now CISA around S bomb adoption and evangelism and tooling and things like that.

And then of course, you know, even in the EU and the Cyber Resiliency Act, if you take a look at that, it requires S bombs for product manufacturers to, you know, kind of extrapolate those components that are in those products in terms of making them actionable. I think that's where things like vulnerability exploitability exchange for folks that are familiar with that is, you know, essentially going to bring kind of some signal to the noise of the S bomb is one thing to tell developer.

Hey, you have, you know, 700 vulnerable components. It's another time of those 700, you know, 36 are exploitable, for example. So we talked about, you know, bringing signal to the noise and trying to drive down some of that complexity we talked about with infrastructure. We need to do the same thing when it comes to vulnerability management for developers.

We don't want to, you know, add a lot of friction, impede their velocity and let them focus on what's actually exploitable, what brings the most risk to the organization and have them take action on that.

Yeah, you know, I would say a year ago we were asking customers about S bombs without a lot of response or engagement. And we're finally starting to see customers come to us and ask us about S bombs and how they can leverage that tool to be more effective. I think it's we were talking about where S bombs in the hype hype cycle feels like we're coming out of the trough of disillusionment and moving into the slope of enlightenment.

You know, I think a big piece of that is that it's not just about requiring these companies to have S bombs, but it's actually helping them to get value from it. So like Chris was saying with VEX and other tools that actually make those S bombs useful. So it's not just a requirement, but it actually solves a problem for those customers and actually becomes a value add for what they're trying to do within their organization.

Sam, any thoughts?

Yeah, it's an interesting one because everyone's tackling it in slightly different directions as well. Yeah, so like we've had a lot of a lot of customers displaying interest in provenance and attestations as well as the actual S bombs themselves, like being able to prove and, and, Do the compliance dance making sure the policies are being enforced consistently.

So how do you It still feels like s bombs. There's no one standard. It's like a couple and then how are people navigating those? How do you make it actionable? We've seen some some great like Seeing lots of people creating different types of pipelines with different tools and different ways of making them actionable you know raising those vulnerability alerts pulling them into the place where the code is being written like Raising them as github issues that can then The action with buttons and like building those sorts of workflows themselves.

Which it's interesting to see people building that stuff themselves to kind of mimic some of like GitHub's depend upon stuff, but in a more formal and policy enforceable way So, like, seeing the evolution of that and the standardization of that, like, how are we going to see the standard ways of creating SBOMs and then signing and shipping those as part of the container manifests and, like, watching these actually consolidate around a best practice way of doing things and then turning them into something that developers don't have to implement themselves, but can just drop in, like for example, in Buildkite, looking at, like, what is the plugin that people are going to reach for and, like, drop into their pipeline and it provides.

S bomb generation and, and make sure that things are in packages and then of course the policy at the end, like those sorts of things seeing the practices emerge and consolidate and then not having to be thought about will be interesting. Yeah.

Go ahead, Allison. Please.

I was just gonna say, I think it's really interesting to see the open source solutions that are developing in this space.

And, and, you know, basically we're saying, how can you secure your open source dependencies? And we're seeing solutions come out of that open source community to help answer that question. I think that's really interesting and fun to watch. I also think that. To some of what Sam's saying there, you know, it gets really interesting at how you manage this at scale.

So really when you start to talk about trying to manage your software supply chain across your entire organization, how do you develop a developer experience and user experience around that, that makes it easy for teams to be able to implement and manage that as well.

We're back at pushing that DevOps problem into the platform engineering problem, right?

Like you want to consume a component that people can, can develop and operate on, but don't have to like build the pieces and plumbing.

I think so. I mean, well, the first step to adoption is to make things accessible and, you know, frictionless and easy. You know, that's, that's the way to win people over. But there's no doubt.

From, from my perspective, sort of in the front line, yes, I agree with you, Allison, a year ago, when I was talking to users of Cloudsmith and customers of Cloudsmith, the landscape, especially around what they wanted from SBOMs and what they needed was still quite foggy to them, they weren't very clear. Now, going into 2023, I'm hearing increasingly from those same users and customers that, yes, this is something that we know we need to get.

On top of like, like Chris said, I mean, there are standards coming down the line and there are requirements coming down the line. They are aware of that. They're maybe not quite there yet, but they're certainly very interested. And look, Sam, the same applies for. You know signing containers in total attestations.

It's all in there and they're thinking about it all that they, but what they really want. And I think you said this, Chris, is they don't want, you know, a wall of data about packages and dependencies and CVS. What they want is, is actionable. Data, you know that they want the path forward there that that's easily identifiable for them that they can take direct concrete actions upon.

So I think some people still feel a little bit overwhelmed by it at the moment. But it definitely feels like maybe, you know, maybe by 2023. We won't have, you know, a perfect sort of solution at the end of this year, but it definitely feels like there'll be a lot of progress this year towards that solution.

So watch this space when we do our December webinar, none of these predictions will be true and I'll look like a fool, but but it's still fun to think about that. But no, I definitely feel from, from talking on the frontline with users of Cloudsmith as a product and of course. We're in package management, so artifacts and signatures and attestations, it's core to what where we think the landscape is moving.

I definitely hear that a lot more now than I did before.

There's an analogy with we, we made a change last year to when you come to a build firstly in CICD, most people don't care if the build is green. If it's green, Everything's fine. You move along. You probably don't even come and look at it.

If it's failing, you don't care about anything that passed in the build. You only care about things that actually failed. Like you want to make it actionable, right? It's the same principle. So, so we made some changes to really pull failures to the forefront and show them earlier and a few of these things.

But I could see the same patterns with S bombs, right? Like if, if everything's okay you just want policy to be green. You don't even want to look at it. Like your deploy just keeps going. But if it's, if it's red, like if there's a critical vulnerability in one of your dependencies, you just want to know about that bit and like make it actionable and give me a button or something like make it as easy as possible.

That's it. Seeing those patterns emerge. Like we're already seeing some people do it. I think Cara Carey did a from Cloudsmith did a lovely presentation about using SIFT and GRIPE, I think to create an SBOM and then highlight the critical vulnerabilities and not care so much about the rest of it.

So those are consistent tools as As Allison was mentioning, like they, they are already providing some of these insights and those, those actionable things seeing those, those become common patterns and becoming pieces that you can just drop in and use without thinking too hard about it. Yeah, that's, that's the interesting thing.

I think. Yeah.

I really liked the statement of give me a button. So sort of you mentioned, you mentioned earlier, sort of, you know, almost make it as actionable as dependable, you know, so nice and clear. Yeah, I think that's a very good, a very good point indeed. So, Chris, any final thoughts on that just before we, we sort of move, move on to the next one?

No,

I think it's spot on in terms of make it easy, give me a button kind of thing is we're seeing a lot of innovation around tooling to help, you know, show developers what is the problem, what dependency of is of concern. And, you know, where are some alternatives, even in some cases that they can explore to quickly remediate the situation and move on with the building deployment process.

So I think Sam was spot on.

Awesome. Awesome. Excellent. Well, I, I know we only have a couple of minutes left and I do need to announce the winners of our Cloudsmith prize packs. Of course, I think that's probably the highlight of the webinar for a lot of people. Certainly is for me, even though I don't actually get one.

So I just like to announce the winners, but just very finally, then a couple of quick minutes before I do that a nice, a nice topic for everybody. So 2023. What does prioritizing developer experience look like? So we've all heard user experience. I'm very familiar with that. And I spend all my time with users.

What are the top things we should be thinking about for prioritizing developer experience? And we're not allowed to use the same answer of just give me a button. That's too easy. So any, anything else that people think developers really want, you know, just to make their lives easier, just the, the, the, the highline topics.

yOu know, I think it's some of the things that we talked about here, helping them understand what's the tool set that I'm supposed to use to be effective in my job. How can I easily find the right information I need? You know, that's where some things like backstage are interesting. How can you make onboarding and ramping up as a developer at an organization really easy and seamless.

And help them understand you know, where they can go to find information and documentation and solve their own problems.

Excellent

uh, i'll jump in real quick and also say, you know for anyone not watching the chat check the chat There's some amazing and some funny comments in there so nonetheless, I think another thing we'll see a lot of attention for is you're trying to bring Governance, risk and compliance and policy into codified formats.

You know, so instead of, you know, asking for mounds of digital based paper documentation, starting to bring some policies, code, compliances, code and things like that into the pipeline into our processes of how we deploy software, for example, I think it would be another area that's going to see a lot of attention.

Awesome. I suppose. Just, just very quickly for myself then developer experience, just even internally in Cloudsmith, a shout out to the Cloudsmith engineering team who did a great job in improving that onboarding experience, Alison, for new engineers at Cloudsmith. So we have a much better development environment now.

It's not exactly click a button, but it's, it's a lot more easy to spin up than previously and easier to debug in. And I think the guys are all very proud of themselves and rightly so, even though I don't develop for Cloudsmith, I was very impressed when I saw it. I thought that has got to make things easier for people on boarding and just getting started.

So yes, and you're absolutely right about the chat as well, Chris there. Hillary's hilarious Pepsi jet. I remember that advertisement. Yes, Pepsi points. Awesome. So yes, well, we've right ran right up to the last minute folks. We've had our 45 minute mark, I think at this stage I just need to thank you all for coming along and taking part.

We could talk for longer. It was extremely interesting if, even if I will be corrected on some of the things I said afterwards, but that's, that's half of the fun. So yes, thank you very much. Sam, thank you very much. Chris, thank you, Alison. It was a pleasure to chat with all of you. I hope we get an opportunity to do it again, and I'm already seeing in the chat who won, who won, who won.

So the names that I have while I turn my head to my other screen four winners of the prize pack. First is Cody Weehunt, Neil, yeah, Neil Berkowitz. Yeah, Waleed Malik and Greg Thompson. Lucky folks. Yeah. Oh, we've got some happy people in the chat already. So Hillary will look after you and get the price packs out to you.

So yes, everybody. Thanks again. Just before I close you can find us all in our respective places of work and please come along and try out all our products. We would appreciate that a lot. But it was a pleasure and I look forward to talking to you all again. Thanks, Dan. Thank you. Bye.