Dependencies in open source

books

The topic of securing your open source dependencies just seems to keep getting bigger and bigger. I always expect it to get less attention for some reason, and every year I’m wrong about what’s happening out there. I remember when I first started talking about this topic, nobody really cared about it. It’s getting a lot more traction these days, especially as we see stories about open source dependencies being wildly out of date and some even being malicious backdoors.

So what does it really mean to have dependencies? Ignoring the topic of open source for a minute, we should clarify what a dependency is. If you develop software today, there’s no way you build everything yourself. Even if you’re writing something in a low level language there are other libraries you rely on to do certain things for you. Just printing “hello world” calls into another library to actually print the text on the screen. Nobody builds at this level outside of a few select low level projects. Because of this we use code and applications that someone else wrote. If your business is about selling something online, writing your own web server would be a massive cost. It’s far cheaper to find a web server someone else wrote. The web server would be a dependency. If the web server is open source (which is probably is), we would call that an open source dependency.

Now that we grasp the idea of a dependency, what makes an open source dependency different? Fundamentally there is no difference. The differences revolve around availability and perception. Open source is very available. Anyone can find it and use it without almost no barrier to entry. If you have a library or application you have to purchase from another company the availability is a very different story. It’s going to take some time and effort to find that dependency. Open source doesn’t need this level of time and effort.

If you visit github.com to download code to include in your project, or you visit stack overflow for help, or if you find snippits using a search engine, you understand the simplicity of finding and using open source code. This is without question one of the reasons open source won. If you have a deadline of next month are you going to use the library you can find and use right now, or spend three weeks trying to find and buy a library from another company? Even if it’s not as good, having something right now is a massive advantage.

The perception aspect of open source is sort of a unique beast. I still see some people who wonder if this open source thing will catch on. I secretly feel bad for those people (not very bad though). There are also some who think open source is a huge free buffet of solutions they can take whatever they want and never look at it again. Neither of these attitudes are healthy. I’m going to ignore the group that wonders if open source is a real thing. If you found this blog you’re almost certainly not one of those people. What needs to be understood is that open source isn’t free. You can’t just take things then use them without consequence, all software, including open source has to be cared for during its life. It’s free like a puppy in that regard.

Obviously this is a security focused blog. If you’re using any software you have to worry about security updates in your software. Security bugs are found in all software. It’s up to us to decide how and when to fix them. If you include dependencies in whatever you’re doing (and you are certainly including them) ignoring security issues is going to end badly someday. Probably not right away, but I’ve never seen that story end well.

Something that’s not often understood about all this open source, is open source usually depends on other open source. It’s turtles all the way down! It’s very common for any bit of code to depend on something else. Think about this in the context of a complicated machine like your car. Your car has parts, lots of parts. Most of those parts are built from multiple parts, which have parts. Eventually we get to parts that are mostly bolts and pieces of metal. Software works like this to a degree. Complex pieces of software are built with less complex pieces of software.

This post is meant to be the first part in what I suspect will be a very long series talking about how open source dependencies are, how they work, and what you need to do about it. It’s not terribly difficult to understand all this, but it’s not very obvious either.