Adolfo García Veytia, Chainguard | OSS North America 2023

This is techstrong TV And welcome back to the Open Source Summit in Vancouver. We're here with Aldol Garcia from Chain Guard, and we're talking about, well, what else? Open source software insecurity, cuz it seems to be the dominant topic of the day.

Al Dfo, welcome the show. Thank you Sam. Mike, I'm thanks for having me.

We are talking about everything from salsa frameworks to people are signing code. It kind of feels like maybe we're making progress, but are we, and where are we on this journey? Yeah, I guess there's been progress, there's been a lot of progress.

Uh, I feel the most progress over the last year has been embracing this shift in mindset of people becoming aware that supply chain security is a big problem that need to be start to get, uh, to start understanding that they need to have a more visible chain when they're embracing and consuming software. And you see people all over the place starting to ask the right questions on the kinds of information, the metadata they should be, uh, consuming and generating where they release software. So it's, I think that it's a big one.

Um, ASBOs are now our main concern. People are starting to understand not only because they're compelled to require ES bombs, but also starting to question what's in the s they're receiving and consuming and producing. So I, I feel there's been progress.

I feel like people's hearts are always in the right place, but do we need to make it easier for them to do the right thing? Right, exactly. Yeah.

And, and it's difficult because a lot of the technologies that we are trying to, you know, push forward and develop to make the supply chain more secure are new. So there's a lot of tools that need to get ridden, uh, not only for the developers, but also for, uh, CISOs. Uh, and to that scale well for enterprise, um, level product.

So it's a lot of work that has to be done, but we're getting there Is part of the issue now that we're putting so much focus on this, that the bad guys are looking up going, Hey, what's that issue? Great, thanks. So this and that will force everybody of course to up their game because there's more bad guys.

So are we in some sort of yin and yang push and pull kind of thing, but it's just the nature of the beast. Yeah, it's a yin and yang, but eventually the industry has a lot of resources and so what, what you're trying to get is more alignment and true efforts like the open s s F and the communities around open source and around the standards. Once we get those incentives aligned, then the industry pushes together, uh, we're gonna see much more faster progress.

You guys are deeply involved with both the Linux Foundation and the Open Software Security Foundation. What are you guys working on? What are those projects and where do those two things kind of hook up?

Yeah, we as a company in c are involved in like everywhere around supply, uh, supply chain. Uh, so we are involved in projects. I'm personally involved in a lot in Nest bombs and working up upstream in Kubernetes and other open source projects.

And, uh, but Changa also has a lot of participation in bricks, like six store and salsa. And, uh, we have, uh, some of our folks are also on the governing ward of the open ssf from the tech, so everywhere. What exactly is the challenge with SBOs on the face of it?

It seems relatively simple. I've got a list of ingredients in my software. So where does this become harder than just what I said?

Um, well, I guess the challenge with SBOs is that there's SBOs are, uh, as you say, like a clear and rather uh, easy proposition for people who are involved in making software and, and, uh, into supply chain security. But companies found themselves mostly overnight being required, uh, and not on track to be to, to, to be required to demand SBOs and to produce SBOs when selling to the government and the tooling was not there. So that's the main challenge.

So people have been rushing sometimes faster than the development of the SBO m to produce the tools. So some tools are not compatible with each other. Um, the formats, it's not easy to work with them together and, uh, but I, I feel we are making progress to overcome the problem with the, with the formats as they, they're are working to become interoperable.

And also, uh, tuning is getting much better to, to either both produce, uh, SBOs and also handle them at scale. Do organizations that consume software have a plan of what to do with all these SBOs? I feel like everybody's requesting an SBO m but they don't really have something on the back end, the manage this process.

Yeah, and this takes me back to where I was talking about the change in mindset. So if you've talked, uh, if you were to, in any of the SBO meetings, I don't know, six months ago people were like, I need an smo, like procurement legal is asking me to request SMOs from, from suppliers. And they really didn't care what was in the documents and they didn't have a use case for them.

But now we are starting saying that companies are starting to, okay, I already have the documents, I might as well just do something with them. And they're starting to look into the, some of them are not very high quality. Some of them vary differently.

People just like to throw anything into those documents. So now that companies are starting to look into what they're getting, they're starting to demand better quality and things will improve. A lot of code is updated on a daily, weekly basis.

How do I update the spo? Uh, so a good software release should get, have an attached to it. And it's not only about the blm, but there's also other metadata related to the BLM that gets released on a different cadence than the blm.

So you release software and on on par with it, you start, you should be starting to think on releasing VAX and also additional s when things change. And, but any of release needs to start with a good, We hear a lot about ai, will AI get applied SBOs and what might that look like? Yeah, so currently, uh, s p spdx version three is about to, so we just releases spdx version three.

Um, it was announced just before the conference started and the first release candidate already has an AI profile. And the idea with the AI profile is that once, uh, the s not only needs to describe the software, the application, but also the model and the data sets that we're used to train it. So, um, uh, s SPDX has already an AI profile that captures all all of that information.

Who's in charge of A, the creation of the SBO M and then B, the consumption of the SBO m are these different people in different organizations and how does that structure kind of look to you? Yeah, ideally they should be different organizations. The, the SMO should be provided to the consumer by the supplier.

So if I'm a software project, I am a software vendor, I should be giving those ESMs to my consumer or client or customer, whatever. And on the consumer side, well it depends on what you're doing with the esm. ESMs may be consumed by, uh, risk analysis tools, by legal procurement people who want to understand licensing in their software.

So ESM has many uses. Uh, the, the biggest two that you'll uh, get across are licensing and security. Uh, we are mostly in security, but um, it depends on who's reading those documents.

Sometimes you hear from folks that they're a little wary of putting all their secret sauce into an SBO m cuz they're wary someone's gonna steal their software idea or component. Is that a legitimate concern and what do we do about that? Yeah, my guess is, um, when you think about applications, uh, most software is 90% open source.

So there is a, an ingredient of the secret sauce, but you don't, the only thing that you have to list in your software is your components and the, the in your secret sauce gets obstructed in a package that is really opaque and doesn't reveal anything. So, um, I guess there may, may maybe some corner cases, some people not wanting to reveal, uh, I don't know details about their product, but mostly it should be okay because it's soak and the other, the main concern, which may be a valid one, uh, but I mean transparency is key in all of this is when organizations don't want to necessarily reveal who their suppliers are. Uh, so that may be a, a concern, but I, I think in the end, the extra transparency brought by the monds will benefit the the whole industry.

We're seeing a lot more regulations coming down the pike. It seems like they're gonna get stricter as we go along. And now even there's more vertical industries that are applying these mandates.

So is it pretty much a fade of comp play that I'm gonna have to figure out how to make all this SBO stuff work? Yeah, exactly. And but I mean, when you put it like, that sounds scary, but in the end, what you want, what we want as an industry is that essences are completely transparent to, uh, software developers and also to anyone not interested in, in consuming them.

So tools should care about, care about desktop pumps and raise maybe a flag when you don't have one or have a valid quality one. But this information should be flowing automatically, machine readable without human intervention. So it it, it won't be a any obstacle in the further development.

Do you think we'll get to a point where organizations will have some sort of governance mechanism as software moves through their pipeline? They'll look at the sbam and they'll say, deploy or not deploy based on what they know about the vulnerabilities of a particular component? Yeah, I mean we, we have been in contact with, uh, customers and everything and companies already have those, those policies and people and the, the whole idea of the SM is act on the information that's contain it, either not deploying it, but also going to, uh, to, to to, to the point of notifying developers or even, or even like not letting things run inside of your organization.

If you detect that that component is vulnerable, Do you think that ultimately this will improve the hygiene of applications? Because today developers will continue to download a version of something that they know that works, but it's highly vulnerable or, you know, they'll get fooled by somebody doing some typo squatting and download something without even looking at it. So ultimately there's this circle back into just better hygiene.

Yeah, Absolutely. And so when you, now that we have a, like, well we don't have the, the proverbial S one everywhere that the open SF wants, but now that we are seeing them more widely available, you're starting to see how the, that information is already, uh, showing you the exposure that some of some software has to dependency, sometimes not even needed dependency. So we are trying like produce these super small images based on our os wolfie and those have like the bare minimum dependencies.

So you compare the M to that and just scan any random image out there and you have like 10 times more dependencies cuz people are just using general key images and the one, it's a really good pathway to understanding what you're consuming and so that you're pulling from the net. So what's your best advice to folks about how to get started? What have you seen some organizations do for best practices that kind of get 'em moving in the right direction?

Uh, for you mean? Yeah, so the, the first thing is start developing, start creating a ans one as part of your C I C D pipeline. Especially when you release, when you release, have some sort of generator that captures the software dependencies and have that, uh, document published as part of your release.

So along your binaries or along your images, be sure to get that one app, sign it. No, because signing is important so that people know it's coming from you and even if it's a low quality document, you'll be making great advance. And so put out that document, let people use it and get feedback and improve it as, as your consumers need it.

All right folks, you heard it here first. Just get started down the path and we'll become more apparent what you need to do as you go along. But the most important thing is just do something cuz doing nothing is gonna become unacceptable.

Real quick, thanks for being on the show, buddy. Thanks Mike. All Right, back to you guys.