Can you vouch for the quality of third-party code that’s incorporated into your applications and websites, and for the APIs that you use?

When it comes to open source, only the largest dev shops or corporations can afford the time, money and resources to examine the source code. Everyone else has to take it on faith and trust that the community has vetted the code. If you are integrating commercial closed-source components, or accessing RESTful APIs from outside your organization, faith (and maybe an SLA) is all you have that the code is not only functionally correct, but also reasonably bug-free and reasonably secure.

(Related: Why we need to reform how open-source software is made)

It would be nice to say that we can verify external components and APIs. Nice, but naive. For most of us, particularly small and medium-sized shops, that’s a pipe dream. We can’t verify, so we trust anyway.

The obvious example of that trust, of course, is the so-called Heartbleed bug that affected some versions of the OpenSSL encryption library. Companies large and small plugged OpenSSL into their websites and ended up being insecure due to a relatively minor coding error.

The service chain for business applications, mobile apps and websites is huge. Library after library, framework after framework. Big companies can write all of their own code (but often don’t). Smaller companies and organizations can’t even dream of writing all their own code. In some cases, they pick up commonly used code snippets or modules from “the community”; in others, they license commercialized versions of open-source code, with the assumption that the code has been thoroughly checked.

That’s trust.

Eric S. Raymond writes in “The Cathedral and the Bazaar” that, “Given a large-enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone.”

Sounds good in theory. In reality, not so much. Not everyone will look at every bit of code, and even when there are lots of reviews, bugs will slip through. Sometimes the bugs may be big showstoppers that crash; sometimes the bugs will be subtle and overlooked. The bug in OpenSSL is like that. OpenSSL worked correctly, but had a teeny tiny little argument-checking flaw that could be exploited. Oops. Should it have been caught? Of course. It wasn’t.

You can’t verify, but you have to trust. That’s reality, and most of us must accept that. One of the challenges, though, is keeping track of when flaws are caught and fixed. Many of us—dare I say most of us?—fail to keep up with all the third-party code in our apps and websites, and in particularly we may not be sure when patches and updates happen. Some source-code management tools offer that sort of functionality through automation, but most do not. Say you use OpenSSL. Would you have caught the April 7 security advisory linked above? If you were using OpenSSL 1.0.1f, would you know to upgrade to 1.0.1g? If you were using 1.0.2-beta1, would you have a plan for hanging on until 1.0.2-beta2 came out?

If you answered “yes” to any of those questions, can you be equally certain about all the open-source and commercial libraries, modules and code snippets in all of your software, and all the APIs that your apps utilize?

You can’t verify. But you have to trust. That’s scary.

If your websites use OpenSSL, how did you respond to the bug? Write me at alan@camdenassociates.com.

Alan Zeichick, founding editor of SD Times, is principal analyst of Camden Associates.