The Tidelift approach to securing open source dependencies

transcript

For most organizations building applications, the majority of the source of their applications is actually open source. If you kind of dig in a little bit, there's this core infrastructure, that's probably about 10% of what you need; things like the kernel or sort of the underlying operating system. These days, most of that's provided by and supported by your cloud vendor. You then have a much larger chunk, that's about 70% of your application, that is open source libraries. These are things for anything like parsing JSON, talking to any of the APIs you may use. They're third party developed, and provided as open source, usually by independent developers. And then 20% is the application logic, the business logic that your organization has written.

One of the things that's increasingly a problem is that security vulnerabilities are being found by researchers or random individuals. They will report problems, but then no one will fix them. So with Tidelift, what we're really trying to do is work with the maintainers of the software to fix the problems as they're found. For example, we actually had a vulnerability reported in a package that is lifted on the Tidelift platform a few weeks ago. We actually responded to the researcher and found the problem and then worked with the maintainers to get a fix availabl, at the same time that the information was released publicly. This way Tidelift users could be on top of getting the update as soon as possible.

So there are a few different classes of open source security exploits. There are ones that make a lot of the news and the press which are things where a piece of software has gone unmaintained or under maintained for a while and someone will take it over and introduce a vulnerablility. We saw that pretty recently with event-stream. There are other cases which are much more common, and they're just bugs, simple cases that, you know, a developer didn't catch because no developer is perfect. That's honestly the much broader set. That's the much more common security problem that we see. The impact of those to application developers is, okay, I have a lot of these very small things. And actually understanding if they really impact me is pretty difficult. And so it's actually really important to stay on top of the updates, just so I don't have to think about is this one where it matters to me.

In a perfect world, maintainers of all software, open source libraries or any software, want to fix security vulnerabilities as quickly as possible. We care a lot about the software we're writing and ensuring that it's good for our users, but a lot of times there also competing priorities. Do I fix this security vulnerability? Or do I finish building out this fun feature that I've been working on? And those priorities come down to how much time do I have to spend on the piece of software, which in many cases is somewhat limited. At Tidelift, we're paying the maintainers to fix the issues that are critical to the business users of their software, helping them to prioritize fixing things such as security vulnerabilities.