Rethinking your open source use policy

Actionable insights on balancing security and speed

09 opensource

We don’t code the same way we used to.

I spoke with someone the other day that was fired from his job as a technical product manager after more than 20 years of experience. He is now job-searching but is finding it difficult. There is a new bar set for speed of technology development that capitalizes on agile software development practices and leveraging open source technologies—two things that were not taken seriously just ten years ago. According to 69 percent of senior executives, this digital transformation is forcing us now to rethink our cybersecurity strategies.

To accommodate these time constraints from management, developers have turned more and more to open source code as a great asset to build products and features, as opposed to writing code from scratch.  Open source technologies are available openly on the internet through sites like GitHub and SourceForge. Open source code now makes up 90 percent of the code composition of our modern applications.

Dealing with this flood of potential risky external code into our websites and applications needs to be addressed through management-directed use policies.  These policies need to protect the organization from cybersecurity threats and potential lawsuits. When senior management, or the product safeguards, rethink cybersecurity strategies for next year, they should revisit their open source use policy if they’re not already doing so.

Here’s why this is important: 50 percent of code developers incorporate at least five new open source projects into their work each month. But enforcing a use policy that ensures the safe use of open source can be quite hard.

We surveyed a wide range of professional developers to get a better idea of the current state of open source use policy enforcement. We found that nearly 25 percent of developers claim their employers do not have guidelines for using open source and on the other side of the spectrum, 15 percent were extremely dissatisfied with the strict policies enforced by their companies—both methods are counterproductive. Here are some actionable insights on why to avoid both no policy and a strict policy and how to find a balance that helps both secure companies and empower development speeds.

Consequences of no policy

Not having an open source use policy becomes a liability for companies because of security and legal compliance reasons. Though not having a policy may save time and encourage creativity by letting developers use whatever open source they want, this is risky in the long run. About 30 percent of successful breaches strike at the application layer of a company. Those applications are typically company websites where customers can log in and store an account.

And now, since 90 percent of modern applications are made up of open source, it’s a huge liability to not know what open source components developers are plugging into your application’s code base and what potential security bugs are now present.

To take things further, developers can illegally integrate third-party code into a company’s application by ignoring associated licenses. Licenses are typically found in a file connected to the open source code being used by a developer. But if nobody tells developers to not use specific open source licenses, they may just ignore licenses altogether. Ultimately, this could result in a company having to freely distribute its product or pay royalties.

Consequences of a strict policy

On the flip side, having too strict of an open source use policy becomes a liability for companies because of the labor needed and the time spent to conduct approval checks. Of the companies we talked with, nearly one in five developers said that they had to wait a week or longer (some even up to a month) to get approval for open source components they wanted to use. That’s like trying to run a sprint with significant ankle weights on. It just doesn’t work.

What we’ve seen with this method of enforcement is that open source components are approved at the outset by a committee that includes cybersecurity, legal, and IT, and then these components are blessed forever. They are never reexamined for new security vulnerabilities or updates that may be beneficial to the company. There is a lot of time and work put into screening open source in these scenarios, but it is all futile if newly surfaced threats are not considered and addressed.


The bright side is that we’re already seeing some companies find the equilibrium that lies in taking responsibility off the hands of developers and having an automated process in place to find issues both initially and past the point of integration. After recent high-profile breaches, company executive management is starting to realize that when it comes to application security, the buck stops with it. Cybersecurity is franchise vulnerability risk that should be talked about by executives as a threat as potent as corporate competition. There needs to be a top-down approach to setting up policies that allow for creativity and speed, but still account for real potential software risk. The best way to do that is by using tools to automatically check for violations of the open source use policy and keep a tab on newly discovered exploitable software vulnerabilities.


Open source is an amazing asset that is putting everyone on an even playing field and is allowing all companies to become flourishing tech companies. Your developers are expecting to use open source to keep up with time constraints. 2018 is a great time to figure out if it is being leveraged safely. Set up a logical policy that requires scanning for security vulnerabilities and license compliance. Then design a low-friction process to enforce the policy without becoming a pesky cog in the wheel.  Your development teams will thank you for that.

Copyright © 2018 IDG Communications, Inc.