September 29, 2023

The US. CISA has released its long-awaited roadmap for open-source software, laying out several tasks and goals that 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.

The 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.

Organizations like Google and Microsoft are starting more initiatives to identify and secure the most used open-source software packages, these efforts often amount to a small fraction of the vulnerable attack surface presented by the problem.


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 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 like 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’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.

The second goal is that 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 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 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.

The third goal is that 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, the hardening principles used for commercial software will be applied 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.”

Leave a Reply

%d bloggers like this: