This week, we’re shining a light on one of the biggest and hottest topics in the industry – open source software (OSS). Turns out, just a little bit of best practice sloppiness in the coding pool could be opening up your software firm to a world of hurt.

Software vendor Flexera recently came out with a report, called Open Source Risk – Fact or Fiction?, which delves into the realities of open source risk. According to the report’s findings, over half of any given software product is open source, and while OSS allows companies to be nimble in their development, the risks and security implications are grossly overlooked and not adequately dealt with.

Flexera surveyed more than 400 commercial software suppliers and in-house software development teams within enterprises about their open source policies, or lack thereof. And while at this point we should probably stop being surprised when we uncover widespread negligence in cybersecurity best practices, we kinda thought OSS-security would be higher on programmers’ priority lists. 

We were wrong. Turns out that nearly two-thirds of you ISVs either don’t have an open source acquisition or usage policy, or if you do, your developers don’t know it exists. And it gets worse: 39 percent of developers have no idea who is actually in charge of open source compliance at their shop–if there’s anyone at all.

C’mon, guys. You ISVs are the shining example we’re supposed to be holding up to the rest of the channel, the cutting-edge innovators and defenders of the code that runs our digital world. Tsk tsk.

If an individual or organization relies on open source in any way, they need to know what they’re using (and you need to know what you’re recommending) so that you can patch it quickly when an attack (such as the security bug Heartbleed) occurs. 

“Most software engineers don’t track open source use, and most software executives don’t realize there’s a gap and a security/compliance risk,” said Jeff Luszcz, Vice President of Product Management at Flexera. 

Oh, we’re not done calling you out. In an age of constant bombardment of hacks that leverage vulnerabilities in software and IoT services, you’d think at least all those bazillions of sensors and devices that are supposed to be powering a secure and connected future would be safeguarded. But it turns out IoT service providers are just awful at managing open source security and licensing. The report lays bare that these companies have done a rather terrible job at keeping pace with open source’s rapid adoption, and it’s putting them and their customers at risk. 

“Open source processes protect products and brand reputation,” continues Luszcz. “But, most software and IoT vendors don’t realize there is a problem, so they’re not protecting themselves and their customers. This endangers the entire software supply chain – for the vendors whose products are exposed to compliance and vulnerability risk. And also for their customers who most likely don’t even know they’re running open source and other third-party software, or that it may contain software vulnerabilities.”

Did ya hear that? Endangers the entire software supply chain. Way to ruin it for the rest of us, slackers.

So. The message here isn’t to avoid open source, it just needs to be used wisely. Whether you’re an OSS-purist or not, there simply isn’t a cost-effective way to avoid using open source. It would be like taking trying to write Hamlet without using any prepositions in English – “Be, or, uh…don’t. Yeah, that’s the question.” So if every piece of software uses some bit of open source, and a hacker manages to tap into a way to exploit those programming commonalities to get inside a system, they’ve got a golden ticket. The takeaway? It’s up to you, the independent software vendor (ISV) to be rigorous about your grammar usage, so to speak.

To start effectively managing open source risk, you must:

Educate

The basics of open source license compliance management should be taught at all levels in the organization. Senior management needs to understand license compliance requirements, and the value of periodically update products to remediate vulnerable open source components.

Set up an Open Source Review Board

The OSRB sets policies, responds to license compliance and security events and provides training and knowledge to the rest of the company. It can be ad hoc or more tightly structured depending on a company’s maturity and size.

Implement Processes and Policies

The development/devOps teams can implement OSRB policies. They should first emphasize compliance with all open source licenses being used. Then they should focus on creating a process to discover vulnerable components and release updates as needed.

Automate 

Software Composition Analysis (SCA) tools will help discover and manage the open source and third-party content being used. These tools can alert companies to vulnerabilities and licensing issues.

Track and report

An SCA solution allows you to track and report on open source use throughout your organization. Streamlined reporting and security alerts benefit software teams and executive management. Customers also win because they’ll get accurate third-party notices and Bill of Materials for compliance and license obligations.

Most importantly, you protect your clients, your company and your reputation.

Look alive, stalwart creators and defenders of the digital world. Just cuz it’s open don’t mean it’s safe, savvy?

The views expressed in this column do not necessarily reflect the views of Penton Media or The VAR Guy editorial staff.