In "Part 1, [ ________ ] Is the Best Policy," we looked at the common aspects of an open source policy and discussed how our recent survey discovered that 41% of people think 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, often designed and constructed by people other than those responsible for doing the work that will soon be governed. In some instances, the policy writers are far from 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 probably wanted it yesterday.
Policies can be born out of someone's architectural bias, from audits, due to 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 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 behavior 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 wrong, but happens all the time. People measure output first, quality second. Unfortunately, policies seem to fit that paradigm much 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 ensure that 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 were not intended to address security concerns. This seems 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 organization was there purely for show?
There Is Hope
There are strategies you can employ to guard against this and prevent falling into that 39%. When writing a policy, one should also look to 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 can define entitlements to be applied for publishing software components outside 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 SDLC.
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 meaningful policy.
The working group established to build / review a policy can also be more easily lobbied, resulting in a policy that will change the organization's behavior in the way it was intended. If policy creation and implementation are considered 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.
Tags
Try Nexus Repository Free Today
Sonatype Nexus Repository is the world’s most trusted artifact repository manager. Experience the difference and download Community Edition for free.