With component usage skyrocketing, shouldn't every organization have an open source governance policy? My experience shows this is not the case. And as a developer, if you don't have a policy, consider yourself lucky! Why? Because policies are a pain. They burden your development effort with unnecessary overhead. And if you are like most us, you spend your time working around policies while seeking forgiveness later.
But maybe it's not the policy that's the problem… maybe it's the implementation of the policy that is the issue.
Because as developers, we want
- to produce quality applications free of defects.
- to deliver secure applications that can't get hacked.
- to protect our organizations from a potential loss of intellectual property (IP).
So let's play the "what if" policy game. What if
- they weren't paper-based or manual?
- they didn't rely on a cumbersome approval process?
- they actually added value and helped you deliver applications faster?
- they made security alerts/vulnerability reports actionable?
- they were ingrained into the tools that you use rather than forcing you to learn another tool?
- they provided guidance early in the development process rather than slapping you on the wrist later?
- they supported your existing development process - from design to develop to build to QA to production?
So how can we make that a reality? Well, there is no magic wand but questions like these should form the foundation of your strategy. And once you build that strategy, you have to determine how to roll it out, and how to scale it. Like other development related activities or processes, the big bang approach is not advisable. But if you take a non-invasive approach, meaning that the policy approach that you use does not rely on intrusive code instrumentation, you can not only start small, you can start with your critical applications.
Here are steps to consider as you start down the path of implementing a policy approach that governs your component usage AND guides and speeds your development efforts:
Build an inventory: It's difficult to manage your components and applications if you don't know what you have. You can start by building an inventory of your critical applications – but don't forget the component dependencies!
Determine your threat exposure: Define policies that accurately reflect your organization's risk profile. Use these policies to 'audit' your key applications. Once you determine that your policies will not overwhelm your developers, you can ratchet up control.
Prevent vulnerabilities and remediate flaws: Ultimately, your policy approach should help you eliminate vulnerabilities by fixing flawed applications. Once you have identified the exposures, you need to develop a remediation plan. And you should use your policy from the start so that you can prevent problems before they make it into your applications.
If you design your approach with developer productivity in mind, it's actually possible that your open source policies can make your organization more productive.