Tag Archives: vulnerability

Making security easy: How we are helping you fix vulnerabilities in your Android apps

Posted by Bessie Jiang – Software Engineer and Chris Schneider – Security Engineer

Contributors: Maciej Szawłowski – Security Engineer, Hannah Barnes – Technical Program Manager, Dirk Göhmann – Technical Writer, Patrick Mutchler – Software Engineer

Security is tricky, but vital to protecting your users and their data. We’re here to help you build secure Android apps with fewer vulnerabilities for an even safer Android ecosystem for everybody.

Vulnerability Detection – How it Works

Google currently scans every app on Google Play for dozens of common security vulnerability classes. If we spot something, we let you know so you can fix the problem. Imagine a pentesting team hunting for bugs in each of the millions of apps published on Play, rooting out issues like bad TLS configurations that expose network traffic or directory traversal vulnerabilities that let adversaries read from or write to an app’s private files.

We are committed to keeping our joint users protected. In serious cases, if a security vulnerability doesn't get fixed, Google may remove the app from Google Play to keep users safe.

Android Application Security Knowledge Base

We know that it isn’t always enough to just tell you about a vulnerability in your app; you need to know how to fix the issue and how to prevent similar issues from cropping up in the future. To this end, we are introducing our security guidance and recommendations under a new program: the Android Application Security Knowledge Base (AAKB).

AAKB aims to establish guidelines for writing secure Android software. It is a repository of common code issues, with remediation examples and explanations for implementing specific code patterns. Organic in nature, new issues are identified automatically for review with experts across the industry – ensuring broad but well-tested approaches and guidance.

Data collected from your engagement with AAKB is used to improve guidance, and to identify how to make the Android ecosystem more secure by default.

How Does it Work?

AAKB establishes clear, vetted guidance with code examples. Guidance is aligned to OWASP MASVS standards, and content is vetted in partnership with technical peers, such as Microsoft. This helps ensure the content is not biased to one party and represents state-of-the-art standards. This also provides an educational place for you to proactively remediate security risks in your applications using industry-wide standards, with direct access to knowledge from subject-matter experts.

The guidance is available through two mechanisms:

The AAKB homepage lists each article independently, aligned to the relevant OWASP MASVS category (e.g. MASVS-STORAGE). Anyone can view or provide direct feedback to this content. Security is an ever-changing field, and being able to update guidance on the fly means software development lifecycles can be updated dynamically with as little friction as possible.

Android Studio triggers remediation guidance from lint checks by pointing directly to AAKB articles. You can fix problems as you're building the app and before they ever reach users.

There are two methods to view remediation guidance with Android Studio:

Existing security lint checks within Android Studio Giraffe+ have had their descriptions updated to include a link to the relevant AAKB article, allowing you get more context as to why a particular code snippet might be potentially “at-risk”.

Example of a finding with a link to a relevant AAKB article in the Android Studio IDE
Figure 1. Example of a finding with a link to a relevant AAKB article in the Android Studio IDE

Meanwhile, the open-source Android Security lint checks give you access to our most recent guidance and experiments to further protect your mobile applications and get ahead of future security concerns.

Add the open source checks to your project by following the README. These lint checks all contain click-to-fix functionality that make it easy for you to write safer code with minimal effort, as well as links to the relevant AAKB articles like the built-in IDE checks.

Example of an open-source security lint finding, highlighting a vulnerable code snippet and click-to-fix solution
Figure 2. Example of an open-source security lint finding, highlighting a vulnerable code snippet and click-to-fix solution

All built-in IDE lint checks can be found in this list, with many under the Security category containing links to relevant AAKB articles. We would love to hear your feedback and suggestions for new lint checks and other improvements to the open-source lint library.

A new resource for coordinated vulnerability disclosure in open source projects

One of the joys of open source is the freedom it gives you to create: contributors get to build the projects they want how they want; it’s up to them. Of course, blank slates don’t come with directions, which makes more niche areas of software development and management a challenge for contributors. Vulnerability disclosure is one of those areas.

Google doesn’t restrict its open source work to one team, instead we teach any and all Googlers about open source: how to release, how to contribute, how to use, and, in general, how to be a good open source citizen. This approach scales well, and gives people the knowledge to be lifelong open source community members. This includes sharing knowledge about open source security, a topic that isn’t new, but is finally getting the industry attention it deserves.

The intimidating blank slate and a lack of time for contributors to develop policies means many open source projects have no documented vulnerability reporting information, much less a plan for how to handle and disclose a reported vulnerability. We recently updated our guidance for coordinated vulnerability disclosure in open source projects that come out of Google and have published it in hopes that other projects will find this helpful for their project security practices.

The new guide has three sections:
It’s a myth that if a project hasn’t received a vulnerability report yet, it doesn’t need a disclosure policy. It’s also a myth that you need to be “a security person” to implement a vulnerability disclosure policy. A successful coordinated vulnerability disclosure frequently comes down to good process management and clear, thoughtful communication. You don’t have to be an expert in operating systems capabilities to understand how a reporter manipulated it to cause an account privilege escalation through your project. A predetermined policy, some templates, and a well-executed runbook will take you through discovering, patching, and disclosing most kinds of vulnerabilities.

Coordinated Vulnerability Disclosure in Open Source Projects

Vulnerability disclosure is part of Fix in the Know, Prevent, Fix framework we proposed recently for open source vulnerability management. In today’s industry, with all of our supply chain dependencies, improving open source project security in even one project can have a multiplying effect. Vulnerability disclosure is a key aspect of that overall security posture. Our hope is that projects will take this guide, remix and adapt to their projects, and share their changes with others so we can collectively increase our open source security.

By Anne Bertucio, Google Open Source