Tidelift CEO and co-founder Donald Fischer recently sat down with Techstrong TV’s Michael Vizard to discuss how to secure the software supply chain, especially the open source components many organizations rely on. The two touch on the “what now?” following SBOM-creation, supply chain liability, and how to make sense of the ongoing government regulation. You can watch the video in full by following this link—or read on for some highlights:
Mike: Whose job is it [to apply the recommended industry and government standards]? Because the consumers of the software assume that the maintainers of the projects have done something about security, and the maintainers of the software are saying that this is their weekend hobby and if you’re going to use it in a production environment, security is not my problem. Who needs to step up here?
Donald: This is a central question for the regulatory paradigms being designed and discussed right now. We’re waiting any day now for the publication of the U.S. national cybersecurity strategy—while it hasn’t been published publicly yet, there’s a lot of chatter around it. The biggest point being discussed is that it’s shifting the responsibility from the consumers of technology to the producers of technology; shifting the liability to the entities that didn’t take the necessary precautions to secure their software. And to stop relying on market-based solutions to police this and instead focus on explicit regulatory requirements. The question is, who is liable when things go wrong? In other critical infrastructures, like pharmaceuticals, it’s very clear that the producer, or the vendor, is liable. In cybersecurity issues it’s been a lot less clear.
Mike: What about the enterprise that builds an application using open source components, what’s their liability? From their perspective, they might not be using that software to sell something, they might just be using it to build and run some function.
Donald: We’ll have to see the actual text of the policy and the implementation of that policy over the coming months, or years. How can organizations get their arms around the cybersecurity posture of the software that they are assembling? So much of software application development today is assembly as opposed to authoring new code. Most of application development, the packages and libraries that folks rely on when building applications, comes from an individual who is doing it sometimes for economic reasons, but often for impact, to contribute their skills and know-how to the world. As you start to think of the supplier liability part of this conversation, what are the implications for open source creators? Are they going to take on liability?
Mike: You reward maintainers for doing the right security thing, how has that been going?
Donald: We’ve partnered with maintainers to ensure that their software meets these objective standards that are being asked for by private sector industry and national governments. The way that we approach this is that we go to these open source maintainers and we ask them to align their software development practices to some of these objective standards—two examples would be: the Open Source Security Foundation (OpenSSF) and their proposed OpenSSF Scorecard, and from the U.S. government National Institute of Standards and Technology (NIST) and their Secure Software Development Framework (SSDF). We take standards like those and we go to open source maintainers and say that we know it’s kind of boring and tedious to check every one of these boxes and to follow every last one of these security development standards, but it’s really important to the organizations that have come to rely on your components—so we’ll compensate you to work with us on behalf of the organizations that are consuming your software to help your software meet these cybersecurity standards and to attest to us that these standards are being met.
And what Tidelift does with the organizations that we work with on the demand side of the equation is we give them a SaaS solution to apply this human, not machine, generated knowledge of which components do or do not meet these standards. Basically we’re trying to align the interest between these organizations that rely on this independently-authored and created open source code with the folks that created that code, trying to get the rest of the job done that the downstream users require for their own self-defense, and also to be able to fulfill these mandatory requirements that have emerged.
Mike: A lot of organizations might be their own worst enemies. People download something and they fork it, or they download something from a secure repository one day but then the next the other development team is downloading from something less secure. How do we bring some adult supervision to the process without getting in everyone’s way?
Donald: Frequently when we’re working with our customers, they’ve established a centralized DevSecOps pipeline and they've brought together best-in-breed tools. And this is where Tidelift comes in with the ability to add to that pipeline a formal check asking what are the standards that the third party open source components going into your application meet, and provide both the guidance and, if the organizations wants to, enforcement of those standards. Centralizing that activity and having a really robust DevSecOps pipeline that the organization as a whole adopts, that allows a way to enforce these policies that now need to be enforced.
Mike: We’re generating all these Software Bill of Materials (SBOMs) to help people see what’s going inside all of these packages. Are we really prepared to operationalize all of that? Because a lot of folks I’ve talked to are like, yeah it’s great that we’re going to have all these SBOMs but I have no idea how to manage them.
Donald: It’s a multistage journey—starting with that good idea and having that yield the intended security benefits. Step one of that is being able to robustly create a comprehensive ingredients list for what you’re building, which is actually tricky if you haven’t designed that process since the beginning because so many third party open source components in particular flow into your application because they’re a dependency-of-a-dependency of a package you're using, you may never actively make a decision to take on any of those. There’s tooling and work to be done to ensure that you can even have a comprehensive list of components.
The big question is now that you have this ingredients list, what do you do with it? Your ingredients list is of no use if you don’t have a list of allergens that you’re looking to filter out, or if you don’t have any kind of assurance as to the process that’s being applied to keep those ingredients in good health and quality before it gets incorporated. Where is the database of facts that you can look up about those software ingredients that are flowing into your applications? Most of those facts can only be known by the actual creators of those software. 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 have to partner with the open source creators behind it, find a way to align interests, and find the mechanisms to get the information out of their heads into a format that can be used by organizations that are trying to do something with their SBOMs.
Mike: What is your best advice to the folks that are trying to manage all of this chaos?
Donald: There are a bunch of different regulations coming out this year, in the U.S. in particular there are a lot of deadlines coming up throughout 2023 for providing SBOMs, making attestations about the software you’re providing including third party components. It’s gotten so complicated that we’ve put together an information resource center to help break down how this all came to pass starting with SolarWinds and Log4Shell, the White House Cybersecurity Executive Order 14028, the SSDF standards created by NIST, and most recently the guidance from the Office of Management and Budget (OMB) that will require organizations to start enforcing these NIST standards in 2023.
For a summary of these regulations and a timeline breakdown, stop by our government open source cybersecurity resource center. You can also learn more about Tidelift and how we pay maintainers to validate and keep to industry and government standards.
50 Milk St, 16th Floor, Boston, MA 02109
.svg){kind=icon}