Hi, I'm Ciara Carey and welcome to Cloudsmith's monthly webinar on all things cloud native, package management, and supply chain security. Cloudsmith is your cloud native, universal, artifact managing platform. So, attacks on, on your open source, in your software on the rise. They use vulnerabilities in open source like in order to get into your system.

So today we're going to be talking about frameworks to help software developers consume open source more securely. And so that framework is the secure, secure supply chain consumption framework, or S2C2F. It was created by Microsoft and it was donated to open SSF in order for everybody to benefit from it.

So it's a practical guide to incrementally improve the security. And how you consume open source. And so today we're really lucky to be joined by Adrian Diglio, who will talk us through this framework. So Adrian is a [00:01:00] principal PM manager at Microsoft, and he leads the secure software supply chain team to secure Microsoft's end to end software supply chain.

So I'm going to bring him in now. Hey, Adrian, thank you so much for joining us.

Absolutely. It's my pleasure to be here. Thanks for having

me. Yeah. So the first question I'm going to ask you is why did Microsoft feel the need to create this framework?

That, that's a great question. You know Microsoft loves open source and we use it extensively.

However, we were starting to see the trends ourselves about attacks on open source and in our developers, you know, accidentally pulling in these compromised packages. So we really wanted to secure ourselves against OSS supply chain threats. And we started on that, that journey in 2019. And we and then after the solar winds incident [00:02:00] happened uh, it was a little bit like hair on fire, you know, across the software industry and and everybody was looking for answers.

And we felt that we've been using this framework in practice to secure ourselves and that this was one piece to the overall supply chain puzzle. And we wanted. To enable other people to secure themselves the same way that we did.

Yeah. I remember I was a software engineer until recently. And I, I wanted to do the right thing, but maybe I didn't really know how to like when I was bringing in a new package, I was a little bit worried always, but I didn't know if I was following, um, the right method for bringing it in and really it wasn't my top priority, I just wanted to get my.

My thing to work, my thing to run, and it's great to have this framework to kind of help you know that you're consuming it securely. So, let's start off with some of the attacks that we're a bit worried about. Like I suppose [00:03:00] LeftPad was, was not really quite an attack, but it's something to worry about.

Yes so LeftPad happened back in 2016. And a upstream maintainer decided to pull their source code and their package. From the public package manager. And back then developers were pulling packages direct from the public package manager. So the fact that it wasn't there anymore, suddenly their build broke.

And the headline said, left pad pulls their source and breaks the internet. Yeah. So That's why using package repositories, such as Cloudsmith is, is advised in the S2C2F.

Yeah. So let's start with level one, cause I know a big a big focus on level one. I know there's four levels in this big focus on level one is to securely to, to make sure you're consuming.

Your open source [00:04:00] all sort of the same way. And so do you want to go into how you can do that?

Yeah. So so yeah, we, we organized the S2C2F in the maturity levels. Level one in my opinion, the, the way we structured it, level one is kind of like the bare minimum. It's, it's the, you know, you need to have some sort of.

Governance on your open source, you need to be scanning it for known vulnerabilities, inventorying it and ingesting them into a, a package repository and you know, from there, you know, that's kind of been the rule of thumb for a decade or so, but we can do better. And so the maturity levels kind of move us up and.

Improving how we securely consume open source. Yeah,

so I think it's like using artifact repository like hazardous and also make sure you're using package managers where you can. so You're, you're taking, you [00:05:00] know, you're, you're that helps versioning. It helps with repeatability, all these kind of things.

Exactly. And, and by consuming them into you know, in an artifact repository if you, if your development team or your entire organization enforces that that is the approved method to consume your open source. That is one of the strategies that we recommend it, you know inside the S2C2F guidebook, if you go check it out, there's eight practices, and those eight practices kind of make up the holistic strategy that you need to have.

To secure your OSS supply chain. And it all starts with ingest it. Developers are incredibly creative with all the different ways that they can consume open source. And so to control your supply chain, you need to control how it's consumed into [00:06:00] your development environments. Yeah.

And there's other benefits to that.

I mean, if you're, if you're using packages, that means there's less repeated code all over the place. So it also helps with. other aspects of software development. Yeah. So let's go into, so level one, you're ingesting all at the same way you're using an, an artifact repository. So you have some control over what package you're using.

You're also have an inventory in level one, which doesn't necessarily have to be a, an S BOM or a software bill of materials, but you have an inventory. And so let's move to, we have some scanning as well, right? You, you in level one.

Yeah, some sort of a software composition analysis tool, an SCA tool. There's a lot of them out there and those are usually tools that can help you achieve your inventory as well.

And they should, they should also scan for known vulnerabilities and license [00:07:00] issues et cetera.

Yeah.

So level two is it's a step up from there. There's more automation involved with the scanning. And I think that you will have to have some way to automatically resolve vulnerabilities.

Something like Dependabot is not like a big part of it.

Correct. Yes. So level two is all about let's improve the speed at which teams can, can update their open source. There were story, real world incidents where this one open source package confidentially disclosed their, their vulnerability correctly.

They, they said, here's the CVE and here's the patch. But as soon as that CVE was announced, adversaries were able to research the vulnerability. develop an exploit, start searching for systems in the wild that were using that vulnerable version, and actively start exploiting within three days. [00:08:00] Oh gosh. And organizations sometimes take much more time to, to update their open source, but we have tools that can help make this easier.

Tools like Dependabot. And additionally, if If you have tools like dependency review, which is another feature in, in GitHub it, it shows you vulnerable packages as a comment in a pull request. Brilliant. That way a pull request reviewer is empowered. They, they have this additional information and they can say, Hey, I, I'm not going to accept this pull request until you fix this vulnerable package.

And, and those sorts of things help. You know, prevent security debt from building up and reduce developer toil and all those sorts of things. Yeah, I think

even a really recent incident is the log4shell vulnerability and the popular log4j package. And I hear even after resolving this, people have gone through their systems, they're [00:09:00] happy, they're happy.

They're using the right package that somehow the old package gets pulled back in again. So it's, it's a terrible cycle so that you can use automation and sort of security checks in your CICD in order to prevent that reintroduction.

Absolutely. And that would be part of

level

two. Level two is all about.

Improving how we manage vulnerabilities with open source. Yeah.

And so level three is a step up again. It's more like about enforcing enforcing that you're not using vulnerable packages. And like, it would actually, presumably it would potentially break. build if you try to pull in a vulnerable package, that kind of thing.

Yeah. So, so level three is all about more than just vulnerabilities. These could be like compromised or malicious like typo squatted packages. So we started adding requirements about, [00:10:00] you know, your organization should. Should start scanning open source for malware which was kind of like a industry wide gap for a

while.

Yeah, actually that's one thing in Cloudsmith, every package that's uploaded is actually scanned for malware and we won't, it'll just, it won't accept it if it's if it's has a malware in it, so that's kind of a cool little feature.

That is fantastic. Yeah. So see, so, so there's, so S2C2F is all about like these requirements and there are certain platforms and technologies and tools that developer teams out there can adopt to help them achieve these, these requirements and have it all built in.

Yeah, and you can kind of feel like as you're going up the level, you're kind of building these nets and they're not all perfect, but it gets harder and harder and harder to get through to that to your software. I suppose that's what you're kind of trying to do.

Yes, exactly.

[00:11:00] And one one of the features of.

Level four, is this allowed denialist? Do you want to go into that a little bit?

Yeah. So, so I believe the denialist is in, is in level three. And you know, there's denialists are also a relatively new feature that's starting to pop up in various. iT's, it's not everywhere yet, but there's some development teams that, you know, for, for whatever reason, they might not want to use this.

Certain open source package and they want to make sure that no one accidentally pulls it in. And so like, just put it on the deny list. if, if you're in an organization where you have an incident response team that gets reports of new malware in open source, they should be able to just update the deny list and make sure.

You know, no, but as, as part of the response plan and to make sure that no one's accidentally consuming these compromised [00:12:00] packages. And so that's yeah.

Yeah. We first in case when we first introduced that idea of a denialist with log for gel, log for shell, where we like, you can deny it being introduced, but we're actually.

Introducing a feature that's like you can add any package to that. So that came from, sort of from log for shell, where we heard it more and more. And then some of our customers are really like, really want this allowed and loyalist, so that's a. It's going to happen pretty soon, so hopefully before Christmas and yeah, so it's really nice to see that we're aligning with this, with this framework, we're doing like the right things.

It's kind of, it's nice to see. That's

fantastic. Yeah. And I, I love how S2C2F is helping people realize that they need these sorts of capabilities.

Yeah, and another thing in level 3 is incident response. So, do you want to talk about what, what do you have to do with incident response? Is it just to have a [00:13:00] plan to see what you're trying to protect and where an attack is going to come from?

Yeah, so, so as soon as there is a known incident that, that some package got compromised Your company might be like, well, what software is using that package? That's where the inventory comes into play. You want to be able to search through your inventory and see who's using this version of this package.

And and so once you identify. Who is using a particular pack, bad package then you need to start contacting. So you got to update the deny list as part of your incident response plan to prevent further bleeding. And then you go and you contact those affected teams. And based on what the.

Compromised packages or, you know they all do different things, but one of the common things that they do is exfiltrate secrets [00:14:00] to a remote attacker controlled server, and so they might have to go start rotating all their you know, tokens and, and passwords and all, all those sorts of things as part of the.

The particular response to whatever type of attack it was.

Oh, actually you kind of brought up something that I was interested in is I didn't really see in S2CTF much on authentication. Do you advise multi factor authentication as part of any of the levels? Or is that like a kind of a separate sort of framework for security?

That's a very interesting question. So there are, so the S2CTF 2f is hyper focused on, on how developers consume language packages like, like NuGet, NPM, PyPy, Maven into the developer workflow and protecting developers and protecting your CICD system. So, so authentication can, [00:15:00] can be a You're right.

We didn't touch on that. You know, what are we authenticating to? Is it, is it the developer authenticating into their CICD environment or or is it, is it authenticating up to the public package manager if it's authenticating up to the public package manager? That's a, that's interesting. I guess we implicitly implicitly say that, that because the, each public package manager has their own um, they're in their own state of supporting.

Multi factor authentication. I,

I think. So you want something that is more covers more all those ecosystems. Yeah. Yes. Yeah. So for

the record, it is recommended and specifically a fish resistant form of multi factor authentication. I, I, I think like. If you're using [00:16:00] MFA that sends you like a text message those have been proven to be intercepted and an attacker could, so, so, so those, that's a less secure form of multi factor authentication.

Okay. Okay, cool. So let's go on to level four. So level four is would you advise this for All software repos or all software bills or are you, is it like the bills that are dealing with more important information or what, what you think?

Yeah, so level four is all about defending against the most sophisticated adversaries.

Okay. And as we've seen So we're talking about

like you know like kind of nearly a company that would like ransomware company or something like that, or, or an a state agent sort of thing.

Yes. Yes. So nation state actors where they, they are well funded, [00:17:00] it's their full time job. It's they are the most capable and sophisticated adversaries that are out there and they, uh, so, so when you think about incidents like SolarWinds I know SolarWinds wasn't OSS related, but the attacker had a presence on the build system.

And was able to silently introduce a back door while the software was being built. So think about all the open source you consume. How do we know that the build system wasn't compromised when that open source was being built? So level four, it's not advised for everyone. It's, it's largely a aspirational level.

And. It's only recommended when it's worth reducing the risk for like if you have some sort of a critical infrastructure or some sort of critical software for your business [00:18:00] that you're building, it might be worth the investment to go rebuild. The open source from source yourself.

And so that would entail cloning, forking that open source and maybe fixing something before the fixed was introduced to the upstream.

Yes. So in. And so this is how this all gets tied together. So in level three, we do advise that you might want to consider mirroring the, the, the source local to your, your company or your development team for business continuity and disaster recovery purposes. What if somebody did remove their open source and, and if that piece of open source was critical to your software?

Don't you want to be able to continue to maintain it? And the other benefit of mirroring the source [00:19:00] locally is that now you can start to do proactive security reviews. So this is also a level three item. Okay. And if you are looking for the yet to be discovered vulnerabilities, then you as a participant in the open source ecosystem can start contributing fixes back upstream and being a positive member of the open source community.

And and so there's, there's many benefits there. And then, and then lastly, in level four is what if you discover a zero day vulnerability and And you confidentially report it to the upstream maintainer, but you're not receiving the, the urgency that you have liked. If your organization is very risk averse and this particular vulnerability scares you, as a temporary measure, you could [00:20:00] do a private fix and, and, and use this privately fixed version in your company while you continue to work with the upstream maintainer to get it fixed for everybody.

Yeah,

and I'm presumably you, you really want to, yes, yeah, that's all right. I think I just spoke over there, but temporary is a really important part of that.

Yes. Yes. Because as soon as it's fixed upstream, you want to use the upstream package. Of course.

Now you mentioned, so we went through the four levels and you did mention solar winds, so I thought I would bring up another framework, salsa what's, what's the supply chain levels.

Assessment. Is it supply chain levels or something like that?

Yeah security levels for supply chain artifact. I'm, I'm miss, I'm messing it up myself. It's like,

oh wait, I have it here. Supply chain level. Or software artifacts. Okay, we got it. So this is another framework and I think it [00:21:00] works symbiotically with the S2C2F

framework.

Yes, they are, they are companion frameworks. So S2C2F and Salsa are both in the Open source security foundation, the open SSF S2C2F is entirely focused on consumption. Just how you securely consume open source. Salsa is all about production. How are you securing your, your source, your build, your release?

And so these are complementary frameworks that can be used together. And so to, to create or illustrate a scenario um, You kind of need both to have a holistic strategy to protect yourself in these days. And if a developer consumes a compromised open source package, that might be the way an adversary gets initial access into your environment.[00:22:00]

Once they have initial access into your environment, they are going to pivot. And try to escalate permissions to get towards their, their objective, whatever that may be, but their objective might be getting a presence on your build system, compromising your software that gets shipped out to all of your customers.

And so that's why you need S2C to protect you from that first phase of attack, and you'll need Salsa to protect you against. Somebody trying to compromise your build environment and it's, it's all about defense in depth and having layers of protection.

Brilliant. And I actually did hear that vulnerabilities have actually overtaken phishing as a conduit into an attack vector into systems.

So it's definitely on people's minds. So, is there anything you, thank you for going through all the levels [00:23:00] in such a quick time. That was just wonderful. Is there anything you'd want to leave

Yeah, so I, I would encourage our audience to, to go check out the S2C2F for themselves. It's on GitHub.

It's in the open SSF repo slash S2C2F. And You know when you get on the landing page, there will be a link where you can view it in Markdown or view it as a PDF. And you know, hopefully the guide helps you. We also have bi weekly meetings where we continue to talk about the S2C2F within the OpenSSF.

And, and anybody is welcome to join. And So, yeah, we'd love to hear from you and we'd love to hear your stories of trying to adopt it, or if you have questions, happy to help.

Oh, great. Thank you so much, Adrian, and I might pop into that meeting as well. I'll be quietly there in the background for, for

But thank you so much for today. I know people are going to love this, [00:24:00] so Yeah, thank you.

Bye bye.