In an interconnected world facing growing cyber attacks, it’s critical to ensure that technology systems are resilient to keep people safe. For over 20 years, Google has pioneered a Secure by Design approach, meaning we embed security into every phase of the software development lifecycle — not just at the beginning or the end.

Earlier this year, we joined the U.S. Cybersecurity & Infrastructure Security Agency (CISA), and now over 200 of our industry peers, to sign the Secure by Design Pledge — a voluntary commitment to specific security goals. Today, we’re publishing our white paper “An Overview of Google’s Commitment to Secure by Design,” which covers how we’ve continued to deliver on the pledge’s seven goals. This post shares highlights of the paper in hopes of providing a helpful industry guide on how to start on Secure by Design, or make adjustments for better implementation.

Google’s approach to the 7 Secure by Design goals

1. Multi-Factor Authentication (MFA): Americans lost $12.5 billion to phishing and scams in 2023, making the need for protections like MFA critical. Google’s journey with MFA dates back to 2010, when we launched Google Authenticator and 2-Step Verification (2SV) for Google Workspace. Since then, we’ve steadily made progress through our work with FIDO Alliance, Advanced Protection Program (APP), security keys and auto-enrolling people in 2SV. More recently, we’ve been part of the push to passwordless sign-in with passkeys (a safer, easier alternative to passwords), which have been used to authenticate users more than 1 billion times.
2. Default passwords: Default passwords in software and hardware are easy for bad actors to find, which means they can lead to widespread unauthorized access. That’s why we treat discovered default passwords as vulnerabilities of their own, and have implemented measures across our products to mitigate this risk. We use a system that links our products to your Google Account, so devices do not rely on pre-configured passwords. So configuring products like a new Nest smart home device or Google Pixel phone requires you to log in with your Google Account. This is similar to how our software-based services are set up and accessed. For example, services like Workspace and Google Cloud are managed by organization administrators and the setup process does not involve default passwords.
3. Reducing entire classes of vulnerability: Our approach to designing secure software starts with our safe coding framework and secure development environment, helping us reduce entire classes of vulnerabilities. Google has a long history of addressing vulnerabilities at scale including cross-site scripting (XSS), SQL injection (SQLi), memory safety issues, and insecure use of cryptography. We’ve done this by evolving our methods and using approaches like Safe Coding.
4. Security patches: Vendors should seek to reduce the burden on end users by making it as easy as possible to apply software updates. Google prioritizes this approach and focuses on the uptake of our fixes, emphasizing quick deployment to lessen the chances of a bad actor exploiting flaws. ChromeOS is a great example, as it uses multiple layers of protection combined with automatic, seamless updates to keep it ransomware- and virus-free.
5. Vulnerability disclosure: Industry collaboration is key to finding and reporting bugs and vulnerabilities. Google has been a long-time proponent of transparency, which means we take proactive measures to find issues and welcome the help of the security industry for external reports. Our Vulnerability Disclosure Policy and Vulnerability Rewards Programs (VRP) have connected us to security researchers that have helped us to secure our products. Since we launched the VRP, we’ve distributed 18,500 rewards totaling nearly $59 million.
6. Common Vulnerabilities and Exposures (CVEs): CVEs are meant to help identify fixes that have not been applied by a customer or user. Google prioritizes issuing CVEs for products that require action to update. We also provide security bulletins for consumers and businesses on various products, including Android, Chrome Browser, ChromeOS and Google Cloud, detailing vulnerabilities and offering guidance on mitigation.
7. Evidence of intrusions: Just like physical security issues, people deserve to be informed about possible intrusions, without an overload of irrelevant information. We do this via warnings about the security of your Google Account, and by providing our Security Checkup for personalized recommendations and Security Alerts. For Cloud, we use audit logs to record and give visibility into activities within customers’ Google Cloud resources. Cloud Logging helps customers with the centralization and retention of logs starting at 30 days, with the option to extend. In Workspace, domain administrators can use the audit and investigation tool and Reports API to review user and administrator activity across products like Gmail, Drive, Docs and Chat. Enterprises can leverage Android Enterprise capabilities, such as Security Audit Logs and Network Event Logs, to look for evidence of intrusions.

We’ve dedicated years to incorporating Secure by Design at Google, but our work is not done, and we look forward to sharing more ways we’ll deliver on CISA’s pledge. Today’s whitepaper will be the first of a series of insights we’ll publish in the coming months. Securing our digital ecosystem is a team sport, so we also encourage industry partners, policymakers and security experts to join this important work. And you can learn more about how our products are built with safety from the start at Safer with Google.