Code and information security is becoming a bigger consideration as technology keeps evolving. The risk of security vulnerabilities or inadequate authentication controls leading to a data leak exposure, reputational damage, and financial penalties and fines is very real.
Too often, security scanning happens too late, if it all. This can lead to extensive rework as developers trace vulnerabilities back to source, identify dependencies across impacted code modules, and assess cost and time to remedy negative business impact.
To mitigate those risks, organizations need automated security scanning and compliance with security standards.
Several services, such as SonarQube, give you a way to monitor your code for vulnerabilities both while it is running and before it compiles. One major feature included in the upcoming FlexDeploy 6.0 release is the overhaul and enhancement of our scan integration with many industry-leading application scanning tools.
In this blog post, we will explore two main types of scanning tools and give an inside look at how we at Flexagon use scanning tools to make our code safer and more secure.
SAST vs DAST
To back up a little for the uninitiated, there are two main types of scans that can be done on an application: Static Application Security Testing (SAST) and Dynamic Application Security Testing (DAST). Both are very helpful for different reasons based on when the scans run in the development cycle.
SAST
SAST falls into the category of white box testing, which is where the testing suite has full access to the source code and the underlying framework behind the application. Being a white box test, SAST allows you to scan for vulnerabilities without the application being deployed and can find a wide spectrum of issues from simple software errors to possible SQL injection points. Finding issues this early in the software development cycle is typically easier and less expensive to fix. SAST scans are useful to discover a wide range of potential problems with your source code. However, since the application isn’t deployed while this scan is running, SAST scans aren’t very useful to discover runtime vulnerabilities.
DAST
DAST, on the other hand, falls into the category of black box testing. Black box testing is where the testing suite does not know the source code or framework of the application and is typically only able to control the application’s inputs. In contrast to SAST, DAST scans are done while the application is running, so they are perfect for monitoring runtime vulnerabilities or potential attacks. The issues DAST scans can uncover can be more severe and expensive to fix, but deploying unchecked vulnerabilities could lead to application interruption or data breaches. Having a complex DAST integration set up can give you a look into what a potential hacker could see or do with your application without having to be knowledgeable in every possible security risk out there as a developer.
6.0 Plugins and New Features
FlexDeploy offers plugins for many SAST and DAST tools. Our 6.0 release adds new functionality to some of our existing plugins in order to seamlessly integrate industry-leading scanning tools into your current CI/CD development process. This article will highlight FlexDeploy’s integration with SonarQube. For reference, below is a full listing of the supported plugins for code scanning:
| Plugin | SAST/DAST |
| JFrog Xray | SAST |
| Checkmarx | SAST |
| SonarQube | SAST |
| Acunetix | DAST |
| Anchore | DAST |
| Salesforce | SAST |
| ApexSec | SAST |
SonarQube Example
Information security is important to us at Flexagon, so we integrate SonarQube with our production instance of FlexDeploy to scan our source code for potential vulnerabilities and code errors. This allows us to spot errors well before a new version of FlexDeploy is released to you. This will provide a sneak peak of how scan integrations work and will show how useful they can be in practical, day-to-day operations.
Workflow Integration
There are a few ways to set up a SAST Scan Integration using build or utility workflows. At Flexagon, we currently use a utility Project to run a scheduled execution to consistently scan our source code. However, in this more conventional example, we’ll show a SonarQube scan integrated into a simple build workflow running on an example project.
SonarQube Scan
When a build executes, a scan of the source code will be triggered inside SonarQube.
FlexDeploy Scan Results
You can view the scan results in the SonarQube application or inside the execution in FlexDeploy itself on the “Scan Results” page. Here, you can filter the details of the scan results by severity or by the text content of the detail. For example below, I’ll filter by severity level to check the most important issues first. Then, I can use the text filter to focus on some of the issues I am interested in.
FlexDeploy Reports
You can view the scan results in a generated report found in the “Reports” tab of the execution. This will give a more in-depth insight into the results of the scan which can be used in a audit of an applications performance. You can download the report too so you can have a local copy as well as having the report on FlexDeploy.
Conclusion
I’ve showed you how helpful SAST and DAST scan integrations are for us at Flexagon. Scanning tools allow developers to catch code faults and weaknesses quickly, especially when integrated into a release pipeline. Integrating automated scanning tools into your software delivery process allows you to see results right way, stop errors early in your software development cycle, and mitigate human error. Be sure to check this integration out with the FlexDeploy 6.0 release in September.
