Software Supply Chain Security – Donald Fischer, Tidelift

This is Textron TV. Hey guys. Thanks for the throw.

We're here with Donald Fischer. Who's the CEO for tide lift? And we're talking about how to secure that software supply chain.

That's full of all those open source component style. Welcome to the show. Thanks my glad to be here.

I think when you guys first started talking about this everybody kind of just not at their head and said, yeah, that sounds like something we might be concerned about someday and then lo and behold we had a bunch of attacks and people started freaking out and even the president got involved. So, you know looking back on it right now. Do you think that we're taking it seriously enough at this point or we still talking about it more than we're doing something about it?

Yeah, that's a that's a credible observation there Mike that you know, some of this could have been foreseen and certainly there have been folks in the industry trying to get ahead of the software supply chain and specifically open source software supply chain challenges that clearly we would face and now we are facing them and we've seen episodes like, you know solar winds two years ago log for Shell about a year ago that are really gotten folks attention on you know, folks in any organization that's building or relying on software and I do think to your point that folks are starting to take it more. Seriously. Certainly we see organizations prioritizing software supply chain security is one of their Cybersecurity priorities or in many cases their overall priorities in their businesses today in the private sector and there's also been a lot of you know, really good positive energy and specific steps being taken by national governments as well to use apply some regulatory pressure here as well to level up industry.

Certainly we've seen some of that in in the US and we've seen some of that in in Europe and in other jurisdictions as well. So I do think it's starting to, you know, get the attention and being taken seriously to the extent that it needs to be from as a practical matter. Whose job is this because the consumers of the software kind of assume that the main Changers of the projects have done something about security and the people who create the software say, hey, this is my weekend hobby.

If you know, you're gonna use it in a production environment security is not my problem. So who needs to step up here? Yeah.

Great question. So, you know this is this is a central question for some of the you know, regulatory paradigms that are being designed and discussed right now, right? So, you know where we sit right now.

We're awaiting any day. Now the publication of the US national cybersecurity strategy that is mandated by, you know, a recent US law that established the office of the national cyber director Etc. It called for a specific articulation of the national cybersecurity strategy in the US and there's the policy has not been or the strategy document has not been published publicly yet.

But there's been a lot of chatter about what's in there. There's been some reporting on it and one of the Central new changes that is being discussed in this document is Shifting that responsibility from consumers of technology to producers of Technology, right? Know I've seen this set for example in an interview last week in newburger.

Who's the deputy National Security advisor for cybersecurity. She said voluntary efforts have been insufficient against the threat to critical services that Americans rely on right? So some of this stuff is becoming mandatory, you know, I saw another saw other coverage of this describe this as shifting liability onto those entities that fail to take reasonable precautions to secure their software and basically stopping stop relying on market-based solutions to police this and enforce cybersecurity in products and services and start using you know, explicit regulatory requirements.

A lot of that comes down to who is liable when something goes wrong and in other domains like Pharmaceuticals or critical infrastructure and other areas, it's very clear that the producer the vendor is liable in technology cybersecurity issues. It's been a lot less clear. It's basically the liab.

Been borne by the by the user. So I think we're going to see a shift there. Certainly the conversation is changing right now.

So a lot of those folks are vendors that have built something that incorporates open source software and you would expect them to take some responsibility for this but what about the Enterprise that just kind of Builds an application using open source components what's their liability? Because from their perspective they may not be using that software to sell something. They're just using it to build and run some function.

yeah, well, we'll have to see what the you know the actual text of the of the policy and then all of the implementation of that policy is over the coming months and probably Years it'll take to for this to unfold but you know certainly at the heart of what you're asking is a very straightforward matter is you know, how can organizations get their arms around the cybersecurity posture of the software that they are assembling, you know think about it today so much of software application development is assembly as opposed to just authoring net new code when you're assembling software that's been written by other folks whether they're other organizations that have created software, you know really set as open source packages that you're downloading and incorporating or really when you look at most of application development the the packages and the libraries that folks rely on when building applications most of that doesn't From a company comes from an individual who's doing that in an open source Community. They're doing it for sometimes economic reasons, but often for impact to contribute their skills and know how to the world and certainly as you start to think about the supplier liability part of this conversation, you know, it's one place to apply that that question is at the organization that bundles these components. How can they even attest to the standards that that makes that meets or not?

If they did an author that code then another really interesting question is like what implications are there for open source creators that are just building something putting it out there in a sense. They are becoming you know supplier to all of these organizations where they already are are they going to take on liability and there's been some you know, kind of potentially scary implications of some of the discussions that have been happening around software liability in these new cybersecurity policy regimes you guys re maintainers for doing the right security thing. How's that going?

And because a lot of folks are kind of they're unclear as to exactly how much responsibility they want to take out. Yeah, so, you know at tide lift my company our contribution to this effort is you know, we basically started with the idea. How can we work with those independent creators Behind These open source packages that everybody relies on and we now work with a network of human creators.

These are like Indie maintainers. They're folks who open source maintainership is typically not part of their day job. It's a you know something that they're doing on the side, we have partnered with them to ensure that their software help us assure that their software meets these objective standards that are being asked for by private sector industry and by national governments, right?

So the way that we approach this is we go to these open source maintainers and we ask them to align their software development practices to some of these objective standards to examples would be one from Private Industry the open sour Security Foundation sort of a Consortium of private companies has proposed a What's called the open ssf scorecard? It's a bunch of practices that you want any software creator to follow around, you know security development of their software a second example is from the US government is the nist National Institute of Standards and technology has published What's called the secure software development framework ssdf pretty long document detailing all of the practices that secure development practices that should be applied when building software at tidelift. We take standards like those we go to open source maintainers we say, hey, we know it's kind of boring and tedious to you know, check all of these boxes and to follow every last one of these secure development standards, but it's really important to the organizations that rely on your components that have come to rely on these components that you started developing putting out there.

So we will compensate you will pay you money. To work with us on behalf of the organizations that are consuming your software to cause your software to meet these standards cybersecurity standards and to attest to us in a you know, kind of High Fidelity way that these standards are being met and then what type of does for the organizations that we work with on the demand side of the equation folks that are building with these open source components is we give them a software as a service solution that allows them to apply this human generated knowledge about what standards open source project do or do not meet to their consumption of those packages and they can basically configure a policy based on this data coming from the human maintainers of the open source projects to say, you know in this application area. We have to be really really, you know, lock down we're gonna apply really really stringent standards.

Every package isn't going to be need to be verified to meet every one of these Secure development processes in other situations. It might not matter as much right. It might be an internal use case where it doesn't need to be as Ultra lockdown.

There's less of a you know lower concept less consequences if there's a, you know, a vulnerability in the code in that case, they can allow you know packages that haven't been entirely verified so Put it put it succinctly. We're trying to basically align the interest between these organizations that rely on this independently authored and created open source code with the folks who have been creating that code try to get the rest of the job done that the downstream users require for their own, you know, just kind of self-defense, you know, sensible protection and also to be able to fulfill some of these mandatory requirements that have emerged A lot of organizations might be their own worst enemies and how do I kind of bring some structure to these things? Because what happens is people download something and they Fork it or they download something from way secure repository one day, but then the next day that other development team is downloading the same code from something that's less secure and we don't know what's in there.

How do we bring some adult supervision in to this process without getting in everybody's way. Yeah. Well, I mean, I think the way that we see that that happening in most organizations mature organizations.

These days is by centralizing the software assembly and release and authorship process with a defined pipeline of tools and policies being applied rather than having every development team, you know, just working ad hoc using, you know random set of tools using random inputs as well. So frequently when we're working with organizations who are tireless customers, they've established a centralized SecOps pipeline. They've put brought together best and breed tools.

Sometimes they'll take a fully assembled devops pipeline from a vendor that supplies multiple parts and they'll be looking to have things all the way from, you know, I get source code collaboration environment a, you know, continuous integration testing package. Or and this is where a tide lift comes in with the ability to add to that pipeline a formal check about what are the standards that the third party open source components flowing into your application meet and basically provide that both guidance and also, you know, if the organization wants to enforcement of those standards and then of course, you know the kind of the secure packaging build release and and the rest of the pipeline to get that into production. So I think that centralizing that activity and having a really really robust SecOps pipeline that the organization as a whole adopts that allows the a way to enforce these policies that now need to be enforced just as a slight, you know, kind of embellishment on the open source third party open source element of that.

Typically the way that we see organizations thinking about this and implementing this is Rather than having every individual developer in the organization responsible for applying policy around in each individual open source package, which becomes an intractable problem. It's you know, many organizations tens of thousands of developers tens of thousands of packages. It's kind of chaos what we see organizations successfully doing is doing that analysis centrally as well as part of this SecOps pipeline establishing a growing catalog of Open Source components that have been validated to meet certain standards and then just allowing or developers within the organization to draw from that vetted catalog of packages that meet the organizations requirements.

That way you take this, you know, pretty substantial load off of individual developers who are just trying to build an application to solve a business purpose arm them with a library essentially of vetted open source packages that somebody else already Upstream of them validated will meet their organizations requirements. Speaking of cognitive load we're supposed to be having people sign code and then we're going to generate all these s-bombs that will let people see what's going on inside these packages are we really prepared to operationalize all that? Because a lot of folks I talked to really like well, it's great that we're gonna have all these s bombs, but I have no idea how to manage.

Yeah, I mean, you know the the whole conversation around these software bills and material or s-bombs which you know, I think the more human way to say that is ingredients list or applications, you know, it's it's a multi-stage journey basically, you know starting with that good idea and having that yield the intended Security benefits, right? So step one of that is just being able to you know, robustly create a comprehensive ingredients list for what you're building. It's actually kind of tricky if you haven't designed that into your process from the from from the beginning because so many open source third party open source components in particular just kind of flow into your application because they're a dependency of a dependency of a package that you're using you may never actively take a decision to incorporate those they kind of get pulled in, you know, the jargon is transitively there.

So there's tooling and you know, Work to be done to make sure that you you can even have a comprehensive list of components. Then there's you know some tooling and you know formats for for containing that that are you know, I think starting to settle down now then the big question is, okay. Now that you have the ingredients list, what do you do with it right by analogy to the food world, you know, you're ingredients list is no of no use if you don't have a list of allergens that you're looking for to you know filter out or if you don't have any kind of assurance as to the you know, Process that's being applied to keep those ingredients, you know in good health and quality when it gets before it gets Incorporated.

So, you know, where is the database of facts that you can look up about those software ingredients that are flowing into your applications? That's where I think there's this really interesting question about The most of those facts can only be known by the actual creators of the software and in the case of third-party open source software, which is now most of the code that goes into commercial applications of all kinds we gotta we got to go partner with the open source creators behind it find a way to align the interest there and also find a specific, you know technology mechanism to get that information out of their heads into a format that can be used by organizations to who are trying to do something with their software builds the material. Nice, what's your best advice to the folks who are trying to manage all this chaos?

Because it seems like their heads could easily explode. Yeah, there's a lot going on here. And there's a there's a bunch of different regulations that are actually binding this year starting in the in the US.

There's a number of deadlines coming up in throughout 2023 for providing software bills and material making attestations about the Software that you're providing including third-party components that are going into that meeting these cybersecurity standards. We actually it's gotten so complicated. com.

We kind of break down how this all came to pass starting with the solarwinds and log for Shell the White House cybersecurity Executive Order in 2021. Then the follow-on standards developed by National Institute of Standards and technology and most recently the guidance from The Office of Management and budget OMB requiring organizations to start enforcing these secure software development standards during calendar year 2023. com and check out our government standards Resource Center linked right on the top of the page.

All right, folks. Well, the good news is you're not the only one struggling with this so there's places to go and people to talk to Donald. Thanks being on the show.

Mike love doing it. Thanks for having me. All right back to you guys in the studio.