By Daniel Moch, Lockheed Martin

Everyone—from private companies to governments—is aware (or is quickly becoming aware) that the security of their software supply chain is critical to their broader security and continued success. The OpenSSF exists in part to help organizations grapple with the complexity of their supply chains, promoting standards and technologies that help organizations faced with a newly disclosed security vulnerability in a popular open source library answer the question, “Where do we use this library so we can go update it?”

In my work in the public sector, I have an additional layer of complexity: the labyrinth of policies and procedures that I am required to follow to comply with security requirements imposed by my government customers. Don’t get me wrong, this is good complexity, put in place to protect critical infrastructure from advanced and evolving adversaries.

In this post I will describe some of the challenges public sector organizations face as they try to manage their supply chain and how the OpenSSF, with the broader open source community, can help address them. My hope is that meeting these challenges together, head-on will make us all more secure.

Public Sector Challenges

Exposure

Even in the public sector, open source software is being used everywhere. According to Black Duck Auditing Services’ Open Source Security and Risk Analysis (OSSRA) report, as of 2024 open source software comprises at least part of 96% of commercial code bases, with the average code base containing more than 500 open source components. A vulnerability in any one of those components might present significant risk if left unpatched and unmitigated.

Assuming the figures in the public sector are in-line with this report this represents a significant amount of exposure. Unique to the public sector are the risks that come along with this exposure, which don’t just include lost opportunities or productivity, but may put lives in jeopardy. For example, if part of a nation’s power grid is brought down by a cyberattack in mid-winter, people might freeze to death. The added risks, particularly where critical infrastructure is concerned, heighten the need for effective supply chain security.

Identification

Another area where public sector organizations face increased scrutiny is around identification, or what NIST SP 800-63A calls identity proofing. That document describes the requirements the US government imposes on itself when answering the question, “How do we know a person is who they claim to be?”

To provide a satisfactory answer to that question, a person needs to do a lot more than demonstrate ownership of an email address. It is a safe bet that organizations working in the public sector are going to follow a more rigorous identification standard for employees operating on their behalf, even if they do not follow NIST’s guidance to the letter.

It should be obvious that systems supporting the development of open source software do not adhere to this kind of a standard. GitHub, for example, does not ask to see your government-issued ID before allowing you to open an account. As a result, public sector actors must live with a double standard—proving to the government they are who they claim to be on the government’s terms but judging the identities of open source contributors by a different standard.

All that may not be a problem outright. Indeed, there are good reasons to allow open source development to happen without rigorous identification standards. It does, however, introduce some tensions that public sector organizations will need to deal with. For example, if a contractor is required to ensure none of the code in her product originated in a foreign country, how does she ensure that is true for any open source component she is using?

Approval Timelines

When I speak to others in aerospace and defense (part of the public sector, since our customers are governments), the conversation often turns to approval timelines to get software packages onto various, closed networks. The security teams responsible for these approvals have an important job, protecting the critical information on these networks from malicious software. How do they go about this work? Beats me. And even if I could tell you how it worked for one classified network, it would likely be quite different for another. What we have today is a patchwork system, an archipelago of isolated networks protected by security teams doing the best they can with the tools available to them. Historically this has meant manually curated spreadsheets, and lots of them.

This problem is not limited to networks used within aerospace and defense, but keeping the plight of these security groups in mind puts into sharp relief the basic problem faced by every group charged with protecting a network. There might be sufficient information available to make an informed decision, but there has historically been little available in the way of tooling to help bring greater confidence, ease and speed to the decision-making process.

How The Open Source Community Can Help

I have outlined three basic problems that the public sector faces: the risks associated with security vulnerabilities, the limits of identifying where open source software originates, and the timelines associated with getting software approved for use on isolated networks. Now let’s consider some of the ways in which the open source community can help alleviate these problems.

While there’s clearly nothing the open source community can do to directly reduce the risk posed to public infrastructure by vulnerabilities, there are ways maintainers can help the public sector make more informed decisions. Providing a SLSA Provenance alongside build artifacts is a great way to give public sector organizations confidence that what they’re using is what maintainers actually released. What’s more, a Level 3 Provenance gives a high level of assurance that the build process wasn’t interfered with at all. It is possible to achieve SLSA Level 3 by using GitHub Actions.

SLSA Provenance also provides useful information to the groups charged with securing networks (our third problem above). Going further, maintainers can also provide VEX documents with their releases to describe the known vulnerabilities and their status. One interesting use case that VEX supports is the ability to declare a vulnerability in an upstream dependency and assert that the vulnerability does not affect your project. That is useful information for a security group to have, even if they take it with a grain of salt.

That second problem—the impossibility of confidently identifying origin—is one that public sector groups will need to learn to live with. We cannot expect every open source contributor to identify themselves and the country where they reside. In light of this, perhaps the best path forward is for the open source community to develop reputation-based ways to score individual contributors. One could imagine ways of doing this that would both respect individual privacy and provide on-ramps for new contributors to begin building trust. This is almost certainly being done informally and piecemeal already. Systematizing it would only bring more transparency to the process, something that everyone would benefit from.

These kinds of third-party systems would be beneficial beyond contributor reputation as well. There are a variety of data sets useful to supply chain security that are likely being collected by organizations already. When possible, these should be made publicly available so the entire ecosystem can contribute to, help curate and benefit from them. But we cannot stop there. These data sets should be supported by easy-to-use interfaces that help security teams build confidence in the software they are being asked to allow on privileged networks. In short, we should welcome ways to make supply chain security and transparency a team sport.

Conclusion

To sum up, we have considered three challenges that public sector organizations face when securing their supply chains: The high potential impact of supply chain risks, the lack of ability to identify country of origin for open source software, and the long approval times to get new software onto closed networks. We also discussed how the open source community can work to close these gaps. It is worth repeating that doing so would make all of us—not just the public sector—more secure.

It is also gratifying to see the ways the OpenSSF is already contributing to this work, primarily by laying the foundation upon which this work can proceed. SLSA and VEX (in the form of OpenVEX) are both OpenSSF projects. Getting projects to adopt these technologies will take time and should be a priority.

About the Author

For nearly 20 years, Daniel has worked as a software engineer in the Defense and Aerospace industry. His experience ranges from embedded device drivers to large logistics and information systems. In recent years, he has focused on helping legacy programs adopt modern DevOps practices. Daniel works with the open source community as part of Lockheed Martin’s Open Source Program Office.