In Part 1, ‘[ ________ ] is the Best Policy, we looked at some of the common aspects of an open source policy and discussed how our recent survey discovered that 41% of people think that policies are not enforced. Now in Part 2, we will look at how effective policies are when considering security concerns.
Policies within a technology organization are generally intended to adjust behavior in a certain way. They try to get people to do less of one thing or more of something else. It’s really just a basic tool for social engineering on scale. Well, that’s when they work, of course.
Strange Beasts
Policies are strange beasts, quite often designed and constructed by people other than those who are responsible for doing the work that will soon be governed. In some instances the policy writers are far from being experts in the underlying subject matter (I wish this had been a survey question…). What is common, in pretty much every case though, is that someone has demanded a policy and they probably wanted it yesterday.
Policies can be born out of someone’s architectural bias, from audits, as a result of an unwanted event, as a cost cutting measure, as a legal requirement or for many, many other reasons. Whatever the initial drive, someone is often made responsible for the successful introduction of a policy. (Note: Not successful adoption. That is often federated out, which in turn can lead to diffusion of responsibility...another topic for another day).
The Fear Factor
Unfortunately, due to the fear of adding further work burden to teams, it is quite common for policies to drive towards things that are already achievable. This often dilutes their initial purpose. If this happens, the policy will no longer change behaviour in the way it was originally intended. But a policy will exist. And so the exercise, at least from one perspective, is complete.
I was once told that delivering the wrong thing is better than delivering nothing. It sounds so very wrong, but happens all the time. People measure output first, quality second. Unfortunately, policies would seem to fit that paradigm a lot more often than they should.
Where Concepts and Practice Differ
If we look at the basic open source policy we described in Part 1, it was mainly focused on possible security issues. The idea was that we find security vulnerabilities or license issues and make sure we’re getting open source software from an appropriate source. While simple in concept, practice often differs.
Based on our June 2014 survey results, 39% of people said the actual policies that were put in place did not look to address security concerns. This would seem to backup our slightly whimsical overview of policy creation above. 39% of people are alluding to the fact that the policies are both ineffective and encourage box ticking behavior. Have you ever thought a policy in your organisation was there purely for show?
There is Hope
There are strategies you can employ to guard against this and to prevent falling into that 39%. When writing a policy one should also look to also define measures of success for the implementation to ensure it can be effective for the purposes the policy was originally intended.
For a policy which says:
- Thou shalt not bring in software from unknown or suspect sources
- Thou shalt not use software with serious security vulnerabilities
- Thou shalt not use open source software with a license which may cause nasty legal issues in the future
Measures of success for the implementation might look like :
- There is a central strategy and coherent logical repository for storing open source software acquired from external sources. This solution should allow approved external sources to be defined / configured and have the ability to define entitlements to be applied for publishing of software components outside of the approved source.
- There is a mechanism to measure the number of vulnerabilities observed and a process to remediate vulnerabilities discovered.
- There exists a solution to identify the open source license type of a software component and a reporting mechanism to display the license type at appropriate stages of the development lifecycle.
Meaningful Change
When you have met the measures that enable the implementation, you can be more confident that the policy can be enforced. You can also drive a policy which is meaningful.
The working group which is established to build / review a policy can also be more easily lobbied, resulting in a policy that will change the behaviour of the organization in the way it was intended. If policy creation and implementation are considered as an atomic unit, the chances of success will increase dramatically.
Creating, implementing, and enforcing policy is often much easier said than done. That said, I hope the advice here will help you throughout your journey to success.
Finally, here at Sonatype, we offer policy workshops if you are looking to take a more prescriptive approach to managing and automating open source policies.
Written by David Jones
David is a former Chief Solutions Architect at Sonatype. He is now the Head of Developer Tools & Services at Credit Suisse.