What is Static Application Security Testing?
Static Application Security Testing or SAST is a collection of techniques and algorithms to analyze source code and automatically find potential errors or poor coding issues. The idea is similar in spirit to compiler warnings (which can be useful for finding coding errors), but to take that idea a step further and find bugs that are traditionally found using run-time debugging techniques such as testing.
SAST, also commonly called "white-box" testing, looks at applications in non-runtime environments. It is the only proven method to cover the entire code base and identify all the vulnerable patterns. SAST is also considered as a way to automate the code review process.
The tasks solved by static code analysis software can be divided into 3 categories
- Detecting errors in programs, offer recommendations on code formatting.
- Static analyzers allow you to check if the source code corresponds to the industry code formatting standards.
- Metrics computation. Software metrics are a measure that lets you get a numerical value of some property of software or its specifications.
Our main focus at PeerXP is to enable automated SAST to identify Security Vulnerabilities in the codebase way before they make their way deeper into deployments.
What is SonarQube?
SonarQube collects and analyzes source code, measuring quality and providing reports for your projects. It combines static and dynamic analysis tools and enables quality to be measured continuously over time. Everything that affects your codebase, from minor styling details to critical design errors, is inspected and evaluated by SonarQube, thereby enabling developers to access and track code analysis data ranging from styling errors, potential bugs, and code defects to design inefficiencies, code duplication, lack of test coverage, and excess complexity.
The Sonar platform analyzes source code from different aspects and hence it drills down to your code layer by layer, moving from the module level down to the class level. At each level, SonarQube produces metric values and statistics, revealing problematic areas in the source that require inspection or improvement.
Sonar covers the 7 sections of code quality,
- Architecture and Design
- Test coverage
- Duplicated code
- Potential bugs
- Code complexity
- Coding standards
SonarQube receives files as input and analyzes them along with barriers. Then calculates a set of metrics, stores them in a database and shows them on a dashboard. This recursive implementation helps in the analysis of code quality and how code improves over time.
Multiple languages analysis in the same project is also supported.
How does automated PWSLab SAST with SonarQube work?
1. SonarScanner - PWSLab uses a carefully architected Docker image of SonarScanner which is a separate client type application that in connection with the SonarQube server will run project analysis and then send the results to the SonarQube server to process it. SonarScanner can handle most programming languages supported by SonarQube except C# and VB.
2. SonarQube - PWSLab sets up a custom installation of the SonarQube Application server in a VM/Server where the results sent by SonarScanner in PWSLab are stored, processed and reports are generated.
Generally, PWSLab SAST is configured with a manual trigger in the project's CI/CD pipeline. Each commit is analyzed by SonarScanner against several industry-grade algorithms and techniques. All of this data, during the end of the SAST job, is sent to the SonarQube application server by PWSLab.
This process depending on the size of code may take several minutes to a few hours, as the Scanner has to crawl all lines of code incrementally.
How to verify reports generated by PWSLab SAST?
As mentioned above, the SonarQube Application in a separate server generates reports based on SonarScanner data. These reports include Code Quality, Potential Bugs, Code Complexity, Code Coverage, and several others.
Every time a job is triggered by PWSLab to run SonarScanner analysis, the analysis data is sent to SonarQube with the Commit-ID SHA as a version of the analysis. Authenticated users of the SonarQube project can then access the issues and reports generated to investigate further.
PWSLab users can authenticate with the SonarQube application using the GitLab authentication plugin or have separate standard accounts in SonarQube itself. All authenticated users of SonarQube application server who have access to the Sonar project can view the analysis reports.
For PWSLab SAST configuration in your PWSLab project's pipeline, please raise a DevSecOps Support Request.
Support Ticket Guidelines and Information Required
PWSLab Job Environment Variables:
Set SonarQube Project Key
Set SonarQube HOST URL
Set AWS Access Key in which the SonarQube Server is configured
Set AWS Secret Key in which the SonarQube Server is configured
Set AWS Instance ID in which the SonarQube Server is configured
Set AWS Region in which the SonarQube Server is configured
If SonarQube server is configured in AWS, then set this variable as true to automatically turn the instance ON and OFF.
Set this variable true to disable Sonar SAST job.
Please raise a DEVSECOPS Support Request in the PDS Department providing the below information:
- What is the primary language stack of your project?
- Do you want this job to run every time a code-commit is pushed?
- Do you want this job to run for a specific branch like UAT after merge requests are accepted by maintainers? So, before anything is merged to MASTER, it is tested by SonarQube.
- Linux Server is required to install and setup SonarQube Application server and PostgreSQL production DB to store analysis data -
- Sever Auth Credentials like HOST/IP and PEM key with a minimum of 4 GB RAM and 50 GB Hard-drive along with Ubuntu 18.04 LTS OS.
- This server can be configured to run as and when required on-demand basis when the SAST job is triggered.
Also, let us know if the article is helpful!