The good news: you have an open source policy in place (on paper).
The bad news: your development organization is not following it.
THE REALITY: A policy that is not enforced, provides no protection.
Your first thought might be “ugh”, why isn't anyone following the policy? Which leads you to question..."But what about the rules? What about the risks? What about all that training?”
Over the past four years, Sonatype has surveyed open source development organizations and year after year, we find that developers have the best intentions. They strive to build good quality code, free of defects and flaws but when it comes to policies that enforce these standards, the manual review process is at odds with how developers really work. If you don't believe me, here are just a few examples of how developers describe the challenge manual policies create.
“Our development runs at top speed, manual policies do not”. -- developer from global manufacturer
Development moves quickly, it’s agile, it’s nimble. And manual policies...well, they are restrictive. Developers are using hundreds of open source components to build their applications. While they understand that components with known vulnerabilities or worrisome licensing risks should not be used per common sense (and your policy), they likely do not have an easy way to check for the risks and vulnerabilities. Spending the time to check will slow the pace of development and increase the stress of time-to-market pressures.
"5 simple words: we find out too late”. -- developer from fortune 100 financial services firm
Perhaps you do not require your developers to check for known vulnerabilities in your open source components; you have assigned this task to another group who works side-by-side with development. We often hear that these processes are too slow, too laborious, and result in late notification to developers of components that fail to meet policy expectations. When notified too late in the development process, it creates re-work and developers hate rework. We have also heard that manual component reviews for policy compliance and vulnerabilities by legal, risk or compliance teams is $%^#-ish work (sorry,
“Policies aren’t enforced”. -- developer from multinational investment firm
Often policies are put in place to act as guidelines for development. But all too often, enforcement of the policies is lacking. And workarounds are all too common. We often hear from developers that they simply don’t know what is expected of them from the policy; this is likely the case more often that you would think. If there is not ongoing training and easy to use tools integrated into the software development lifecycle than workarounds will continue to be the norm.
Not all hope is lost. There are more organizations adopting policies and more development teams are aware of them. But the key to enforcement -- offered by our customers and many industry thought leaders -- will be speed and availability. The faster the information about policy violations and risks are made available to developers, the easier it will be for them to proceed with their primary task: building innovative applications quickly. The more frictionless policy enforcement becomes the more successful you (and your developers) will be.
If you want to learn more about frictionless, scalable and automated open source policies, I invite you to read our latest paper: 7 Security Gaps in the Neglected 90% of your Applications.
