Components as Process

Author, Chris Riley

Author, Chris Riley

The developer space is not boring. Over the past 10 years, as many businesses have adopted the DevOps approach to rapid, agile development for rapid software releases. Simultaneously in the last decade has witnessed a huge increase in the use of open source code, especially in the form of pre-constructed components. Whereas at the turn of the millennium enterprise software was over 90% proprietary, rarely using open source components, today we see the opposite. Most builds now consist of over 90% open source components, with very little use of proprietary code, if any.

The Problem

It does not take much to see the problem here, more releases with more components. A huge matrix of process and moving pieces. There are many tools for handing the DevOps processes. And Maven, a powerful tool for component monitoring and management.

This seismic shift away from in-house development has left project managers who use Maven facing four major hurdles. These are areas which must be addressed when ensuring the robustness and security of deployed products. And preventing a disaster as DevOps meets the complex, component laden development environment.

  1. The first of these hurdles is ecosystem complexity. Many components rely on hundreds or even thousands of other components to perform their functions. While any component may appear secure in and of itself, each dependency it exhibits can open new vectors for the dedicated attacker.
  2. The second hurdle is the shear diversity of components available for Maven users, with over four hundred thousand currently available for use, encompassing some two hundred million classes. There are, quite simply, too many different components for any manager to understand even a small fraction of the development options available.
  3. The third hurdle is the volume of components in use, which results from the great diversity that are available. Most enterprises use thousands of components every month, which makes it difficult for even the most inspired project manager to understand what everything does, how it does it, and why.
  4. Finally, those tasked with managing components are confronted by the fact that all of the thousands of the components in use are constantly undergoing change. Most components update at least every quarter, with active projects updating monthly or even weekly. Each new iteration of each component offers new opportunity for the introduction of a security-compromising error.

As the average cost of a security breach in a major corporate system is about $5.5 million, each new vulnerability must be identified and ameliorated as quickly as possible. Furthermore, if you don’t fix it early, you will pay more to fix it when you do. Even if there is no breach, correcting an error after it pushes out to distribution (which happens rapidly in many DevOps implementations) can be heartbreakingly expensive. Essentially, the cost of a fix rises exponentially with each further step it takes through the development/deployment cycle. Security fixes implemented in the design phase cost a mere fraction of those which must be addressed after final builds have been distributed to (and often further modified by) operations users and customers.

With no update infrastructure in place to track the evolution of the base components your developers use, security issues become viral, spreading to all systems that implement the compromised component, but fixes do not. In order for fixes to be implemented, the developer using the component must be aware of the issues discovered, and then update their own build with the corrected component before pushing the new final code to users.

A second area of concern when running a Maven-based DevOps team is Licensing and IP. A lack of proper consideration for the validity of your license to use the code you implement can be as damaging a liability as using code with open security holes. Code made available for “free” through public hubs often includes some form of structured license, and it is your responsibility, as the entity using the code, to conform to these restrictions.

The set of licenses for a series of components is either valid or invalid. There is no middle ground. Often, even though components may work together flawlessly and securely, their specific licenses are incompatible, making any project combining these components illegal to distribute under any license.

However, many components which bundle contractually-incompatible dependencies are released nonetheless, thus creating considerable legal landmines for developers unwilling to trace back and affirm all the different licenses associated with their dependency chains. There are only two solutions if conflicting licenses are found in the chain. One is to contact the authors of those components directly and to convince them to re-release their code under a license compatible with your specific licensing scheme. The other is to remove and recode those portions of the chain yourself.

A Toolset to Investigate

While this might all seem terribly time-consuming, there are several tools which make the process of component analysis much easier for the dedicated project manager. The first of the is the Transitive Dependency Graph, which provides a visual guide to how a given component relates with other components. Using such a graph makes it easier for one to trace back and locate any other components which might cause security or licensing issues.

The next valuable tool is the Application Composition Report. This standard report, available on Maven.org and other public repository sites, tracks the various components in each application and the composition of each component for the purpose of security and license audit.

The final tool, which I highly recommend, is a private repository. This can be set up on a local server using NEXUS (which currently has a 66% market share in this space) or one of several other repository hub designs. Using this configuration, you put a repository manager at your own organization in charge of collecting the components from development teams (both in and outside the organization) and then doling them out to build developers as needed. Developers’ work is then pushed back to the private repository, where the same repository manager who cleared the original components then becomes responsible for pushing software to directly to customers or internal operations users.

Conclusion

In this manner, there is a modicum of oversight guiding the usual DevOps paradigm of developers communicating directly with operations staff and pushing new code with every suggestion. Developers and operations staff are still encouraged to communicate directly and frequently, but the repository manager offers an essential check, preventing in-house developers from directly importing vulnerable, open source components, and at the same time preventing compromised and undocumented code from flowing freely out to users and customers. This helps to ameliorate both security and intellectual property liabilities, by preventing the use of components antagonistic to both those concerns.

About the Author

Chris (@hoardinginfo) Riley breaths software development. He is not your typical tech guy, he came from the world of heads down software development. Realize the gap between developers  and operations, and developers and business he felt the need to help developers advance their understanding of these areas.  He is a regular author and speaker in the areas of DevOps, Development Governance, People, Process, and Tooling.

 

The following two tabs change content below.

Chris Riley

DevOps Analyst @fixateio. Helping the enterprise embrace modern software delivery. Regular contributor to DevOps.com and other industry wbeinars and forums. @hoardinginfo
Authors

Related posts

*

Top