Like many organizations, you have turned to Nexus as a repository for your components. Since that is going so well, you may be thinking adding controls that turn Nexus into a Golden Repository. It’s natural to try to manage components by restricting usage to only those components approved by your security, licensing and architecture teams. Unfortunately, what sounds like a good idea actually has a ton of unintended consequences, most of them negative.
We know because we have already been down this path. We built much of the Nexus governance capabilities based on these golden repository requirements. We had tons of conversations with customers and we built and delivered what we thought they wanted. Then, reality struck - customers started to use Nexus to control access to approved components. They wanted to ensure that developers used only the best components so that the applications they constructed could be trusted and free from licensing issues.
So what went wrong? This is not an indictment of using Nexus as a repository manager. Nexus is a key instrument in managing and storing components - and we all know that components represent the critical building blocks for our applications. So while Nexus Pro features such as smart proxy, LDAP, build promotion and staging, make it possible to implement a highly performant, scalable repository that helps provision components and drive the release management cycle, something was missing in terms of using Nexus as the Golden Repository.
It turns out that the problem was not a functional limitation with Nexus - Nexus procurement support does a fine job of controlling what goes into the repository. The issue is a process problem that led to unexpected consequences. Here are just a few of those limitations:
Developers bypass the repository because it gets in the way of their development efforts.
Approvals couldn’t keep pace with the volume and release cadence of components.
Component versions became stale and organizations lacked the ability to identify new vulnerabilities, and to purge/replace those components from the repository.
A golden repository couldn’t meet the needs of different departments or application profiles - not all applications share the same risk profile.
The golden repository does nothing to help you manage newly discovered vulnerabilities in your production apps.
We knew that the repository concept was solid, we just had to improve the way that we implemented component governance. We learned that:
Guidance and governance was needed throughout the entire software lifecycle.
Automated policies were needed to replace approval laden approaches.
Continuous monitoring of applications was necessary to identify new vulnerabilities.
Flexible policies that are organizationally aware are needed to manage different department and application needs.
Component governance has to be extended to support the production environment because application usage and component vulnerabilities are not static.
In short, you need a Golden Policy Approach, not a Golden Repository Approach.
Since many of our customers were turning to us for help - we felt that the topic warranted a proactive effort to educate others using Nexus as a repository for component governance. As part of this educational effort, we have scheduled a webinar to help you determine the best way to implement component management. And those that register for the webinar will also receive a design brief on how to augment their repository with a policy-based approach that manages the entire software lifecycle. Register now!