Performing a SAST for a CASA Tier 2 Self Scan

Google has recently announced a new process for verifying the identity of its users, called CASA Tier 2. This process is designed to enhance the security and privacy of Google accounts, especially for those who use sensitive services such as Google Pay, Google Cloud, or Google Workspace. In this blog post, we will explain what CASA Tier 2 is, how it works, and what benefits it offers.

Introduction

Google’s APIs provide a variety of services and features that can enhance the functionality and user experience of your applications. However, they also expose sensitive data and resources that need to be protected from unauthorized or malicious access. For example, the Gmail API allows you to read, send, and modify emails. The Google Drive API allows you to create, edit, and share files. The Google Maps API allows you to display and interact with maps, but it also requires access to the user’s location and navigation data.

If you are a developer who uses Google APIs, you may have noticed that recently, some of them require a CASA process before you can access them. CASA stands for Cloud Access Security Assessment, and it is a tool that Google uses to verify the identity and security of the applications that request access to its APIs.

The CASA process includes a scan that checks if the application has any known vulnerabilities or malicious behavior that could compromise the user’s data or device. The CASA process is designed to protect both developers and users from potential security threats and privacy breaches. For developers, it helps them improve their application quality and security by providing feedback and recommendations on how to fix any issues detected by the scan. It also helps them build trust and reputation with users by demonstrating that their application meets Google’s standards and best practices. For users, it helps them make informed decisions about granting permission to applications by showing them clear and transparent information about what data and resources the application will access and how risky it is. It also helps them avoid phishing attacks and malware infections by preventing them from granting permission to fraudulent or harmful applications.

Performing a Tier 2 Self Scan Using an Open Source Tool

Google will send you a document informing you that they require your application to undergo a scan if you access certain API scopes that they deem as sensitive. You will be provided with a link to sign up on the App Defense Alliance portal. On this portal, you have the option to upload your source code, where a scan will be performed for you. This is the simplest method to get the scan done, but it also means trusting whoever is operating the portal and their partners with your intellectual property. I did contact them regarding this and their answers were not very convincing. Therefore, I opted to perform a self-scan using an open source tool, which is another one of the option the Google allows.

On the portal, select the option to Bypass the Fortify Scan and provide a reason such as “We appreciate your interest in security and offer to use the Fortify Scan tool. However, we have decided to conduct a self-scan on our code instead of sharing it with you. This is because our code contains sensitive and proprietary information that we need to protect from unauthorised access or use. We hope you understand our decision and respect our confidentiality.”. You should then have the option to upload the results from your self-scan.

One of the tools recommended is the FluidAttacks Free & Open Source CLI. At the time of writing, the documentation provided by both the App Defense Alliance and by FluidAttacks were out of date. I have listed the steps I used below to get it working.

To follow along with these instructions, ensure you have the latest production copy of your source code, and Docker installed on your system.

Create a folder on your system – I called mine FluidAttacks. Inside this folder, create a config.yaml file, as paste the following within it:

namespace: CASA
output:
  file_path: ./Fluid-Attacks-Results.csv
  format: CSV
working_dir: .
language: EN
sast:
  include:
    - .

Make a copy of your source code that you want to scan and paste it into the FluidAttacks folder – this is the same folder that you created the config.yaml file in. This can be a flat file hierarchy or contain nested folders.

Open a terminal window and run:

docker run –name CASA -v /your/local/dir:/src fluidattacks/cli:arch skims scan /src/config.yaml

• Replace /your/local/dir with the absolute path to your FluidAttacks folder.
• Replace arch with amd64 or arm64 depending on your system.

This will then look something like (On Windows):

docker run --name CASA -v C:\MzansiBytes\FluidAttacks:/src fluidattacks/cli:amd64 skims scan /src/config.yaml

When done, you will hopefully see this message in your console window:

[INFO] Summary: No vulnerabilities were found in your targets.

Open the FluidAttacks folder, and there will be a Fluid-Attacks-Results.csv file that you can upload to the portal. Make sure you first open it and ensure there are no vulnerabilities. If there are, first address them and re-run the scan.

I hope this helps as I was personally struggling with getting the scan to work due to the erroneous information provided by both the App Defense Alliance and FluidAttacks.