Building on this momentum, today we are going to share Google’s approach to address the log4j report’s recommendations. We see this as an important part of our effort to support others in the industry as we all work together to increase open source security. This includes:

1. Driving adoption of best practices;
2. Building a better software ecosystem; and
3. Making long term investments in digital security.

Together, these efforts demonstrate the steps we take to protect others and reflect our broader commitment to improve security for everyone.

We welcome the U.S. Government’s work to improve the nation’s cybersecurity, including through establishment of the CSRB to review incidents like log4j.

Report recommendation: Drive existing best practices for security hygiene

Google will continue to make security a cornerstone of our product strategy and we commit to share our internal frameworks and best practices with others. We partner closely with industry stakeholders to identify and address vulnerabilities in the ecosystem, and share best practices on how to address the latest security threats. We hope that sharing this information will spark industry-wide discussion and progress on the security and sustainability of the open source ecosystem.

For example, Google contributed heavily to Open Source Security Foundation’s (OpenSSF) guide on coordinated vulnerability disclosure (CVD) for open source projects. The guide was based in part on Google’s prior CVD publication and suggests a process for publicly disclosing vulnerabilities, and includes commonly-needed policy and communication templates, such as embargo notifications and disclosure announcements.

In addition, in partnership with OpenSSF, Google helped establish Security Scorecards for Open Source—an effort to automate evaluation of security best practices for critical open source projects. We’ve made this data public for 1 million critical open source projects across various software languages. This work also aligns with existing Secure Software Development Framework (SSDF) requirements.

Report recommendation: Build a better software ecosystem

For almost two decades, Google has been an industry leader in building better software and driving open source innovation across the ecosystem. Open source contributors at Google work on a variety of projects and repositories—not just our own code. We sponsor, create, and invest in projects and programs that enable everyone to join and contribute to the global open source ecosystem. We will continue to make open source security a priority and urge others to do the same, because the health and availability of open source projects strengthens the security posture of users and developers everywhere.

For example, in 2021, we launched Open Source Insights, a tool designed to list and visualize a project’s dependencies and their properties. When log4j broke in late December 2021, the Open Source insights team reported that over 35,000 Java packages were impacted by the vulnerability and compiled a list of 500 affected packages to help guide patching and remediation activities.

Still, there is more to do. As of this week, the team reported that only 40% of the affected packages have remediated the problem. To support enterprise and public sector customers, we’ve also launched Assured Open Source Software service to help them reduce their need to develop, maintain, and operate complex processes to secure their open source dependencies.

However, we continue to point out that truly moving the industry forward requires embedding controls throughout the build process. Software Bill of Materials (SBOMs) are helpful in providing a point-in-time view of software composition, but it does not address the full scope of risks in the supply chain. That’s why we worked with OpenSSF to publish the Supply Chain Levels for Software Artifacts (SLSA) framework, an end-to-end framework for ensuring the integrity of software artifacts throughout the software supply chain. SLSA is inspired by similar Google internal processes that have been used for a decade to secure Google’s production workloads. With SLSA, users can make informed choices about the security posture of the software they consume. The SLSA framework provides guidelines and evidence for securing each step of the software production process so that the final SBOM attached to a package can be considered credible.

More broadly, Google has a dedicated team of full-time engineers focused on creating innovative security solutions to improve open source security. In partnership with OpenSSF, for example, we’ve founded projects like Sigstore for code artifact signing and verification, a vulnerability schema for automating vulnerability triage, and OSS-Fuzz community fuzzing service, among others. We’re also expanding this work to create a new Open Source Maintenance Crew to engage upstream full time across critical open source projects.

Report recommendation: Investments in the future

As the report points out, our work on log4j continues. We applaud the Board’s recognition that public and private sector stakeholders need to make significant investments for the future to improve the nation’s digital security over the long term. At Google, we are committed to doing our part. For example, last year, we announced that we will invest $10 billion over the next five years to strengthen cybersecurity, including helping secure the software supply chain and enhancing open-source security. This includes $100 million to support third-party foundations like OpenSSF that manage open source security priorities and help fix vulnerabilities.

We’ve also started the OpenSSF Alpha-Omega and SOS projects to improve the security posture of critical open source projects via directed funding efforts. This includes funding to hire security professionals, conduct security audits for critical projects, and provide assistance for incorporating security tools as part of a secure software development lifecycle. Google has spent $7.5 million in various open source security efforts in the last year.

We welcome the chance to participate in future review board processes, and look forward to working alongside others to continue to protect the nation’s software supply chain ecosystem. It’s clear that public and private sector stakeholders learned a great deal from log4j and the report provides an in-depth review of shared challenges and potential solutions. Now, we must act on those learnings to improve the security of the entire ecosystem.