Instead of being reactive to vulnerabilities, we should eliminate them proactively with secure languages, platforms, and frameworks that stop entire classes of bugs.
Preventing problems before they leave the developer’s keyboard is safer and more cost effective than trying to fix vulnerabilities and their fallout. (Consider the enormous impact of the SolarWinds attack, which is predicted to take
.) Google promotes designs that are secure by default and impervious to simple errors that can lead to security vulnerabilities.
We want to see secure systems used as widely as possible, so we have invested in initiatives such as getting
.
Security Measures for Critical Software Critical software does not exist in a vacuum; we must also harden the broader systems and run environments. Our paper outlines a list of actionable steps for critical software's configuration, the privileges with which it runs, and the network(s) to which it is connected.
Our suggestions are based on practices that have withstood the tests of time and scale, such as in our Google Cloud Products, built on
one of the industry’s most trusted clouds.
Google contributes to open-source tools that help maintainers adopt these practices, such as
gVisor for sandboxing, and
GLOME for authentication and authorization. Additionally, to share the knowledge we have gained securing systems that serve billions of users, we released our book
Building Secure and Reliable Systems, a resource for any organization that wants to design systems that are fundamentally secure, reliable, and scalable.
Software Source Code TestingContinuous fuzzing is indispensable for identifying bugs and catching vulnerabilities before attackers do. We also suggest securing dependencies using automated tools such as
Scorecards,
Dependabot, and
OSV.
Google has made huge contributions to the field of fuzzing, and has found tens of thousands of bugs with tools like
libFuzzer and
ClusterFuzz.
We have made continuous fuzzing available to all developers through
OSS-Fuzz, and are
funding integration costs and
fuzzing internships. We are leading a shift in industry support: on top of
bug bounties, which are rewards programs for finding bugs, we have also added
patch rewards, money that can help fund maintainers remediate uncovered bugs.
Software Supply Chain Integrity Google strongly encourages adoption of
SLSA, an end-to-end framework for ensuring the integrity of software artifacts throughout the software supply chain. Four “SLSA Levels” provide incrementally adoptable guidelines that each raise the bar on security standards for open-source software.
SLSA is based on Google’s
internal framework Binary Authorization for Borg (BAB) that ensures that all software packages used by the company meet high integrity standards. Given BAB’s success, we have adapted the framework to work for systems beyond Google and released it as SLSA to help protect other organizations and platforms.
We have shared many of Google’s practices for security and reliability in our
Site Reliability Engineering book. Following our recent
introduction of SLSA to the wider public, we are looking forward to making improvements in response to community feedback.
Minimum Requirements for SBOMsGoogle submitted an additional paper in response to the NTIA’s
request for comments on creating SBOMs, which will give users information about a software package’s contents. Modern development requires different approaches than classic packaged software, which means SBOMs must also deal with intermediate artifacts like containers and library dependencies.
SBOMs need a reasonable signal-to-noise ratio: if they contain too much information, they won’t be useful, so we urge the NTIA to establish both minimum and maximum requirements on granularity and depth for specific use-cases. We also recommend considerations for the creation of trustworthy SBOMs, such as using verifiable data generation methods to capture metadata, and preparing for the automation and tooling technologies that will be key for widespread SBOM adoption.
Improving Everyone’s SecurityWe are committed to
helping advance collective cybersecurity. We also realize that too many guidelines and lists of best practices can become overwhelming, but any incremental changes in the right direction make a real difference. We encourage companies and maintainers to start evaluating today where they stand on the most important security postures, and to make improvements with the guidance of these papers in the areas of greatest risk. No single entity can fix the problems we all face in this area, but by being open about our practices and sharing our research and tools, we can all help raise the standards for our collective security.
Follow