How to secure your open source supply chain

Commentary: Open source has never been more popular, which means it’s time to figure out how to effectively secure the open source you use. Two experts weigh in.

Image: Getty Images/iStockphoto

The world is made of software, and upwards of 99% of any software you use–open source or proprietary–includes open source components. Some of those components come with a vendor standing behind them, willing to indemnify you in case something goes wrong. For other components, you might be able to get a subscription through a company like Tidelift to ensure steady maintenance.

But then something like the Heartbleed bug rips a hole open in OpenSSL, and you’re left wondering, “How could I have prevented this?” The short, but hopeful answer is: You can’t. Not really. Not completely. As Chef and System Initiative co-founder Adam Jacob stressed in a recent Open Source in Business interview, the real question is “how quickly can you react to the disruption in your supply chain?” not how to preempt such disruptions.

SEE: SQL injection attacks: A cheat sheet for business pros (free PDF) (TechRepublic)

Open source security: It’s always about process

Open source has historically delivered fewer defects–or “bugs”–than proprietary software. This makes intuitive sense: Developers who will be showing their code are more likely to invest the necessary time to prepare it for public consumption. To take fewer shortcuts. To polish.

However, the real secret to open source security isn’t bug-free code, which is impossible. No, open source security comes through disclosure. Because anyone can see the code, all can also see any problems. Or, even if not spotted before a vulnerability is breached, the open nature of the code makes it easier to fix the problem. Small wonder, then, that research firm WhiteSource found that 85% of open-source vulnerabilities are disclosed and have a fix already available when disclosed.

So when determining which open source components to use, Jacob said, focus on the process for fixing problems that inevitably arise with your “supply chain”:

The question is, how quickly can you react to the disruption in your supply chain? Because that’s actually what managing supply chains is more about. Yes, there is a proactive part that [includes] vetting whether to take on a dependency or not. But when something goes wrong in the supply chain, it becomes a matter of “How quickly can we turn around the fix? How quickly can we repair what’s broken and get it out to the world?” And that’s really where you need to focus. It’s not that you don’t focus on prevention. Of course, you do. But you can’t prevent it because the supply chain is so big and you’re not. And that’s the nature of the universe.

Pay attention to the upstream contributions to open source projects

If you’re a vendor selling services or support around these open source components, Jacob went on, ultimately what you’re promising is “that I’m the one who will react to it and I’ll react faster than you [the customer] to get a fix in your hands.”

This is why (in the same interview) Scott McCarty, a Red Hat product manager, stressed the importance of upstream contributions to open source projects. (An “upstream contribution” simply means the contributions back to the main source of the code.) Upstream contributions aren’t something to brag about, said McCarty. No, they’re merely a way “to express to the customer that you have enough involvement in the supply chain” to be able to care for them when problems invariably arise.

SEE: Why the best open source companies welcome upstream competition (TechRepublic)

This isn’t “support,” per se, though sometimes it can feel that way. Rather, the product is the ability to influence an open source project in a way to get fixes delivered quickly, which is easier if the vendor has upstream contributors. Such contributions are inherently self-interested, McCarty pointed out, but not in some “bad” way. No, it’s that self-interest that motivates more contributions, which helps the vendor to better care for customers, who repay the favor with revenue, which drives more contributions. It’s a virtuous open source security cycle.

Disclosure: I work for AWS, but the views expressed herein are my own.