recommended reading

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

Kidsana Maimeetook/


By Josh Bressers December 28, 2016

recent posts

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.


Close [ x ] More from Nextgov

Thank you for subscribing to newsletters from
We think these reports might interest you:

  • It’s Time for the Federal Government to Embrace Wireless and Mobility

    The United States has turned a corner on the adoption of mobile phones, tablets and other smart devices, outpacing traditional desktop and laptop sales by a wide margin. This issue brief discusses the state of wireless and mobility in federal government and outlines why now is the time to embrace these technologies in government.

  • Featured Content from RSA Conference: Dissed by NIST

    Learn more about the latest draft of the U.S. National Institute of Standards and Technology guidance document on authentication and lifecycle management.

  • A New Security Architecture for Federal Networks

    Federal government networks are under constant attack, and the number of those attacks is increasing. This issue brief discusses today's threats and a new model for the future.

  • Going Agile:Revolutionizing Federal Digital Services Delivery

    Here’s one indication that times have changed: Harriet Tubman is going to be the next face of the twenty dollar bill. Another sign of change? The way in which the federal government arrived at that decision.

  • Software-Defined Networking

    So many demands are being placed on federal information technology networks, which must handle vast amounts of data, accommodate voice and video, and cope with a multitude of highly connected devices while keeping government information secure from cyber threats. This issue brief discusses the state of SDN in the federal government and the path forward.

  • The New IP: Moving Government Agencies Toward the Network of The Future

    Federal IT managers are looking to modernize legacy network infrastructures that are taxed by growing demands from mobile devices, video, vast amounts of data, and more. This issue brief discusses the federal government network landscape, as well as market, financial force drivers for network modernization.


When you download a report, your information may be shared with the underwriters of that document.