Google CASA Process

There are three key steps that developers need to follow:

1. Validate that the application language is supported (see the “Preparing applications to be

scanned > Supported languages” section below)

2. Package your application code correctly so that it can be processed by Fortify SCA (see the

entire “Preparing applications to be scanned” section below)

3. Upload your packaged application code to the CASA portal (see the “Uploading packaged code

to CASA portal” section below)

Terminology

This document may refer to several OpenText Fortify modules and technologies. The table below

provides a brief overview:

● Application: An application is a codebase. It serves as a top-level container for one or more

versions.

● Application Version (AV): A version is an iteration or branch of a codebase. A version is a

container for the application’s vulnerabilities.

● CI/CD: Continuous Integration tool as in ADO, GitLab, Github, or Jenkins.

● FPR: Fortify Project Result: SCA stores the software security issues it finds in an FPR file.

● SAST: Static application security testing is a set of technologies designed to analyze application

source code, byte code and binaries for coding and design conditions that are indicative of

security vulnerabilities. SAST solutions analyze an application from the “inside out” in a non-

running state.

● SCA: Static Code Analysis: This is OpenText Fortify’s product, which is used for SAST.

● ScanCentral SAST Controller: Accepts the scan requests and packages and distributes them to

the SCA Sensors.

● SCA Sensors: The heart of Fortify SAST analysis. These are the workers that will translate and

scan your code and send the FPRs to the ScanCentral Controller to send to SSC.

● SSC: Software Security Center is the vulnerability repository for Fortify products. SSC provides a

“single pane of glass” to view all of the vulnerabilities from SCA, WebInspect, and Sonatype. SSC

allows users to see vulnerabilities in AV that they have access to. Users can view and triage

vulnerabilities, find recommendations on remediation, create reports on findings, and assign

vulnerabilities to users. There are also attachments to link AV to Jira, ALM or other bugtrackers

that development uses.

Preparing applications to be scanned

For an application to be scanned, it first has to be built (Java, .NET) and then packaged. Packaging an

application is language and build tool based. Below is the list of supported languages and what is

needed to run a scan.

Developers must use the ScanCentral Client to package their code. Developers will load the .zip to the

CASA portal, which will forward the .zip to Fortify Hosted to run the scan.

Supported languages

● .NET applications in C# and Visual Basic (VB.NET) (.NET Core, .NET Standard, ASP.NET)

(Windows only for now)

● ABAP

● ActionScript*

● Apex

● Classic ASP

● ColdFusion

● Dockerfiles

● Go

● HTML*

● Java

● JavaScript

● Kotlin

● PHP

● PL/SQL

● Python

● Ruby

● T-SQL

● TypeScript

● Visual Basic 6.0

*Languages that are not officially supported by Fortify but that are likely to work nonetheless

If your application is written in a language that is not listed above, it will not be possible to assess it via

the inline Fortify scanning workflow. You will need to select the “Request To Bypass Fortify Scan” option

in the CASA portal to assess the application.