Yes, Policies Can Actually Speed Development

CONTROL, ENFORCEMENT, APPROVALS, POLICIES

These concepts run counter to fast, agile, based-development. These words make developers cringe, they are "4 letter words". Could it be that the problems with these concepts is not what they are trying to accomplish, but how they are implemented? They are intended to ensure that applications developers create are trusted, that they meet and exceed the expectations of the user, that they drive the business forward without placing the business at risk. Who can argue with that? Sure, developers want to build things fast, but they want to deliver applications with high quality. So, the intent is good, but the implementation is bad.

Before we discuss the problem with policies, let’s look at some data. Our survey of 3500 developers, architects and development managers show that organizations are exposed.

• 66% of organizations lack meaningful controls over their open source usage.
• Even if they have a policy, only 38% of organizations have control over what components are used in their applications.
• Open source policies are not only unenforced, they get in the way - 31% don't have enforcement / 28% state that it slows them down / 27% state that they find out problems too late.

So what is the problem with policies?

• They are manual - many organizations start with manual processes, but they can't keep pace with today's development approach.
• They are static - since policies aren't easy to change, they tend to remain static, they don't react to change.
• They are inflexible - if enforced, the same enforcement action is taken across the development lifecycle, which doesn't provide the flexibility needed for stage appropriate action.
• They are document-centric - many policies are documented in written form and components are tracked in spreadsheets.
• They are generic - since policies are difficult to manage, generic policies are often created that don't account for specific department or application needs.
• They are approval-laden - many organizations that manage open source component usage require developers to start an approval process that requires approval from the legal/compliance, security and architecture teams.
• The implementation is reactive - most policies are punitive in nature, they don't provide guidance, they simply are used as a checkpoint late in the development lifecycle.

These implementation problems are exacerbated by how applications are constructed today:

• Applications are constructed of components - the typical application is comprised of 80% or more open source components.
• Component volume, diversity, complexity & release cadence make it impossible for manual, or approval-laden policy approaches to keep up.
• Organizations not only have a large number of components to manage, they have a large number of applications to manage - both existing production applications as well as applications that are currently in development.
• Organizations need to account for the varying risk levels of different departments or applications. Not all applications or usage is alike - some application scenarios require more vigilance. Not all applications are deployed in the same fashion - some deployment approaches allow more open source license flexibility.
• Agile-based development or fast waterfall delivery cycles - development cycles are fast, imagine asking a developer to start an approval process that will take weeks, when they have a deadline in several days!
• Security, Legal/Compliance, Architecture, Dev, IT Ops silos - due to specialization, many organizations have silos of expertise. Unless the policies can accommodate all of the different constituents and facilitate effective collaboration, they will fail.

One Potential Approach - Automated Workflow

Ok, so now that you understand the problem, what can you do about it? One potential approach that some organizations and vendors have taken is to take the manual processes and apply workflow. This approach is borne out of the BPM world - with the old thought that if we use automated workflow, the approval process will be streamlined and developers won't be bogged down with manual work. Sounds good? Well, hold on a minute, because this approach has the following limitations:

• Automated workflow is still primarily linear - security, legal/compliance and architecture teams still need to address every component.
• It's still reactive - the approval process starts when a developer identifies a new component they want to use.
• Since it is reactive, policies can't be used to guide component selection.
• It doesn't provide enforcement throughout the lifecycle (no way to know if developer bypasses approved list of components).
• It's designed to automate the approval process, it doesn't help manage the introduction of new component versions.
• It doesn't identify and notify appropriate constituents of newly discovered threats.

So the approach sounds reasonable - even if you cut the approval process in half, you still can't keep up with the volume, variety, complexity and release cadence of components. You still can't provide the up-front flexibility that your developers need to try out new components. You still don't have the ability to guide and enforce action throughout the lifecycle. You still don't have policies that will help manage your production environment.

What's the side effect of policy approaches that don't work? Well, they either slow development, or developers ignore the policies, or developer settle for sub-optimal components because they are on the approved list. Each of these outcomes is a problem. If development is slowed, the business doesn't get what it needs, and finger pointing ensues. If developers bypass the policies, organizations are put at risk because components are not properly vetted. And if developers follow the policy and use out-dated components that were previously approved, then they are constructing applications with sub-optimal components. There has to be a better way!

The Better Approach - Automated Policies

Luckily there is a better way, and it's actually not as difficult as it may sound. You can leverage the work that you are already doing with your repository manager and extend governance with automated policies. That's right, instead of automating the workflow, you leverage automated policies that keep up with today's agile, component-based development efforts. This approach provides the following benefits:

• Frees humans to focus on higher value tasks (policy definition and exception management).
• Provides up-front guidance for optimal component selection vs. late in the process "scan and scold" approach.
• Automates guidance and enforcement throughout the lifecycle directly in the tools that developers use.
• Accommodates risk profiles for different organization / application requirements.
• Provides the up-front flexibility developers need while ensuring production deployments meet your standards.
• Frees developers from hassle of initiating approval process - they just have to manage exceptions.
• Policies drive proactive notification and action for newly discovered vulnerabilities (continuous trust for production apps)

Our Component Lifecycle Management approach leverages automated policies so that you can keep up with the volume of components while providing guidance and flexibility your developers need. And the end result will be applications that you assemble are trusted and remain trusted over time.

We also realize that there isn't a single correct way to expand your governance approach. Sonatype has designed the CLM so that you can support your most critical needs, and you can expand usage over time. It could be that you want to start by assessing the risk of applications in production. It could be that you want to start by using policies that will manage your release process. Or it could be that you want to use policies to provide guidance to your developers early in the development process. Sonatype supports each of these approaches and more.For more information check out the CLM product.