DevOps Decrypted: Ep. 17 - Are 3rd party devs an invasive species or essential to the health of a product?

Laura Larramore:

Alright – hello, everyone and welcome to the DevOps Decrypted podcast! I'm your host, Laura Larramore, and joining me today are Jobin and Rasmus, and Jon Mort.

And we're gonna talk about some cool topics today and see what we get into.

So, first up is this news about Reddit and third-party market apps. Who wants to start us off with that?

Rasmus Praestholm:

I can introduce it as the resident nerd. Well, we are all nerds and different flavours...

But oddly, even though I'm not really that much of a Redditor, I do follow it, and I am a big big fan of, you know, open source development, and so on. So, a thing happened in that, you know, Reddit has been a cultural institution for many years. Now the core of the product did not necessarily provide really good tools for moderators and the sorts. So a third-party development ecosystem has developed over the years, with a lot of third-party apps that actually access the Reddit API to get you the content in different formats.

This was very much used by the moderators that did not think there were enough good moderating tools on Reddit. But the third-party solutions, you know, figure that out – then, and this might be where I'm another sketchy of whether this relates completely or not – the AI explosion happened. And there are these models that are being trained on an immense amount of data online which include credit posts and Stack Overflow, and all those kinds of things. And Reddit then has been looking for ways to monetise.

And maybe they sold that and like, “Hey, wait a minute. We have all this stuff. We can sell this instead of just letting people scrape it for free”, and decided that, oh, it's time to start monetising our API, possibly at the level of which it would make sense for AI – which is kind of like higher because they can do one enormous scrape and then process.

Whereas regular users do constant pulls because they're just, you know, viewing the site over and over again on different days.

So possibly to kind of monetise for AI.

They are completely screwing up third-party developers who are doing much more API pulls because their actual end users are using the site.

So some of the popular third-party applications are looking at bills in the double-digit millions of dollars a year for something that used to be free.

Not a lot of them have much, you know business built on top of – a few of them might have, you know, donations or subscription tiers, but it's a trickle. It's teeny, tiny. And all of them, to my knowledge, have said we're going to have to close shop when this goes in. It's too expensive. We can't do it.

And there's understandably a lot of drama about this, the favourite of which is putting various rules in place. That many, you know, of the top tier subreddits are now exclusively content about John Oliver.

Which is hilarious, and you should look it up if you haven't seen it yet. It is wonderful!

It is really the internet at its core. But in our context, it comes back to, hey, how do you handle third-party developers? How can you monetise fairly while not alienating your community and so on and so forth…

Jobin Kuruvilla:

I mean, this is very interesting. Especially us being Adaptavist, you know, a company that actually works with a lot of vendors and creates add-ons and apps on top of the functionality they offer. And we have a lot of customers who are actually making use of it. Right?

What is interesting to me is, you know, the vendor itself decides to shut down.

The additional functionality offered by the third-party developers. Obviously, marketplace – that's a different business model, right? And I believe that a lot of vendors like Atlassian, who does wonderful things with the marketplace, and we are actually on the right side of the spectrum there.

What's gonna happen one day if Atlassian decides, you know, call it quits and shut down the marketplace, I mean, that's definitely going to impact a lot of customers. Not that Atlassian is ever going to do that.

I think they showed the right example, right? In this case, what Reddit is doing is okay, yep, we are going to monetise it. We can monetise it. How about we monetise it? By, essentially, you know, destroying the third-party vendors who were actually relying on them to provide this such a functionality – doesn't sit well with me, Jon. What do you think?

Jon Mort:

I agree. I think I particularly am some of these apps I've been around for much longer than the running mobile apps have been. Part of the success of Reddit has been like leaning on the on, on the is this thing, and it's kind of…

I think I see it as being a slight against the historical community that's been built up in one way. And yeah, this seems to be a kind of stubbornness here, as well as to compromise or negotiate, or something which is best for all of the community. And I think there's possibly a difference here between like a content company and a company who's selling a product in that sort of thing. So I can't imagine – like a decent part of Atlassian's success has been, how extensible it is, and how you can bend the tools to meet what's needed.

And the marketplace is a real accelerator for that. You see other companies that have that sort of similar ethos – like Microsoft, are a good example of how enabling developers and supporting them has helped to build Microsoft's business.

And there's been a few missteps along the way. You could see similar to Apple and like the apps on the app store and things.

But I think these content companies… I've got a real problem in, how do you monetise things? Like Stack Exchange? They have a similar set of strikes going so from moderators, because of this, the Stack Exchange policies. And that's all about AI and accessing that data there.

I think it's a really difficult place to be.

Particularly when your content and your things are being used for other companies to be, you know, making a lot of money – like open AI is making a lot of money off the back of all of the brilliant data that's Reddit and Stack Overflow, produced via their communities.

Jobin Kuruvilla:

I think the community is the keyword there, right? I mean… When all those third-party developers come together, they're building, they're innovating, and they have more ideas. They're creating things that the original vendor wouldn't ever have thought about, right? And when you come together as a community, you're able to deliver more value to the end customer.

I think that's what's missing if you shut down all that. But they develop this and that. That's what makes me a bit sad about this whole fiasco, you know?

You're feeling, you are leaving that community out, and to be honest, I mean…

As you mentioned, Atlassian has done really well with this – you actually see that you know, the third-party when they're starting in it. And if you go to a community when they're at Atlassian, you could see so many people in there, you know a lot of them, third-party vendors, and you wouldn't see – I'm not going to name any names – you go to another vendor where there is no marketplace integration. No, there are no third-party vendors like that. You don't see as many people there. There's no community feeling there, so I don't…

That's really key to this whole thing, at least in my opinion.

Rasmus Praestholm:

Yup – and I love that you bring up the Stack Overflow setup, Jon, I should have also remembered that. Because, yeah, there's a whole strike there again, because of content management and community response.

It is distinct which is also interesting because the setup with Reddit is definitely, you know, Third-party development. They've been able to use the API. They made awesome, cool things, but just effort years of, you know, of the heart put into it.

And the response to that was as ham-fisted as you can imagine because it's Reddit! Of course, it is! They responded with John Oliver, and jokes about the landed gentry and all this fun stuff! It's madness, but it's just such a terrible, terrible reaction from the, you know, the owners of the setup.

But that's about third-party development.

With Stack Overflow, it was about because all these, you know, ChatGPT-generated answers suddenly started flooding all the different, you know, sites under the Stack Exchange.

The moderators were, you know, cracking down on it because they want to curate their content because that's what they do. They don't want all these generic, no-effort answers that may be completely wrong.

And that's, you know, doubly important, because if it gets posted there it's gonna get re-ingested into the next machine model, and it gets worse. And the community, the community managers are on top of that, and they're trying to fix it.

But then the owners come back and say, “Oh, wait a minute. We don't like you cracking down on all this stuff because we think you're hurting engagement”, and you know, their numbers.

And then again, it's just it becomes this terrible interaction between the owners that be, and the community – even though it's realistically very different situation.

Jobin Kuruvilla:

Seems to me like the freedom of speech, and debate, right?! How much freedom you should have on Stack Overflow and things like that?

I mean, you're right about the content. If the content is not right anymore. It's going to be re-ingested again and used somewhere else, right? And ultimately all those answers that ChatGPT is going to give you. That's not going to be the right answer.

That's what it thinks is the right answer from my 100 other posts that I found in Stack Overflow or elsewhere. So I think it's key that community engagement is there to crack down on false information or wrong information.

Rasmus Praestholm:

And there are solutions here like, even though I'm maybe not the biggest fan of Atlassian myself, they do seem to have the marketplace stuff and the setup, you know, worked out – because they have clear conditions. They have a nice marketplace, and everybody knows, you know, kind of like the playing field and the rules that they're dealing with.

And they are not putting a foot in mouth, left and right about all these, like, yeah, we know you did all this wonderful stuff. But we're gonna do something completely different. So kudos to them for having, you know, you know, set up that part really well.

It's not necessarily that these things are impossible. It's just you need to find that balance between monetisation and community development.

Laura Larramore:

Yeah, I think there may be a point where you can hurt your community to the point that your value may not be worth the monetisation, too. So very interesting.

Rasmus Praestholm:

And maybe I can carry that into a similar topic that I've been bubbling around in my head lately because another vendor can maybe be relevant to this area. And maybe, Jon, you have some. You know, another with more examples on this?

But to me, I started wondering about what's happened to Slack… because after the acquisition by Salesforce, the culture, it's like, has been changing substantially. The old CEO is gone. A lot of founders are gone. A lot of the original, you know, vision and stuff that made it work the way it did. Almost in a little bit akin to Reddit, and that it was just, you know, wild exploration journey that you went somewhere neat is now becoming more monetised and and and set up.

And to me that got into wondering… Is Discord the new Slack?

Because they really have that cultural feeling, even though Discord is, you know, a voice communication platform that started as a way for gamers to talk to each other while they're blowing each other up.

It is realistically becoming, possibly, the new Slack because of how well they are engaging with their community and how well they are keeping all these innovations and novel features going.

They are. There are companies now that completely bypass Slack and just go straight to Discord.

Jon Mort:

Yeah, I mean, I think it's a really viable platform, for you know, as a chat in real-time, communication doing right for, and I think for, particularly for like smaller projects and kind of open source things, I think it's ideal, really in a lot of ways, because it's super easily accessible, and it's something which you know, like I mean it’s… I'm always impressed with when I use it, how easy it is to use and to jump on a channel, switch between devices… It does a whole lot of things just effortlessly.

And I think that they've also done a great job with bots and the integration point, that you know, it's been pretty easy.

And you got companies like Midjourney... I think it's absolutely fascinating that their entire – the only way you can access the tool is through a Discord bot.

It's just mind-blowing. If you think about that down there, things that that's like, we've built an entire business, like huge business off of that as a delivery platform. And it really fosters community, and that is the way that you use that.

So yeah, I enjoy using Discord.

Jobin Kuruvilla:

I mean, I'll probably be a distant voice here, I mean, that's only because I haven't used Discord much. I mean, I don't see a problem with Slack, and it does seem like a lot of the cooler younger generation – like Jon here – are attracted towards Discord. But that's more like, you know, Facebook versus Insta for me. I mean, a lot of the cooler generation is on Insta, but I'm still on Facebook!

So similarly, I'm still on Slack. And I don't see a problem in so like especially, you know when it came to sometime back, discussion around creating service packages around Slack, I was wondering…

The tool is so intuitive. You don't really see a reason why we should be building any service packages around Slack because you know. Everybody can figure it out by themselves. So I kind of voted against it at that point.

So I thought, Yeah, that option of Slack is pretty easy. So what you're saying is, you know, Discord is even probably easier. But could that be just a perspective, or?...

Jon Mort:

Well, it's not about necessarily being easier. I think it's some of the tools being more front and centre for you. So one of the problems that you have with Slack is that they kind of, they gate kind of community management and things by price. And it becomes really like, some of the tools for, like suggesting or enforcing good Slack etiquette, you've got to pay for, and it seems like the way that Salesforce has gone out to monetise it has been through, like deficiencies in the product.

Whereas the way that Discord monetises it through scale and usage and that that seems to be the kind of the approach that they take.

And Slack has this little bit of a policy of, you know, features starting off in the premium end, and then and then coming down the various, the various tiers. But things don't, it doesn’t happen very quickly.

And yeah. So I think, yeah, I just don’t like the business model of trying to force the monetisation, to force you up a tier.

Rasmus Praestholm:

Yup, yeah. I think the way they differed was that Slack always kind of started out a little bit more corporate.

It was, you know, had free tiers and all that kind of stuff.

But they had an interesting culture behind it, because they did sort of also build out of a side project that became, you know, real on this, or I’m getting them mixed up with Discord, I don't think so…

So they had some cool things going on, and they did neat things.

But after the Salesforce acquisition, they sort of had their moment where, well, we're going to monetise even more. And we're going to kind of drop a lot of the culture. So it really just became generic – well, yeah, you can do chat-ups on there. It's fine.

You're okay if you pay for it if your company pays for it.

But you would probably not use like very often anymore for anything that's not like, a day job.

Do you really go for Discord for that? Where they didn't start with that at all? They, they said, literally started as a platform for voice chat in games.

And they always had this massive focus on culture and fun and innovation, and so on. And then over time, it just turned out that companies also kind of like having fun – and that easy access thing. And then third-party ecosystems developed to help support that with all these advanced bots, and applications that are like entire bots, and you can hook it all up.

And the weird thing Discord did was… they didn't lock down.

They just kind of supported this and kept going.

But in part, maybe that's because they're still running on VC cash or something like that, and they haven't had their Reddit moment where they're really starting to heavily monetise and become revenue-positive.

I have no idea there.

And that may be happening right now because, even, after I started thinking about this topic.

I just, you know, found some announcements – I'm not sure if it's super public yet, or if it's just being rolled out to some servers – but Discord is beginning to now building more tools about subscribing to servers and making tiers and even like introducing almost microtransactions on servers.

So they're beginning to explore a little bit with that whole like, how can we make this truly profitable.

But they haven't had the Reddit moment of, let's lock out all the third-party developers. We're doing our own thing now.

So I'm hoping that they will, they will stay closer to, you know – they don't take away those tools that Jon mentioned that make it really easy and nice and fun to use this core, but they still try to monetise different corners and leave some of the third-party developers, like Midjourney and others, to continue their success and support them.

And just come up with a more fair and equal way of balancing things.

Jobin Kuruvilla:

That also brings up the question… How many third-party integrations do they have at the moment? I mean, I know at least with Slack, when I last checked they had more than 2,000 integrations available right? And obviously, for companies like ours. You know, we rely on a lot of Slack apps. And we write a bunch ourselves, right, helping our customers using Slack.

How easy is it for Discord? Do we have any idea of how powerful their ecosystem is?

Rasmus Praestholm:

Yes.

I was curious myself. Hmm, how much is that really like marketplace-y, and ready to go out of Discord, I didn't think there was a lot, because it's not in your face.

You can go look for Discord bots, and I think it's at least in the tens of thousands of established bots. It may be more than that. Even one of the main sites says "explore millions of Discord bots and servers" – so like, they are big scale.

And I thought, Well, I mean they can all be on the marketplace or something like that. But then, when you go dig it like, oh, there's also like hundreds or thousands of integrations in the marketplace that you can like. Hmm, okay, that's pretty neat. So they have that kind of stealth.

It's actually there. You may not realise that because that's not how it grew up. But this incredible ecosystem exists, including full, fully monetised, third parties, and so on—just kind of hiding behind the scenes – or hiding backstage, as some might say.

Jobin Kuruvilla:

Very well – I think that's a viable option then, even for companies, is what you're saying.

Rasmus Praestholm:

It absolutely is. And it's neat and fun to build on, which I might also like – hint hint, wink wink – maybe Adaptavist is doing this, too. Hmm?

So, it's exciting. Slack is not exciting anymore.

Laura Larramore:

Yeah, in nearly every Discord channel that I'm in, someone in the Discord channel has made a bot specific to that channel, or something that's useful – I even attended a developer hackathon on the developer channel that was geared towards hey, let's make a bot to make our channel a little better.

So there's a lot out there, and there's a lot of customisation that you can do.

Jon Mort:

Yeah, I know. One of the things that Discord did explicitly is to try and enable creators to make money on this part. One of the things that they do, which I think is another, an exciting part of that.

One thing I will say about the bots though is that you don't necessarily know, like, who's making it? What happens with the data – all of those sorts of things which you know, Slack is much hotter on, and verifications and things that they do – and building out a corporate server on Discord might require you to have some awkward conversations with bot vendors, to go. You know, hey, what security certifications and things do you hold on those kinds of things? And within the Slack app directory, you get a better idea of those things – it's something also that Atlassian is pushing really hard on and trying to make that kind of trust visible – which might take us on to the next topic…

The software bill of materials, as being a you know, kind of a, a new one – that's not something new, but a really important part of shipping software.

Does someone want to jump in and explain the software bill of materials?

Rasmus Praestholm:

That's one that I am happy to let you do because this one I am vaguely familiar with it over time. I know it's been a thing and like Maven and Gradle and those kinds of bill systems over time. But it's always been one of those things. That's… yeah. I know it's there, on the periphery, somewhere. I know it's essential, but I don't really have time for it. So why is it important now?

Jobin Kuruvilla:

I think it's always been there, right? I mean, now, it is just getting traction because of all the security issues that have been happening all around the world. Especially, I mean, this is not a problem just for any particular vendor, but for anybody who is using software, this is actually a big thing. And obviously for the marketplace when there's like Atlassian, they need to pay attention to this.

And I was actually in the GitLab leadership partner summit the other day. You know, tools like GitLab is actually taking measures to make sure that SBOM is available and visible, and, you know, can be presented today to the customer, or it can even be looked at in their pipelines.

So.

Going we're going back to your original question about what an SBOM is. You know, it basically gives a lot of information about each of the components in a software supply chain. Right? I was actually looking at specifically, what are the things that you usually will find in the SBOM. You know, you'll have the component's name, the component supplier name, the version of the component, get any unique identity for that particular component which could be, you know software identification tags, uh the packages, uniform resource locators – all of those things.

And the components' dependency relationship to the software.

So all of that information together makes the software bill of materials, or what we call SBOM.

And again, you know, there should be an order for the SBOM, and there should be a timestamp for the SBOM creation.

The good thing about all of those is, you know, that gives you some kind of trust in the software that you're using. And in particular software, there could be multiple components, each with its own SBOM. And you could essentially track the dependencies. You can see what each company does, who created it, what is inside the component, and so on and so forth.

Rasmus Praestholm:

I kind of think of it as a continual evolution of, you know, dependency management.

Like you used to have, like, here are some JAR files. We'll just dump into the source tree and build it – good luck.

And then you got into more like the Gradles and the Mavens like. Oh, now we can build you a hierarchy of all your dependencies and so on. But it was still really just like, go find these JAR files and pull them down and stick it in the code.

Then we got into some of the, you know, providers like Sonatype, with Nexus IQ, and so on, like trying to tie the dependencies to oh, we know that their vulnerability is announced for these particular things over here.

And this might be kind of like the next level, which it gets… kind of a little "legalese” about it because it gets into the actual providers behind the library. And, as you say, like really nitty-gritty details like timestamps and probably signature keys or other things. So that you really stop beginning to realise that, yeah, you're depending on this giant tree of stuff and etcetera. There are people behind all this stuff.

It's like that famous graph of the, you know "what makes the internet run". It's this one guy that maintains a library thanklessly over in Oklahoma. That's like supporting 90% of the internet, whatever that poor guy is, we should probably get him some help.

Jobin Kuruvilla:

Yeah, I mean, it still scares me. Every time I used to run a Maven install, I download the whole of the internet right?! I mean you don't even really realise the number of packages it is downloading. Ha! And there was one of the conversations that I was listening to, and that was this interesting analogy about you know how it is like nutrition facts.

So basically, when you pick up something from the store, you look at the various content in it, and you see 95% of the daily value of sugar. Oh, I don't want this anymore, you know. Pick up something else which is, you know, less sugary.

So it kind of gives you confidence that the software or the component that you're using is actually good enough to be used.

So that is where the SBOM comes in. And I believe it also works really well with the zero-trust policy.

So GitLab's licence because now everybody is shifting left. So there is a lot of emphasis on security. And there's a zero-trust policy around it. So unless you know that the component is actually trustworthy, and you know it actually has an SBOM published, you exactly know what's in the package, you shouldn't be using it.

Jon Mort:

Yeah. And I think it's this, I mean the the time where it really, SBOM really kicks off and around the Log4j vulnerability of a couple of years back. That which you would, there were a lot of teams who were scrambling around or like, I don't know if we are affected by this vulnerability, you know? And that's really key, important question like, is this something that we're affected by, and you've got the…. So that's kind of what one side of things – is a really interesting new kind of AI vulnerability on a thing. So lots of AI coding assistants will hallucinate code and sometimes hallucinate libraries. And people have been squatting those libraries that the AIs hallucinate, which indeed starts to – you have this kind of like trusted system because it usually produces you decent code, or whatever, that's now suddenly producing you something which is harmful.

And so how we treat dependencies, and how we treat those kinds of things, I think is kind of becomes increasingly important as the complexity of the software and the complexity of the dependencies goes up.

And I, that kind of like, supply chain attack is something which is, you need to very quickly, be able to establish what components, from all the way from the front and all the way down to what he's you know what you you serve, where you're running on.

You need to understand that and understand who's responsible for each free section of it.

Rasmus Praestholm:

Yeah, there was a recent thing highlighted for Github where a new attack is possible where, if you rename, you know the path where your code lives on Github…

Github, friendly enough, makes a redirect to a new thing. If you have code that's pointing at the old link and just directly pulls code and maybe starts executing it.

Somebody can register the original name after a period of time. And now the redirect breaks. And now you're getting whatever the code is there. So there's a lot of these things out there. It is scary. And it's good that we're trying to address it. It's just still the question of how it's going to end up looking.

Jobin Kuruvilla:

Yeah, I still can't believe it – Jon called ChatGPT a trusted system!

But anyway, that's not the point. But the point is to have that radical transparency right with SBOMs in place. And you know it, tools like GitLab, I was mentioning earlier. They're doing a lot of things with SBOMs like for example they have new licence checks to reveal the SBOMs in the pipeline. So that is something you can have now in the pipelines when you're building your software – you can do these licence checks, and you can do checks around SBOMs. And they're publishing an SBOM of SBOMs – even at the different system levels.

So you don't have to go into the individual components to see the details of that particular component. Instead, you can have an SBOM of SBOMs!

So you have all those information and pull it together at a higher level. So it's easier to get visibility into what's underneath, which I found very interesting. And there was some other thing that was mentioned was they'll say there's merging and ingesting of SBOMs into the documentation. So it becomes easier to consume all of that information. It it's unlike looking at the nutrition facts of each and every product that you pick up from the shop. Instead, you have this higher visibility into SBOMs, which is all great stuff, in my opinion, because us tools like GitLab, or maybe other tools start doing this more often, you get this increased visibility into what's in there, in a software package. It makes life a little bit easier for developers, I hope.

Rasmus Praestholm:

Yeah. And I'm sort of there. There are two things that are higher in my mind in this, which is You know. What kind of tooling do you use for this? And what if anything is going to be costly about it?

Because this is happening now, like SBOMs have been mandated by the US government now for some types of work which is going to affect even clients of ours.

We have to tell them you got to start using this. Suppose you want to keep selling to the US government. That's a big deal.

But that kind of sudden push on enterprises, especially the ageing ones, that are not necessarily at the edge of, like, good tooling.

They're going to start tracking this in Excel spreadsheets. That's not great. That's not the way to do it.

And there will be tooling out there, for like – Maven and Gradle, for instance, did wonderful things, the dependency management, and like charting the graphs and so on, that you might not have in the old days with [inaudible] or something crazy.

And that's free. It's available. But then, when you get into Nexus IQ, it's like tracking vulnerabilities that affect. And of course, you have to pay.

And there's going to be neat tooling on SBOM coming out. How is that going to look at how well it's going to be adopted? And is it going to cost lots of money to where that poor guy is in Oklahoma, or Nebraska, or whatever, who’s maintaining this thankless, this little library that just keeps the internet online? Is he going to be able to use those tools?

That seems important.

Jobin Kuruvilla:

Yeah, it's a very good point you brought up about the government agencies, you know, increasingly recommending or requiring SBOM creation for all software vendors. You know, that's happening already, and I believe the forecast or the webinar I saw was GitLab partnering with one of the US government agents is, say, we're talking about exactly the same thing – and that is also the reason why GitLab is doing a lot of work on the SBOM side these days, I would imagine a lot of the other vendors will follow you, and you know, start

posing SBOM in the pipeline and the tolling whatever it is.

Rasmus Praestholm:

Yeah, I almost wonder if this is one of those areas because of just the criticality of the vulnerabilities and the exploits and all that in this area, where there should be a more push to have, you know, a higher foundation of service to catch these things.

I can understand that lots of companies need to make money, and there are a lot of optional things you can throw out there in areas that don't relate so much to security, like, yeah, you can get the super shiny, neat thing. But you got to pay for it. We're like, well, I mean, yeah, that'd be great. But it's a luxury we can live without.

But when it's security and supply chain attacks and all that kind of stuff, you want everybody to have that stuff because it affects you.

Jon Mort:

That is what the Open Source Technology Improvement Fund is looking at, trying to fund some of those open source projects and looking at security funding vulnerabilities, like, you know, patching. And there's a decent number of organisations who have pledged to support that.

I do worry a little bit about the maintenance aspect of these things.

You say you for kind of having, you know, a pull request forced upon you by someone you know in your open source maintainer – are you accepting it? Are you not? You know, there's all of that I mean things, because the whole maintenance costs and things.

But it seems like a step in the right direction.

Rasmus Praestholm:

I have seen this in person myself as I look at this. You know this fund like it's a great idea.

And then you get into the whole like, you know, lots of good things happening like posting bounties and all that kind of stuff, but I've seen the dark side of it because I've run an open source project that's more than a decade old.

So we have a lot of old code in there.

And one day, out of the blue, we had this amazingly detailed security report dropped in our GitHub. And it's like, Wow! This sounds really critical; nice find! But what is this? And what? You'll pay us money to fix it because it's security?

I'm going to need some information here.

And we talked it out. And it turned out that this was kind of like a startup, or some sort of thing where they were trying to do this kind of like good. You know, community involvement in things, but somehow they were probably trying to make money themselves or get a good position to get into that stuff – and the vulnerability they found?

It was to an HTML parsing library inside a UI widget inside a video game, meant to preview HTML documentation embedded within the video game…

And it was in a tech vector where, if you could connect to the website, you could gain control of it.

But it wasn't a website.

It was like, a widget inside a game that had nothing to do with the internet.

And ancient code that didn't matter. And this is… guys, you've kind of wasted our time here!

Jobin Kuruvilla:

But going back to the point that you're making Rasmus – I think there's already a standard available right now. So it's on developers too, you know, to define the SBOM for the components that they work on. I think SPDX, it's an open international standard developed under the Linux Foundation.

It already defines a form out for you know SBOM documents, and that can be consumed by humans, by machines, by tools. What were you talking about earlier? Right by GitLab? Whatever it is, I think there's already an existing standard. I think there is an increase in demand for publishing SBOMs. So that's gonna happen.

Rasmus Praestholm: Yep, yep, I would love to see it more.

I can definitely hear, you know, Jon's concern and validated there that more code review, more mysteries – like if somebody submits an SBOM thing for my open source things like… that's great. I think. Are you gonna help us maintain it?! Because we don't know what…

So yeah, it's always a question of balance.

Jobin Kuruvilla:

Yes, indeed.

Laura Larramore:

I think with the government push to make vendors supply that, that's gonna trickle down to the whole industry, and it's whether you want to be on the driving force of that or whether you want to be on the receiving force from the government because it's going to come down. More than likely!

Well, thanks for joining us to discuss third-party apps and this SBOM intrigue – and we hope that you're enjoying the show. And let us know what you think on social media @Adaptavist.

And we look forward to keeping this conversation going there.

So – for Jobin, Rasmus and Jon, I'm Laura, and this has been DevOps Decrypted – part of the Adaptavist Live Podcast Network.