After years of vulnerabilities like Log4j, Heartbleed and other open-source vulnerabilities wreaking unknown levels of havoc on digital society, the federal government has arrived with a plan.
On Tuesday, the Cybersecurity and Infrastructure Security Agency released its long-awaited roadmap for open-source software, laying out a number of tasks and goals that U.S. officials hope will lead to better tracking around the use of such code in commercial and government IT environments and spur quick action from the cybersecurity community when a widespread or targeted vulnerability is disclosed.
As SC Media has reported, open-source repositories and libraries that produce and host some of the most-used pieces of open-source code are held together by small bands of volunteers who maintain and update the free code that quietly powers much of the commercial software world. While larger companies like Google and Microsoft are starting to devote more money to initiatives to identify and secure the most commonly used open source software packages, these efforts often amount to a small fraction of the vulnerable attack surface presented by the problem.
CISA’s plan is largely supportive of that general model, though it will aim to boost the resources and coordination between the private sector and government to make a more dramatic impact.
The agency “recognizes the immense benefits of open source software,” noting that it facilitates innovation in the software space while also allowing to work at an “accelerated” pace.
“We envision a world in which every critical OSS project is not only secure but sustainable and resilient, supported by a healthy, diverse, and vibrant community,” the plan said. “In this world, OSS developers are empowered to make their software as secure as possible.”
Roadmap aims to address vulnerabilities in the mold of Log4j, MOVEit hacks
CISA is primarily concerned with two scenarios that are anything but hypothetical: a piece of corrupted code that has become part of many different commercial and free software programs and intentional targeting of a software provider in order to gain access to the IT environments of their customers downstream.
The first scenario describes Log4j, the Apache vulnerability that was embedded in untold thousands of software programs around the world. The second describes something similar to the MOVEit hack. While that incident was not caused by open-source vulnerabilities, there are plenty of smaller-scale examples that worry CISA and other defenders.
CISA has few regulatory powers over this largely private and volunteer-run ecosystem, but it does have oversight over the cybersecurity of federal agencies and critical infrastructure, both of whom make regular use of open source software.
Not surprisingly, the agency’s first goal revolves around building better relationships with the open source community so that high-impact vulnerabilities can be identified and remediated before they can be broadly exploited by malicious hackers or nations.
The plan was released the same week that the Open Source Security Foundation hosts a two-day summit in Washington that will see software developers, security researchers and U.S. government officials come together to discuss how to cooperate better on open-source security.
CISA will establish a new “real time collaboration center” with open-source providers, foundations, code hosting services and other members of the community. In particular, officials will look to replicate the kind of public-private partnership model that drove remediation efforts around Log4j, with government and industry working hand-in-hand. They will also stand up an open source security working group to boost expertise within the agency.
Second, the agency will create a new “capability” that can provide better visibility over risky open-source code present in federal networks. One of the things that has made remediation of Log4j (or latent Kaspersky code) so tricky is the inability to easily find instances of them in programs and IT environments due to the lack of software bills of material or other methods of inventorying.
The agency plans to identify open-source libraries that are most commonly used by the federal government and critical infrastructure, while aggregating data from its Continuous Diagnostics and Mitigation program and others to better map out their software dependencies. It will also help to identify open-source components that are malicious or that may need direct federal support to be secured.
Third, CISA will look at developing shared services that open-source developers and organizations can lean on if they lack their own resources or staff. Those could include tools to monitor the continuous integration and continuous delivery (CI/CD) software development pipeline for risky code and flag out of date code components.
Finally, officials will look to bring the same hardening principles used for commercial software and other technologies to the open-source space. That means pushing further SBOM adoption across the ecosystem, security training for open source developers, the development of best practice guidance and a robust vulnerability and disclosure process that “may include establishing processes to specifically look for upstream issues in open source packages that critical infrastructure organizations depend on and quickly notify affected users of the identified vulnerabilities.”
