Creating Your Open Source Policy Template: 3 Points You Don’t Want to Overlook

The vast majority of enterprise level companies employ some level of open source policy in their organizations. Their purpose is to create company-wide guidelines for the use of open source components. However, there’s a fine line between theory and practice and more often than not these open source policy templates fail to fulfill their purpose because they lack enforcement and the supervision needed to ensure developers are following them.

Much has been written about the makeup of open source policy templates. What needs to go into them and the best practices for their assembly, but often times these guides leave out critical aspects of policy implementation. Before you go setting your policy, make sure you don’t leave out these three crucial points.

Out with the manual and in with the automated implementation of open source policy templates

As detailed and scrutinous as your open source policy template may be, if it lacks the automation tools to identify open source components, surface their vulnerabilities and track their remediation, then the policy you set cannot be counted on to work.

Manual tracking of open source components on spreadsheets and managing licenses over emails is impractical and unsustainable over time. Given that open source components comprise 60% to 80% of modern applications, the amount of open source components used and their multitude of dependencies simply cannot be encompassed manually. Therefore, any policy template that fails to discuss automation as a leading principle is shortchanging you and will not get the job done.  

Open source components are dynamic by nature. They get worked and reworked by the open source community on an ongoing basis, leading to new vulnerabilities being found and others being fixed continuously. This makes periodic testing for open source vulnerabilities ineffective. Only an ongoing, continuous process, that simultaneously monitors your open source usage and is automatically synced up with the multiple vulnerability documentations boards run by the open source community can effectively and efficiently notify of open source vulnerabilities in real time as they come up.

Who’s enforcing your open source policy template?

You have your policy in place and you know what you want to achieve. You want your code to be clean as a whistle, have no outdated components and legacy versions, and comply with the license boundaries you set. What you need now is an enforcement process to see your policy through. Without one the policy you created will remain stashed away in a company shared folder to collect dust.

To ensure effective policy enforcement the developers “on the ground” must receive real-time feedback. An immediate response rate will keep the process moving and ensure developers can shift from component selection to pull and integration swiftly.

The enforcement process starts at the component selection stage, where the components chosen must meet the company’s open source security, quality and licensing policy. If components are within the parameters set in the policy, they are cleared and can be used by developers at will. However, if a chosen component fails to meet the policy, it will be flagged and brought up to team leaders for inspection. This is the approval process. Foregoing the red tape in the pre-selection stage may well spell out the insertion of vulnerable or otherwise faulty components into your code.

The need for policy enforcement does not end at the selection stage. Components may turn vulnerable even if they were cleared for use when entering your code. To ensure your policy’s security standards are kept throughout all stages of your product’s lifecycle, a continuous monitoring of your open source inventory is needed, along with a reaction process and a chain of command management. Who will be alerted of the vulnerabilities found? How long will they have to treat them? Who will be overlooking their fixing? Answer these questions as part of your policy building process and remember that the enforcement of your policy is as critical as creating it in the first place.

Striking a balance between boundary setting and over-restricting

Developers want to code, it’s as simple as that. And they want to do it as freely as possible and with as little restrictions as they can get away with. The question for management then is how to carry out their open source policy without the red tape it produces slowing down the development process. Because let’s face it, developers don’t like to be slowed down. Development environments these days are agile and forward moving, with emphasis on speed and turnover. They don’t like to anticipate security or legal catastrophes down the line and constrain themselves in the here and now to presumably prevent them.

The answer lies in a balancing act. A delicate tug and pull between allowance and restriction. Requiring your developers to comply with your policy yet giving them enough freedom to code comfortably.

Some good old lobbying is helpful too, to melt away resistance and help get the ball rolling with your developers. The logic is simple. Today’s open source policy tools are automated and hands-free. They work in the background and won’t interfere with development. They will save developers the swift kick in the backside when a vulnerability is found right before release and the heartache of late remediation and reverse engineering. Despite all these promises, it can be a hard sell in agile development environments that have not yet welcomed the DevSecOps trend. The trick is in making the risks tangible and the cost of a violation a genuine threat. It’s about reminding developers that a breach brings the company to a screeching halt while complying with a security policy merely slows down the process slightly.

And then too it’s on you, the policy maker, to ensure a smooth enough enforcement system that development remains agile and forward moving. Show them there will be no bottlenecks, no downtime, no stagnation, and you just might get them on board.