Sastisfying App Security

An introduction to SAST

solution Sastisfying App Security

SAST (Static Application Security Testing) is a type of white box test in which a set of technologies is used to analyze the source code, byte code or the application binaries in order to reveal known security vulnerabilities that can be exploited by malicious users.

A Bit of History

In his 1976 paper, Design and Code Inspections to Reduce Errors in Program Development, Michael E. Fagan explains how to do a code review and, thus, creates the world’s first code review process. Fagan inspection is a formal execution process involving several phases and participants, and also defines entry and exit criteria to both start and end the process.

Fagan Flow via

Figure 1. Fagan Flow via

In 1992, in his article Experience with Fagan’s Inspection Method, E.P. Doolan proposes using software that keeps a database of detected errors and automatically scans the code for them. This begins the use of automated tools.

Software Development Life Cycle (SDLC)

SDLC is a series of stages that must be followed for the development of a specific software product. These stages ensure that the quality, functionality, and objectives of the application meet customer expectations and development standards.

Software development Life Cycle phases via

Figure 2. Software Development Life Cycle stages via

During the SDLC it is important to use testing methodologies in the early stages of development that identify and resolve security vulnerabilities quickly, before the application’s release. These vulnerabilities can be found on the following websites:

OWASP Top Ten Project via

Figure 3. OWASP Top Ten Project via

By applying SAST we can detect and avoid most of the security vulnerabilities listed in the previous links' pages.

How does SAST work?

SAST can be applied manually or through the use of automated tools.

Manual testing is done by a team of testers responsible for reviewing the code for known security vulnerabilities. Once vulnerabilities are found, they are reported to the development team to be solved. Manual testing includes several stages including:

  1. Synchronization: This stage includes receiving from the developers the application, a complete explanation of what the application does, and how the application does it.

  2. Review: In this stage, the testing team takes the source code and analyzes each line, method, class, and file for security vulnerabilities.

  3. Reporting: At this stage, false positives and irrelevant information are eliminated, finding reports are created and delivered to project leaders responsible for communicating with developers, who then mitigate or patch the vulnerabilities.

Report of finding in manually test via

Figure 4. Report of finding in manually test via

Automated tools: There are many tools that allow us to automatically perform code analysis and provide reports of the vulnerabilities discovered during the scanning process. Because these tools are more flexible, they can be integrated with development environments that include Waterfall scenarios, Continuous Integration (CI/CD) environments, Agile/DevOps, source repositories, and even with other testing tools.

Get started with Fluid Attacks' Secure Code Review solution right now

These types of tools use sophisticated functions such as data flow analysis, control flow analysis, and pattern recognition to identify potential security vulnerabilities. The result is that vulnerabilities are reported sooner, especially in complex projects or projects with too many lines of code.

Report of findings in automated tests via

Figure 5. Report of findings in automated tests via

Reports are always checked by employees because automated tools tend to generate a large number of false positives and need to be filtered to extract the potential risks of an application.

As says:

There are six simple steps needed to perform SAST efficiently in firms which have a very large number of applications built on different languages, frameworks, and platforms."

  1. Finalize the tool: "Select a static analysis tool that can perform code reviews of applications written in the programming languages you use."

  2. Create the scanning infrastructure and deploy the tool: "This step involves handling the licensing requirements, setting up access control and authorization, and procuring the resources required (e.g., servers and databases) to deploy the tool."

  3. Customize the tool: "Fine-tune the tool to suit the needs of the organization. For example, you might configure it to reduce false positives or find additional security vulnerabilities by writing new rules or updating existing ones. Integrate the tool into the build environment, create dashboards for tracking scan results, and build custom reports.

  4. Prioritize and onboard applications: "Once the tool is ready, onboard your applications. If you have a large number of applications, prioritize the high-risk applications to scan first. Eventually, all your applications should be onboarded and scanned regularly, with application scans synced with release cycles, daily or monthly builds, or code check-ins."

  5. Analyze scan results: "This step involves triaging the results of the scan to remove false positives. Once the set of issues is finalized, they should be tracked and provided to the deployment teams for proper and timely remediation."

  6. Provide governance and training: "Proper governance ensures that your development teams are employing the scanning tools properly. The software security touchpoints should be present within the SDLC. SAST should be incorporated as part of your application development and deployment process."


SAST can be applied in the early stages of the SDLC since it searches for vulnerabilities in the code before it is compiled. This ensures the least number of possible security vulnerabilities will make it into the application before it is released.

SAST can reduce money and time costs by finding and solving vulnerabilities in the early stages of the SDLC that could cost you much more to fix, if discovered, in the later stages.

SAST is flexible and can be adapted to any type of project.

SAST can be fully integrated with CI/CD, Agile and DevOps environments (DevSecOps).


It is important to know the security vulnerabilities to which applications are exposed. In order to do so, we must continuously read and inform ourselves via resources such as OWASP or CWE.

Security testing should always be performed on applications to ensure that they are able to maintain the confidentiality, integrity and availability of information.

Always perform continuous reviews of an application. Security tests should never be performed only once.

Using SAST helps programmers reinforce coding standards.



Subscribe to our blog

Sign up for Fluid Attacks’ weekly newsletter.

Recommended blog posts

You might be interested in the following related posts.

Photo by Pierre Bamin on Unsplash

Watch out for keylogging/keyloggers

Photo by Denis Tuksar on Unsplash

There's not an only way but here's a good one

Photo by Jelleke Vanooteghem on Unsplash

Benefits and risks of these increasingly used programs

Photo by Sven Mieke on Unsplash

A hacker's view of the performance of Researcher CNAs

Photo by Phil Hearing on Unsplash

Why so many are switching to Rust

Photo by Rohit Tandon on Unsplash

Description and critique of CEH certifications

Photo by Pramod Tiwari on Unsplash

An OffSec Experienced Pentester review

Photo by David Ramírez on Unsplash

Or what makes the ethical hacker

Start your 21-day free trial

Discover the benefits of our Continuous Hacking solution, which hundreds of organizations are already enjoying.

Start your 21-day free trial
Fluid Logo Footer

Hacking software for over 20 years

Fluid Attacks tests applications and other systems, covering all software development stages. Our team assists clients in quickly identifying and managing vulnerabilities to reduce the risk of incidents and deploy secure technology.

Copyright © 0 Fluid Attacks. We hack your software. All rights reserved.