Creating a More Secure and High-Quality Open-Source Supply Chain

Josh Bressers works as security strategist at Red Hat, Inc. He has 15 years of experience in the security field. The views expressed in this article are his personal views and do not reflect those of his employer.

As the world’s value-creation activities move from industrial manufacturing to software asset development, and use of open-source software becomes more prevalent, government IT personnel should look to the past to ensure their future. This means taking a close look at their software supply chains and the components they’re using to build applications. A major area of focus should be software supply chain.

Open-source communities are engines of innovation that foster conditions to allow the best ideas and implementations rise to the top. That said, these communities often leave their projects behind as they continually focus on the new and exciting; they don’t see themselves as key suppliers to a complex system integrator; they just want to innovate.

» Get the best federal technology news and ideas delivered right to your inbox. Sign up here.

Community-created artifacts are innovative, but these components need a rigorous quality assurance process to ensure they are ready for enterprise assembly and consumption. Because let’s be honest: While the Wright brothers were part of the aviation development community, most of us would prefer to fly our families on a Boeing jet.

The same basic idea behind traditional industrial supply chain management can be applied to open-source software: fewer suppliers and high-quality parts lead to a reliable product. But open-source software supply chains have grown in complexity as open source becomes more popular. If federal IT professionals are not careful, they could end up with a huge number of suppliers and low-quality parts. Because like all software that has come before it, some open-source software is extremely high quality, and some is fairly low quality. Agency personnel must understand the difference, and that’s not always obvious.

Open-source projects have difficult to follow supply chains, which can lead to several questions. Who is contributing to the software? Why are changes and features being added? Who is verifying the quality of the changes and features?

To make things even more confusing, most projects depend on, or sometimes even contain copies of, other open-source projects. This has a multiplying effect as project dependencies grow. The whole concept is to share ideas and code, not create an unmaintainable mess.

Given all this complexity, how can anyone expect to understand what’s happening?

Unfortunately, there is no silver bullet to having a secure and high-quality supply chain. Agency professionals consuming or developing products (or even something in between) must know who their suppliers are, work with them to understand the “parts,” and, most importantly, keep records of what was received, including from where, why and by who. This process is incredibly complex—and quite likely impossible for a single agency to tackle by themselves.

There are a few strategies agency administrators can adopt to help their open-source supply chains remain secure and reliable:

Build a parts list. It seems like it should be easy to know and understand the parts being used. However, in many cases, these solutions have been built up over years, by people who left long ago and never documented what they did or why. As such, when users start trying to track everything they will start finding skeletons everywhere. Building a parts list is essential. Without that, there’s no supply chain—or way to conduct the next steps.

Understand the quality of the parts. As mentioned before, open source can vary widely in terms of quality, and it’s not a simple task to understand the difference. This step will require competent staff. Even if managers use external ratings for each project, they’ll need someone who understands the ratings and software to make the final decision as to what’s good or bad. Remember, though, everyone is different; there is no one size fits all.

Ascertain security implications. Even high-quality software has security problems. In some cases, high-quality projects will have more security bugs than low-quality projects because they treat security more seriously and have people looking for problems. Agency managers should never assume the project with the most security bugs is the worst. How they use a particular open-source project will determine what their security requirements are. An internal tool used by one person is not comparable to something operating in a classified environment.

The thought of using open source in your agency is no longer an option—it’s here, it’s in use, and it’s not going away. Rather than putting resources into fighting a battle you can’t win, find vendors, staff and projects you can trust and rely on. There is a great deal of expertise around managing open source, from projects rating security quality, to vendors that can scan infrastructure and codebases, to applications able to identify known security problems that exist in open-source code (and, in some cases, advise on how to fix those issues). Remember that while tackling the open-source supply chain would be nearly impossible to do alone, it’s a challenge we can all solve through collaboration.