Welcome to Cloudsmith's April Webinar, Salsa 1. 0. What does it mean for you? Welcome to I'm Allison Zickelka. I head up product at Cloudsmith. Cloudsmith is the only universal artifact management solution that lets you securely store and distribute your software artifacts to your team and to your customers anywhere in the world.

I'm excited to have two great guests here today to help us dig into Salsa. Salsa is a community backed framework designed to help organizations secure their software supply chain. We'll talk about what's in the specification and why, how Salsa relates to or differs from other standards. And what are some practical steps organizations could be taking now or should be taking now to help ensure the security of the software they ship to production.

Before we jump in and before I introduce our guests though, I have a few housekeeping notes. If you're watching us on Twitter or LinkedIn, repost this live stream for your chance to win a free lunch. We'll announce the winner of the free lunch at the end of the webinar here. We will also be giving away prizes for folks who are joining us on our webinar streaming platform.

Uh, so stick around until the end of the session and be sure to let us know you're here by dropping an emoji in the chat. And then lastly, Cloudsmith is excited to announce Unpacked. Unpacked is Cloudsmith's virtual conference for DevOps and engineering leaders taking place on June 20th. If you're interested in learning more about securing and scaling software delivery and hearing from folks who are tackling these problems and these challenges every day, be sure to visit unpackedconference.

com to register today. It's free, it's virtual, it's global, and we'd love to have you join us. So with that, I'd like to introduce our guests for today's session. First, we have Isaac Hepworth. He is a group product manager at Google focused on software supply chain integrity. Through this role, Isaac has supported Google's contributions to OpenSSF's SIGstore, Salsa, and Guac.

Isaac is also the chair of the OpenSSF Supply Chain Integrity Working Group. Isaac, thanks for joining today.

Thanks for having me here. Great to be here. Thanks, Allison. Good to meet

you all. Uh, we also have, also joining us is David A. Wheeler. David is the Director of Open Source Supply Chain Security at the Linux Foundation.

David is an expert on developer, developing secure software, and on open source software specifically. David, thanks for joining us today as well.

Thank you very much.

Uh, with that, let's jump into our topic, uh, Salsa 1. 0. So to get us started, I'd love to hear from each of you how you came to be involved with Salsa, uh, and contributing to its development.

Uh, Isaac, you want to jump in first?

Yeah, absolutely. Um, so I mean, I've, I've been working in the, in the industry for, for decades and, uh, you know, working on, on developer products. Um, you know, at Google, at Twitter, at Microsoft, at Stripe and so on. Um, and then, you know, a year or so ago, Uh joining google I had the opportunity to uh, you know to lean in with uh with open ssf Um, it was currently working on on seek store and salsa and a whole bunch of uh, super interesting software supply chain initiatives, um as a product person, um I'm, uh, I mean, I'm, I'm amazed and also slightly horrified at how much opportunity there is to, to improve the security in this space.

Um, and so, uh, you know, that that combination is incredibly compelling, uh, to me as a product person. Um, and so, you know, there, there is a lot that we can do better, um, as an industry. Um, the the macro dynamics here around, you know, that the rise in attacks and software supply chain security, you know, emerging regulation legislation around it, you know, a burgeoning sort of efforts in the open source community and the standards community.

Um, and it's really a, uh, a super exciting environment. Um, lots to do. I'm in a lot of value to add. Um, and I think frameworks like salsa, which, you know, span the industry horizontally can, can really. You know, lift all boats and, uh, and hopefully, uh, you know, make the overall, um, industry software supply chain more secure.

And that's a super exciting opportunity.

Yeah, that's great. And David, how about you? What's your interest in Salsa and getting involved in this space?

Well, I've been interested in open source software or developing secure software for, uh, decades, literally. Um, and, uh, I joined the Linux Foundation before, uh, the Open Source Security Foundation, OpenSSF, was even founded specifically to try to help, you know, you know, Linux Foundation, um, you know, just, you know, improve security overall.

Um, when the OpenSSF was formed, I immediately got involved because, uh, its goals are basically my goals. Um, and when, uh, Google came, uh, to OpenSSF, you know, joined, you know, Google was originally a founding member of the OpenSSF, and, um, when Google came and said, Hey, we've got this framework to try to address some of these concerns in the supply chain, you know, things like the, the bill processes and so on.

Of course, people saying this is, this is great. Um, the challenge that, uh, you know, Google of course has been doing a lot of these things for quite some time, and I imagine we're going to be getting into this. So the challenge was, how can we take all these good ideas that were Within Google space and bring it out and find out, okay, these parts are, are either very challenging to do outsides of Google space, or maybe there's other ways to do it.

And basically starting with an example from one organization into something that can be widely applied by many different organizations. This is, this is not a unique challenge, by the way, this is a challenge of standards in general. Usually the best ones are starting with. Something that someone's already doing successfully and then trying to look at how to generalize it.

And so from the beginning when Salsa came in, um, I, I became involved, um, you know, trying to help, uh, you know, the many, many organizations who've, uh, contributed, uh, to what has finally become, uh, uh, Salsa version 1. 0 release, which I'm sure we're going to be talking about.

Yeah, no, that's great. Um, great introduction from both of you on some of the background of Salsa 2.

Uh, I want to jump off from there a little bit. Isaac, you had mentioned that Salsa is trying to be horizontal across the industry. Uh, I'd love to understand, you know, for folks who've heard of Salsa, who are on this call, but maybe aren't really familiar with what's in the framework. Um, what are the main objectives of Salsa?

What, what are, what's Salsa trying to solve for organizations? And then how does, how do the tracks and the content of Salsa map into helping them solve those challenges?

Absolutely. Um, and there's, there's a, there's a many layered answer to that. And I think, you know, one of the, I mean, one of the areas which is perhaps the most vague, but at this stage of the maturity industry is super important is, you know, Salsa just as a center of gravity for beginning to standardize, you know, language and concepts around supply chain security, making sure that everyone's using the same nouns and verbs, understands them the same way.

Uh, you know, has the same conceptualization of, you know, what does the software development life cycle look like, you know, what are the relevant threats at various points in that life cycle, and so on. And Salsa does a great job of, you know, beginning to provide a lingua franca for the industry, um, and standardizing some of that terminology and vocabulary and enabling folks from across the ecosystem, from across the industry to work together effectively.

So I think, you know, from a non functional perspective, Salsa has done a terrific job of that. Um, I think functionally, Salsa Um, you know, one of the one of the observations I'd make is that, you know, modern software is component based by nature. Um, and, you know, it's, you know, assembly often often involves, you know, components from outside your own operational domain from, you know, some upstream supplier from outside of your organization.

Um, and, you know, folks who are making software or consuming software or using software. Are often in the position of not really being able to concretely understand Risks to their organization from artifacts that they're, you know relying on from upstream. Um and salsa is uh, you know Salsa is in part a way to do that a framework to better understand the the risk involved in um With a given artifact, you know, what, what's, uh, what's this artifacts provenance?

What can I tell about it from its inherent properties and from what properties can I derive from, you know, Practices that were used in its production and so from a for a consumer of software I think salsa begins to give some quantification to to risk and enables you to implement policy in your stlc around You know that the provenance of nature artifacts you're ingesting for software producers, you know who are producing these components and uh, you know Supplying them downstream supply chain.

Salsa is a great, very pragmatic set of best practices for supply chain security. Um, and so, you know, Salsa has this dual life where, you know, for people making components, it provides, you know, a very pragmatic, leveled, you know, transformation framework for making your, your own supply of components. uh, you know, incrementally more secure as you go on your software supply chain security journey.

Um, and then for consumers, you know, gives you additional data and metadata to reason about as you consume software components. Um, in terms of the tracks, I mean, I, I think, you know, you know, Salsa at the moment, you know, the Salsa 1. 0 specification had, you know, a lot of effort and a lot of it's, it's the, the weight and the gravity of Salsa is around.

You know, build and how is software built and what are the properties of a builder that is used? Is it hermetic and isolated? Is the environment as femoral? Um, you know, is the builder service based? To what extent can we trust the service that is building software? Because ultimately Software which runs in production you you might normally you might even consider the build system which built that software part of the the production basis You know, you should consider your build systems part of production operations, too Um and salsa has a focus on build um, you know as its first track and i'd like, you know, I think I should emphasize that You know, Salsa is a vision within the open SSF spreads much more broadly across a whole number of supply chain concerns, including build and provenance and source and dependencies and vulnerability management.

We don't have all these, all these pillars covered today. Um, but certainly there's an ambition to, you know, have the open SSF provide frameworks and solutions spanning all of these concerns.

Yeah, that's great.

Um, so I can go ahead. Yeah, I can try to add to that. I mean, one way to view this is, Salsa is all about a pragmatic approach to, for projects to counter, uh, supply chain attacks.

And, and if I can, uh, riff a little bit on what, what Isaac said, um, some, some history, it might be helpful here. You know, if you go back several decades, a lot of software development, you know, applications, you developed almost everything yourself. Uh, that's not really how normal software development works today.

Uh, the numbers that I have is on average, anywhere from 78 percent to 90 percent of a typical application. Once you open up the hood is open source software components. That's not including any proprietary libraries that they also use. That's not including an operating system. Often it's not including databases.

I mean, in general, just like the hardware world, you know, I mean, people generally don't... Design their own screws when they're building a larger system. Similarly, we don't try to rebuild everything from scratch today. That's good. It's a good thing. But the side effect is that means that when we develop software, we're depending on others, including how it's built and so on.

I mentioned, um, Isaac already mentioned these, uh, various, uh, tracks, uh, when the, uh, Salsa first, um, was, you know, its first draft was released, um, it included a lot of capabilities, and the discussion was, you know what, we really need to focus on a On a specific track, really nail that down exactly what that is.

Let's get move, you know, let's really refine that so everybody can understand it. Let's call that version one. Then, now that when I was released, there's going to be ongoing work to refine other areas to continuously improve. Uh, but nevertheless, the overall goal is very much to counter supply chain attacks because we are now far more dependent on suppliers than we used to be.

Yeah, that's great. And that's definitely something we talk a lot about with our customers where they're sourcing the artifacts and getting those third party dependencies. And how do you know that you can trust them? So is it safe to say that we can expect to see additional tracks be built out within Salsa in the future?

Yes, I actually let me just jump in, but I'm sure I mean that the the version one of 0. 1 actually had more. And the challenge we had was, Oh, wait a minute. You know, when you try to do everything all at once, it takes many a very long time. Uh, typically, that's not a good way to proceed. It's much better to try to work incrementally.

Um, At the very least, I'm expecting there to be a source track, where there'll be more analysis about source related things. Uh, the version 1. 0 that's released has levels, build levels 1 through 3. We are, I, I do expect there to eventually be a 4. Um, The original four that was defined in the version 0. 1 included some capabilities.

Uh, there were things like hermetic builds, discussion about reproducible builds, and a survey that we did basically found that, wow, people are finding these very challenging to do. Um, And therefore, let's focus on the parts where there's much more agreement, unanimity, and then we will work, we will continue to work to improve on these other areas.

Isaac, please, uh, please add to what I've

just said. Yeah, no, I think that that's absolutely right. And I've got a couple of things to add. I think yes on, on hermeticity. Like I think, you know, we, we had an early concept of what a hermetic build meant and would get you. And I think that there's There's more nuance than you expect within that concept, you know, people talk about hermetic builders Hey, your build system really doesn't have access to network at all.

And certainly that's one end of the spectrum um The other the other poorer end of the spectrum is where your build system can do whatever and pull things down live from the internet As it goes, um, but somewhere in the middle there's you know The concept of hermetic to your organization, or perhaps a white listed network access, or perhaps intermediated network access, or perhaps you can access, you know, my internal artifact repositories and so on.

And so I think we introduced, we need to introduce more nuance into the hermeticity requirement and As you say, that'll come in Build Level 4. Um, I think the other thing, you know, backing up and thinking about, you know, for folks who are new to supply chain security, I found it very useful to, you know, articulate and conceptualize, you know, in terms of, uh, you know, food and food safety and the food supply chain.

And so, you know, people who are familiar with SBOMs, you know, I make this analogy of SBOM, it's like the ingredients label. You pick your can of beans off the grocery shelf store and it has ingredients labels on it. Um, you know, and the S bond will tell you this bread is made from flour and water and yeast and sugar and salt and so on.

The salsa provenance for your bread will tell you where those ingredients came from. It'll tell you how they were mixed. It'll tell you the uh, the brand of mixer that was used and it will tell you all the food safety handling procedures that were followed as well. And so they give you that that additional level of security and so people you know People have this, this question often, often between the ambiguity of what's in an S bomb, what, how do I think about salsa provenance?

And I find disambiguating this way in terms of, yes, an S bomb is an ingredients list. Salsa tells you how the thing was made, what machinery was used, what best practices were used in terms of the way the food was handled and so on in its production. Um, and so I found that a useful way to explain provenance versus S bombs.

Yeah, I think that's great. I think that's a great analogy. Um, and, and building on that a little bit, you know, the Salsa versus SBOM, I'd be curious, you know, I think the term, uh, the term framework is used a lot around Salsa. So how do you think about Salsa compared to some other standards that are helping folks in the software supply chain like NIST and other standards that are out there today?

So I think, uh, I mean, it's, it's a good, it's a good question. And, um, on the Salsa blog, there's actually a blog post comparing, you know, the, the Salsa framework to the NIST SSDF, the secure software development framework. And I think that are certainly some interesting comparisons to be made there. One of the high level ones I would make is that.

You know ssdf is is very broad. I think it is a you know, a very rational and sane framework And I think that it's it's super useful and it's it's something which google has been paying very close attention to um, but it's it's There are a couple of aspects that it's missing when when you look at adoption of it The first of all is um, you know, it's not a leveled framework.

There's no there's no transformation ladder or there's no kind of hey What's SSDF level zero? And then how do you get from that to level one? And how do you, wherever you are on the ladder, how do you reach the next run? Um, and Salsa's leveled structure, um, ergonomic, uh, you know, approachable, um, feeling that wherever you are in your practices today, you can map onto where you are in the Salsa levels and you can easily climb the ladder.

That's the first observation I make about NIST, SSDF and Salsa. Um, the second one is that, you know, SSDF. You know, it's a, it's a descriptive framework, and so it describes, I mean, it certainly provides examples to illustrate, you know, um, the, you know, how would this, uh, descriptive practice be implemented in the real world.

SSDF on the, uh, sorry, it's also on the other hand, it's rather prescriptive, it's rather specific and tells you specifically, here are things you need to do, this is what your build system needs to look like, here's how you capture, you know, the parameters that go into your build, here's how you have to think about an ephemeral environment.

So it's, it's very specific and that, that makes it. from an implementer's perspective, uh, much more comprehensible, uh, to, to get started with. You can immediately look at it and there are specific almost checklists of instructions that you can follow in order to reach a particular Salsa level. Um, I think that, you know, NIST SSDF, um, certainly super important for the industry.

It's very, very broad in scope. You know, it's got sections about preparing the organization and how do you do role based training for people building software? Salsa is much more narrow and targeted in scope to supply chain concerns specifically and Salsa 1. 0 to build within that set of concerns. David, anything to add?

Yeah. Um, I, I, I agree with what you said there. And of course, when you open up Broad 2G, all specifications and standards related to these areas, it's a very, very long list. Um, but, um, I, I think one other thing that's, uh, important to note that, uh, and a challenge, you know, um, many of these other specifications and, you know, documents and materials, I'm sure.

What , what word to use here, you know, uh, NIST 853, 800 dash 53, and, you know, the SSDF and so on, for examples. Um, many of them make assumptions that are rather difficult to translate into the open source software, uh, world. Um, a lot of them make assumptions about, you know, we're going to impose, uh, requirements on your organization.

What organization? You know, in a vast number of open source software projects, there's one person. Uh, there's one maintainer. There might be two. Uh, they don't work for the same company necessarily, in many cases, if they're, you know, and so, you know, the, um, many of these documents make assumptions That translate poorly out in the world if you're not a government contractor, for example, um, now that doesn't mean they can't be applied.

And certainly there are cases where they can be, and that's wonderful, but it makes it a challenge to translate. This, um, you know, more generally number of these documents kind of assume a waterfall model approach, you know, write all the requirements, you know, create a document taller than I am. Then we'll start writing some designs and we're all done.

We'll start writing some code. Uh, that's not the way most software is developed today. So, you know, um, that doesn't mean there aren't requirements and there aren't designs. There are, uh. But the assumptions about how they present themselves don't always map to the way some of these specifications assume that they exist, um, that they might exist, say if you were a contractor.

So the, the goal is for, for something like SALSA is to make it applicable to a vast number of circumstances, which may not be the same as the circumstances, say a large government might, uh, might assume exist. I think

that's that's a really good general point, actually, and, you know, as someone who has, you know, one foot in Google's first party supply chain work and one foot in Google's open source contributions around supply chain security, it's, uh, it's super apparent to me that, you know, the problems in supply chain security.

You know, generally, you're very similar in the open source domain and Google's first party domain, and even in solutions that Google builds for its customers in GCP. The problems are all very similar, and you can squint and they look the same. But the fact that we're delivering solutions in these three different delivery domains, one being open source, one being Google first party, and one being to Google customers.

And each of these domains has different value structure, different incentives, different economics, different scale of actors, and, you know, things, techniques which may work to increase security in a corporate environment, like an executive top down mandate, you will now, you know, use this compliance framework.

You can't apply that in open source. The incentives are different. How open source software is developed is very, very different, you know, organic, much more bottoms up affair. And so it's, uh, there's this interesting variation that even as the problems look similar between, you know, enterprise first party software supply chain security and an open source and the dynamics of each environment is sufficiently different that you need to reason about them differently.

And they require different approaches.

Yeah, certainly if I make you. Yeah, go ahead. If I may quickly. Yeah, sorry. Uh, um, I and I think this all stems from a an intentional effort within Salsa Open SSF in general to engage a lot of different organizations. You know, there are open source software projects with literally thousands of.

Of contributors, you know, very large bodies of maintainers all the way to single down to single person projects. And the only way to develop specifications that really can be applicable in all those different circumstances is by developing that specification publicly, working with many, many different organizations to try to develop something that is both specific enough to be applicable.

And yet. Also is can actually be applied by these various organizations.

Yeah, I think that's great. I want to just call out Isaac mentioned the Salsa blog in there. And so for folks who are on the webinar platform, I think we can post a link to the Salsa website for those who are streaming. The Salsa specification and blog can be found at slsa.

dev, salsa. dev, so definitely check that out, um, to get familiar with the contents of the Salsa, uh, framework, but also explore the blog and some other material that's available there. I want to shift gears a little bit, um, and start to talk about, practically, how organizations are Implementing best practices or thinking about securing the software supply chain.

Um, David, the Linux Foundation recently put out a survey or conducted a survey. Um, this also plus plus survey, which I think we can also share a link to, um, to understand practically what our organization's doing to secure their software supply chain today. I'd love to hear a little bit about some of the discoveries from that survey and what surprised you out of that or what you if it was what you expected.

Absolutely. Yep. So, and this comes back to my earlier comment of don't just write a spec, dump it over the wall and hope that it was okay. Uh, we, we, um, so while Salsa version 1. 0, 0. 1, sorry, 0. 1 was out and before 1. 0 was, you know, Completed released. We did a survey to, you know, get feedback on things related to that based on that 0.

1. Um, and, uh, we got some really interesting, uh, results. Um, I'll do a quick summary, but I'll, I'll point to the blog post, which went to the actual survey itself. One is that a number of the practices are also are already widely adopted. That doesn't mean they're universal. And you know, when you make, whenever you make a list of please do A, B and C, each of those may be widely applied, but that doesn't mean people, many are doing all of them, if that makes any sense.

Nevertheless, the fact that so many were widely applied gives, I think a lot of credence to the idea that yes, for many organizations, they'll have to make some changes to reach these higher build levels. Higher levels of salsas. Well, the build levels of here in particular, but, um, they're completely doable.

Um, the ones that were all of them were considered helpful, uh, two in particular were considered to be substantially more difficult, specifically hermetic. Builds are reproducible builds. Those of you who will look at the version one Oh, we'll notice that, Oh, those aren't in version one Oh, and that's because it's, as Isaac mentioned, once we started getting into, well, what exactly do you mean and what is required and how do you do that?

Lots of complications, lots of more difficulties. So we're not ignoring that. We're just saying, let's, let's first agree on what we can. Set that down, and then for follow on work, we will work on focusing on those areas. Um, and, and, you know, all that is, is informed by, you know, what, what makes sense more broadly, industry wide, what seems to be harder.

We will work on those, but not delay everything else until we've resolved those parts. Um, and so, we, I posted, uh, a, uh, the, the, uh, You know, the blog post where we summarize that and the actual report itself is posted as well. Well, it's interesting is that though, you know, you know, all of them, even though there's some of them were far more difficult, that didn't mean that people weren't doing them.

Um, people were absolutely doing even the harder ones. So there is an appetite. There's an acknowledgement by many. That this is important and that they need to do something and salsa gives them a a common tool For here's what we need to do and we can talk about Are you doing these things or not? And isaac, please mention whatever I forgot to mention

No, I actually I mean the one that you last mentioned there in terms of uh, you know It stood out to me as one of the top level takeaways, um, was, you know, that there wasn't a strong correlation between, you know, the level of difficulty of a particular practice and the level of adoption of that practice.

Um, and I think, you know, the, the, the, the summary, the survey summary summaries that, you know, The evidence that where there's a will, there's a way. Um, um, and I thought that was a super interesting takeaway, but I definitely encourage people to look at the survey. I thought it was a particularly well designed and well conceived, um, as a survey, um, and really interesting to see, you know, what is, uh, you know, what is the state of the industry around adoption, knowledge of, and perception of the various practices.

Yeah,

that's great. Um, so just sticking with the practical applications, a lot of what is in salsa came out of Google and practices at Google. Isaac, could you speak a little bit to, I guess, the journey that Google went through to start to secure their supply chain and how you decided where you're going to start?

And how that led to the Salsa framework. Yeah,

absolutely. So, um, so, uh, hopefully I get this more or less right. Um, so it was about about 10 years ago. Um, you know, Google began, you know, a serious concerted investment and it's, you know, internal supply chain integrity. Um, and, you know, that that resulted in a framework, which, you know, externally we've talked about.

And if you want to search for it, there are a few Google blog posts about a thing called binary authorization for Borg. Um, and Borg is our, you know, uh, site. Horizontal computing substrate. Um, and so binary authorization for Borg that that began with this idea that wouldn't it be great if for a given binary running in production, you could strongly link and auditably so you could strongly link that binary to a given.

Commit in the source code and so you could say, you know, provably so cryptographically provably So this binary that's running in production came from this set of sources over here Um, and that's where binary authorization for borg began and then over the course of a decade, you know, we we had You know, more and more, um, you know, software supply chain concerns became a part of that framework, including things like enforcing two party review of every commit, including, uh, you know, even questions around, you know, once a binary is running in production, given, uh, you know, what we know about a binary and how it was produced and the security practices that were used, what data can that access live?

And so admission control is certainly one part of policy and people talk about maybe shifting that left upstream and supply chain. You can also think about shifting admission control rights to, you know, what even once something is running in production, what types of things can it do? What identities can it assume?

And what data can it access? So binary authorization for Borg internally at Google has has this long history. And as David said, you know, a few years ago, there was this idea of, you know, how could we Distill and externalize this framework to enable the industry at large to benefit from this, you know, set of, uh, you know, fairly at this point, mature practices inside of Google.

And, and that was the genesis of salsa. And salsa was donated to the open SSF in that form as essentially a, a distillation and an externalization. of Google's internal binary authorization for Borg. Um, and it, it means, you know, the idea of, of provenance. Um, you know, we, you know, we've long had this, this same idea internally at Google.

Um, some of the, the requirements in the source track of Salsa came from, you know, similar requirements, which, um, you know, were built and implemented at Google over time. Um, at this stage, as David points out, I mean, I think that Part of the, the joy of, of working with Sware Sware is by this point, you know, a a, a set of contributions from commu, from the open source community and from, uh, companies, you know, across the globe.

You know, we've had, you know, IBM and Red Hat and VMware and Microsoft and Chain Guard. Um. All involved in helping to shape and build the salsa specification promoting it help, you know Helping ensure it meets their needs both for internal use and also open source and so salsa at this stage You know is very much.

It's a it's an open framework. It's owned by the open ssf It's a community driven, um set of practices. It's a community driven standard The tooling is all open source. Um, and that's a super exciting space to be in. Um, and so there's certainly I don't want to give the impression that, you know, Seltzer is a Google initiative.

Um, but at this stage, it's an initiative from the industry at large represented in a set of artifacts delivered and owned by the OpenSSF.

Yeah, I think that's great. I think I appreciate that clarification on Google's relationship to Salsa. I think it is interesting, though, that a lot of what's in Salsa came out of the actual practices that Google was trying to implement internally.

So reflecting their own software supply chain journey. Um, I'd be curious, either from experience at Google or looking at other organizations that you've helped with Salsa or who've adopted Salsa. What are some of the challenges organizations face when they want to start to secure their software supply chain on that getting started?

What are some of the challenges to even, even starting to address some of the concerns?

So it's, um, it's a great question. I think, you know, the standard answer I give there is, I think, Step zero for people getting started on their supply chain integrity or supply chain security journey is understanding your dependencies.

I think it's the biggest gap that most organizations have. I was doing a panel at a cloud native security con a couple of months ago and I asked the room, You put your hands up if you know what your open source dependencies are and not a single hand went up And I said, okay We'll put your hand up if you think you ought to know what your open source dependencies are and 80 hands went up And I think that that gap there Um is the key key chasm to cross when you're getting started with supply chain security Um, if you don't even if you don't know what your dependencies are You're going to really struggle, uh, to understand and quantify, manage, systematically reduce the risk introduced by those dependencies.

Um, and I think this is actually something super interesting from the executive order in the U. S., you know, pushing S bombs in the industry. And SBOM is essentially, you know, a list of what component dependencies you have. And so, you know, if you think about the policy goal of the executive order, the policy goal isn't, we want these, you know, JSON documents everywhere.

The policy goal is, we want everyone to kind of up their game when it comes to supply chain security. And SBOM is a forcing function. For organizations to begin to understand and map out and eventually the dependencies, I think, is rather ingenious that, hey, it would be very difficult to produce S bombs without doing some basic groundwork and implementing some basic, um, supply chain discipline and hygiene.

And I think that that's, that's where, you know, the executive order is, uh, is super powerful, um, for the industry at large in the U. S. at least. Um, helping organizations get started there, but certainly knowing what your dependencies are. I think it's step zero for most organizations in my experience. David, what do you think?

I've lost the question a little bit, if you wouldn't mind repeating it. Yeah,

um, what's the, what's the biggest challenge? Or if somebody is, is wants to get started on their software supply chain journey of understanding and securing the software supply chain, how should they get started or how should they think about?

Jumping in and starting that journey?

Well, I mean, to be honest, I think the biggest challenge is taking the first step. Uh, you know, no journey. You know, you know, all, all journeys take time. But to be honest, it's that first step. You know, the first, uh, the, uh, the first step out of, out of, uh, out, out of the shire as it were, uh, to, to move in an area that you, you're, you're not very familiar with, but you know, you need to go do that.

Um. I will say that the good news is that we've had a lot of folks who have Helped lay that ground groundwork helped create that path. Um, I know that for example, you know at cncf Uh, you know looked at uh argo and prometheus and several other folks against the earlier version of salsa You know and feeding back the hey your your spec isn't very clear here.

It should be clarified like this Do you really mean that do you really you know? And and so um Uh, once you start, the good news is, I mean, the reason for a, you know, announcing, hey, it's at version 1. 0 is that people have already, uh, taken efforts to take, uh, what was attempted to be clear before and, uh, prod on it, uh, focus on it to, uh, help make sure that it is clear and that there is information to help people actually accomplish that.

I hinted earlier, you know, in my experience, the best specifications aren't just somebody sat down and dreamed something that might work, but specifications from Actual experience trying to do something. Uh, yes, you do have to have an idea, but so much is learned from trying to do it once. And, um, and so this reflects at this point, not only Google's experience, but the experience of other people looking at that draft, you know, saying, yeah, yes, but you could do it this other way.

Or, you know, well, that's probably not what you meant. I know what you said. So, um. So in many cases, I think that helped, um, because it's leveled, the upper levels tend to be harder. What a surprise. Um, but that's okay. Uh, the advantage of leveled systems is you don't have to, you, you can start with the first level and then move, move on.

Yeah, that's great. Um, Isaac, you mentioned in there. about managing risk and being able to make improvements around your risk profile. How should somebody think about measuring the benefits of implementing something like Salsar? How do you think about the return on the investment of starting to implement some of these best practices?

Gosh, I mean, that's another great question. And I think, you know, organizations starting this journey tend to have You know, one or two broad sets of concerns. Uh, one is inside a risk. Like what is my risk when it comes to my own software dollars, my own staff and, you know, an individual employee's ability to compromise my supply chain from the inside, I think that there's, you know, there's, there's ROI you can gain.

From from there, you're thinking about, you know, to what extent can you protect your own, um, you know, production systems from rogue employees and insiders and with malicious intent. The other broad class of concerns that organizations come to the table with in supply chain is about my upstream dependencies in the supply chain.

Um, and you know, I think, you know, there are, you know, there are, there are various measures and we're beginning to get quantitative in the space. I mean, so open SSF has another project called scorecard. Um, and scorecard is essentially. You know, it's a numerical score, um, and, you know, there is, you know, data available for, you know, the top million or so open source packages out there.

I'm giving you a sense of what are this, uh, you know, what are the, uh, what's the overall security posture of this project? Uh, you know, does it pin branches? Uh, you know, does it have two party review? Um, you know, does it pin its dependencies? Um, you know, and there's a set of practices that Scorecards assesses objectively and essentially gives you a score.

Um, and like, like any aggregate score, you know, there's, uh, you know, that, uh, it can't be precise in every dimension at once. But it certainly gives you a sense and gives you a way to quantify upstream risk from the get go. Um, and certainly internally at Google, as we're advancing our own internal capabilities here, we're looking at You know, what are our upstream dependencies?

What intelligence and data can we gather about them? How do we aggregate that data sensibly? Um, and then produce, you know, essentially, um, risk signals, um, for input into policy, into overall risk systems, into governance, and even developer assistance as well. Like, you know, one idea, you know, there are some implementations out there already, but the idea that an individual developer in their IDE Could establish a new dependency, you know, with open source upstream and, you know, get assistance or, you know, additional information right there in the IDE about, you know, what, what risk did you just add to your project from an overall, you know, dependency, health perspective, dependency, security perspective, dependency, integrity perspective.

Um, but you're shifting left that, that risk assessment. So you're not coming to deploy something to production and suddenly finding out, you know, gosh, it's too risky, but. really making it an ingestion time at development time at the time when you first established that dependency in the first place, really understanding what, what risk you're ingesting into your supply chain at that point.

Yeah, I think that's really great. That's something we hear a lot from our customers too, is just how can I help developers make better choices right from the start on what they're including in the software supply chain. Um, so we're close to time. Uh, just two last questions. Uh, David, if somebody wants. If somebody started using Salsa and they have feedback, how should they provide that back to the team working on Salsa?

Well, there's multiple answers to that question. But I mean, basically, please get involved or report back to the Salsa community. That could be as simple as filing an issue on GitHub. But we also have alternate weekly meetings via Zoom. Feel free to reach out via email and slack. Uh, but The short answer is please get in touch in any way that is most convenient to you Uh, we have a 1.

0. Uh, it's a pretty it's in great shape Uh, but we intend to continue to expand improve it Uh add more information as we uh, refine it. So, uh, we always love to hear feedback

great uh, and then final question just for organizations who Are interested in software supply chain, but are new to the space. Do you have any recommendations on resources, a blog, a person to follow on Twitter?

Who do you think would be good or what do you think would be a good recommendation for someone who's interested in starting to learn more about securing their software supply chain?

Well, I'm gonna be, I, I'm gonna jump in right there because, uh, I, I think the open SF is a great place to go. So that would be, uh, open ssf.org.

Uh, org. Um, you know, so, uh, the Open Source Security Foundation, I mean, it's, it's part of the Lennox Foundation and it is specifically, it's specifically exists to, uh, improve the security of the, uh, open source software that we. We all depend on it. I mean, individual or persons and individual organizations.

Absolutely. If you have a particular project you want to work with, please go do so and go improve. But, uh, in many, many cases, it makes sense for folks to work together to work on these broader issues. And so the, uh, the open SSF is very much a forum for that. Uh, we've got blog posts. If you want to find out what's going on, we've got, uh, courses on how to develop secure software Uh, we mentioned scorecards and the best practices badge projects for, you know, helping projects figure out what kinds of things you should be doing.

I hear about this salsa thing, which, you know, it's finally come to fruition. And it's, it's wonderful to see. And so, um, I don't believe that there's going to be one thing, one silver bullet that counters all, you know, software security, software supply chain issues. We're not going to go back to the world of rewriting all our software from scratch.

That's a, that's a terrible system. It doesn't scale to the problems we've got, to the challenges we have. Um, but you know, we do think that there's a lot of things that can be done, uh, that really make things a lot better. And we would encourage anybody who's interested to please, please come join. Yeah, that's

great.

Isaac, any closing thoughts or anything to add? I'm gonna

just 100 percent echo what David said. Also took the Urban SSF book, uh, encourage folks to get involved. It's an incredibly welcoming community. Um, there's groups looking at supply chain, at best practices, at tooling, at dependency management, at vulnerability disclosure, any topic you can think of in there.

You know, supply chain and general open source security world. And there are groups in the offices of working on it. Um, and there is a large focus on open source. Um, there are a lot of individuals who show up from large enterprises across the world as well. And so, um, you know, I think it's yes, it's a great point to dive in and orient yourself within the space.

Um, but there's lots of threads to pull on both in terms of blog posts and individuals and Twitter accounts, um, you know, to learn more and dive into certain topics.

Okay. Well. Thank you both for taking time to chat through Salsa 1. 0 with me and congratulations on the release of the 1. 0 framework. That's exciting.

Thank you so much. I hope folks have enjoyed this conversation. I know I really have. I have a few housekeeping items before we wrap up. First, I want to announce the winners. So for folks who have won our prize pack, that's Andreas Fellner, Michael Dawson. Cody Wehunt and Christopher Durand, and then Alan Anderson won the free lunch.

Thanks for reposting our stream on LinkedIn. I also want to mention that Cloudsmith will be at the Open Source Summit in Vancouver in two weeks. Um, David and Isaac, I don't know if either of you will be there. I'll be there. Okay, perfect. We will all be at, uh, in Vancouver. So hopefully, um, if you are there as well, you can stop by and say hi.

Um, Isaac or David, are either of you giving talks or are you just attending?

I am giving a talk, and in fact I'm also on multiple program committees, so if you see me rushing from one place to another because I'm supposed to be in three places at once, uh, please be, please be sympathetic, but I would love a chance to talk to folks there.

That's great. Um, and then last thing, just a reminder that Cloudsmith is having our virtual conference, our first ever virtual conference for DevOps and engineering leaders coming up June 20th. The conference is virtual, global, and free, so if you're interested in learning how to securely ship. Uh, securely ship your software, uh, visit unpackedconference.

com. Thank you again, Isaac and David, so much for joining me today. If you're interested in learning more about the Salsa framework and how it might help you secure the software you're shipping to production, visit salsa. dev. Thanks, everyone. Thanks so much, Allison.

Thanks, David.

Thank you so

much.