Earlier this month, the U.S. government’s Cyber Safety Review Board (CSRB) released its “Review of the December 2021 Log4j Event,” a series of observations and recommendations related to the Log4j vulnerability. The report is based on interviews with representatives from 40 organizations, including government agencies, commercial enterprises, and nonprofits.

The publication has three main sections. The first reviews the fundamentals of the vulnerability and industry’s response to it. The second analyzes factors that contributed to the exploit along with its impact on business operations. The third — which will be the focus of this blog post — offers recommendations to help organizations improve software security.

Editor’s Note: The CSRB’s report includes guidance for both U.S. federal government agencies and organizations in the private sector. Here, we’ll focus primarily on recommendations for private enterprises, although we will highlight notable suggestions for government agencies.

Watch On-Demand: Log4Shell — A Case Study in Responding to OSS 0-Days

Don’t Forget About Log4Shell

Although Log4Shell was disclosed in December of 2021, the vulnerability continues to threaten organizations today. And, the CSRB expects this to continue for “years to come.”

Specifically, software that uses older, unsafe versions of Log4j are at risk. And, even organizations that have upgraded to safe versions of the library should be mindful of inadvertently pulling in older, vulnerable versions.

“All organizations should have capabilities to discover and upgrade vulnerable software and the ability to sustain execution of these vulnerability management capabilities for the long term,” the report reads.

The CSRB also includes a variety of guidance related to information sharing, most of which is directed toward CISA (Cybersecurity and Infrastructure Security Agency). For example, the report recommends that CISA “expedite, to the greatest extent possible, its implementation of the landmark cyber incident reporting requirements Congress enacted in March 2022 through the Cyber Incident Reporting for Critical Infrastructure Act of 2022.” (CISA technically has 24 months to undergo “initial rulemaking activities,” but the CSRB wants to see those efforts move faster.)

Additionally, the report recommends that CISA conduct several activities to “expand its capability to develop, coordinate, and publish authoritative cyber risk information.” This recommendation stems from the difficulty many organizations experienced in getting up-to-date, accurate information in the immediate aftermath of Log4Shell.

What Organizations Can Do Today

  • Make sure you’re not currently using a vulnerable version of Log4j, and have a process in place to keep vulnerable versions out of your software moving forward. The best way to do this is to regularly scan in-house and third-party software for known vulnerabilities.
  • Also, work with your organization to build robust policies to ensure there is visibility into all software that is being used and that there are specific timelines to address vulnerabilities when they are found.

How FOSSA Can Help

Follow Best Practices for Vulnerability Management

The CSRB recommends organizations implement several tools and processes to accelerate the identification and mitigation of vulnerabilities. This includes investment in “capabilities that allow them to identify vulnerable systems and applications in their environments in a timely manner,” such as vulnerability scanning.

The report also recommends that organizations prioritize maintaining an accurate, up-to-date inventory of technology and application assets, such as a software bill of materials. Notably, the CSRB calls on several federal agencies to develop guidance on using these inventories more effectively.

“OMB, in coordination with the Office of the National Cyber Director (ONCD) and CISA, should, as the SBOM ecosystem matures, consider issuing guidance to agencies on effectively using these asset inventories and software metadata to improve detection and incident response during future vulnerability response activities,” the report reads.

Additionally, the CSRB calls on organizations to develop (and/or refine) vulnerability response and disclosure processes. This covers both code that an organization owns/writes as well as third-party dependencies. Specific recommendations include:

  • Have a plan for receiving and acting on vulnerability reports
  • Invest in software supply chain security, including tooling as well as coordination with supply chain partners
  • Measure (and strive for improvement in) the mean time to repair (MTTR) vulnerabilities

Finally, the CSRB highlights the importance of adhering to secure software development practices. Some of the guidance in this section is a bit broad, but it includes using source code scanning and IDE tools, along with communicating security risks to software users and establishing a comprehensive approach to code maintenance.

What Organizations Can Do Today

  • Evaluate your current infrastructure to make sure you can quickly identify and mitigate vulnerabilities in open source code. There is a tooling element to this — software composition analysis technologies are designed for open source vulnerability management — and a process piece. Consider implementing policies that include specific timelines and a defined process for addressing vulnerabilities.
  • Develop an SBOM plan. As a starting point, this should include a process for generating SBOMs (in human- and machine-readable formats like SPDX), and making sure they are updated (ideally automatically) after any changes.
  • Implement secure software development practices. This recommendation is obviously quite broad but can include activities like designing reproducible builds, validating checksums of the software you use, and reserving package name/namespace to guard against dependency confusion attacks.

How FOSSA Can Help

  • FOSSA's Vulnerability Management product scans your applications to detect vulnerabilities in open source code. FOSSA also makes it easy for users to quickly and easily mitigate vulnerabilities.
  • FOSSA earned the highest possible score for SBOM management in the most recent Forrester Wave. With FOSSA, users can generate customized SBOMs (pick and choose from a comprehensive list of data fields) in a variety of formats, including SPDX and CycloneDX.

Invest in a More Secure Software Ecosystem

Nearly all modern software applications include at least some open source. And, as Log4Shell showed, if a popular open source component is compromised, the effects are felt across industry and region. This is why the CSRB suggests organizations get more involved in ecosystem-wide security initiatives.

The report highlights several ways enterprises can do this. One is to participate in community-based security initiatives like OpenSSF, OWASP, and the Open Source Software Security Mobilization Plan. Another is to invest resources (financial and staff) to support specific open source projects, especially those that your organization relies on.

The CSRB also views software bill of materials as an important tool in facilitating a fast response to vulnerabilities. However, the report notes that “SBOMs that can catalog the components of software are promising possibilities, but at present are limited.” Even so, the publication does recommend that organizations create and distribute SBOMs with software products — and “be prepared to incorporate improvements in the tooling and processes as they become available to the industry.”

This section also includes a number of recommendations intended for federal agencies. They include:

  • Partnering with universities on curriculum development and integrating cybersecurity into computer science courses.
  • Exploring public-private partnerships to build an inventory of the most commonly used open source pages, including a framework for maintenance and metrics for tracking health.

What Organizations Can Do Today

  • Consider sponsorship and partnership opportunities with community-based security initiatives and specific nonprofits. In addition to supporting a more secure software ecosystem, these investments can build goodwill with the open source community and potential customers.
  • Invest in SBOMs. This includes the right SBOM tools that can support generation and import. As the CSRB report notes, organizations have experienced limitations using SBOMs to support vulnerability management. However, a new generation of tools and improved industry-wide awareness have made SBOMs an increasingly potent vulnerability management tool.

How FOSSA Can Help

  • FOSSA’s best-in-class software bill of materials generation solution helps a wide range of enterprises generate, maintain, and communicate SBOM data. Please contact our team for more information on getting started.

Increase Government Investment

While the first three recommendations in the CSRB’s report are relevant for both government agencies and private enterprises, the fourth is mainly directed toward the federal government. It includes several suggestions for public-private partnerships to strengthen software security, such as a Cyber Safety Reporting System (CSRS), which could be similar to NASA’s Aviation Safety Reporting System. The report also suggests the federal government launch a Software Security Risk Assessment Center of Excellence (SSRACE) to “develop, manage, and protect a central inventory of all software across federal agencies.”

Another recommendation, which may have more immediate implications for the private sector, is that the government require vendors to be more transparent about their software, including provenance and dependency information. This is an extension of the Biden Administration’s 2021 Executive Order on Improving America’s Cybersecurity, which requires organizations selling into the federal government to provide an SBOM with each product.

Finally, the CSRB recommends that the U.S. government’s National Academy of Sciences Cyber Resilience Forum study the incentives associated with secure software development. This includes incentives aimed at individual developers — i.e. a “trust rating” earned through contributions to software security, which could, in theory, “be a component of the software’s overall health rating.” The report also suggests that the Forum look at “legal, structural, and regulatory” incentives for organizations around secure development, including the possibility of software liability reform.

What Organizations Can Do Today

  • This section, like the ones preceding it, makes clear that the CSRB views SBOMs as a mission-critical part of software security. Prioritizing your SBOM program (with a focus on tooling and process) can help set organizations up for success.
  • Be mindful of package provenance. This includes specific actions like analyzing the who, what, and where of your open source. Does it originate from an adversarial country? Is it backed by a single maintainer/small group of maintainers or a large organization? Indicators like the OpenSSF Best Practices Badge show that projects are paying attention to security.
  • Additionally, FOSSA Risk Intelligence (a new add-on to our Vulnerability Management product) gives users signal on indicators of risky open source, such as stale and empty packages.

How FOSSA Can Help

  • Please contact our team for more information on getting started with FOSSA’s SBOM solution and/or our Risk Intelligence add-on.

CSRB Log4j Vulnerability Review: The Bottom Line

Many recommendations in the CSRB’s Log4j vulnerability review are intended for federal government agencies, but the report is relevant to private enterprises, too. And, there are concrete actions private sector organizations can take today to strengthen software security — and be better prepared for the next major vulnerability impacting open source software.

For more information on using FOSSA to implement the CSRB’s recommendations, please reach out to our team.