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.
Figure 1. Fagan Flow via secjuice.com
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.
Figure 2. Software Development Life Cycle stages via Synotive.com
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:
Figure 3. OWASP Top Ten Project via owasp.org
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:
-
Synchronization: This stage includes receiving from the developers the application, a complete explanation of what the application does, and how the application does it.
-
Review: In this stage, the testing team takes the source code and analyzes each line, method, class, and file for security vulnerabilities.
-
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.
Figure 4. Report of finding in manually test via Mitre.org
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.
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.
Figure 5. Report of findings in automated tests via Oreilly.com
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 Synopsys.com 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."
-
Finalize the tool: "Select a static analysis tool that can perform code reviews of applications written in the programming languages you use."
-
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."
-
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.
-
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."
-
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."
-
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."
Benefits
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).
Conclusions
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.
References
Share
Recommended blog posts
You might be interested in the following related posts.
