Cyberattacks on applications are on the rise, and zero-day vulnerability exploitation is leading the way. Introducing SAST into the development process makes the product safer for users. However, for many people, such a path to a secure future may seem confusing.
SAST (Static Application Security Testing) is a method of analyzing application security by checking source code. During the analysis, the SAST tool (a static analyzer) detects code fragments that contain potential vulnerabilities. The main advantage of this method is that developers can use it in the early development stages, and suspicious fragments can be detected even in rarely used code fragments.
The number of information security incidents increases every year. According to a report by Positive Technologies, there were 807 cyberattacks in the third quarter of 2023, which is 4.3% more than in the third quarter of the year before. Vulnerability exploitation attacks ranked third among all attack methods. No wonder that many organizations today are faced with the need to build a Secure Software Development Life Cycle (SSDLC). Incidents often involve vulnerabilities in application code. Most of the issues occur early in development, right at the code-writing stage.
SAST solutions are designed to help developers and security specialists find vulnerabilities in source code. SAST also bridges the gap between security and development, making developers more accountable for their product. For SSDLC, the use of SAST tools has been reinforced at the development stage.
Today, IDEs can also detect security flaws, but their analysis isn't deep enough. IDEs can't help you find XSS and SQL injection vulnerabilities. This is where static analyzers come in: the interprocedural analysis of data flow enables you to track data changes between multiple functions, which helps detect potential injections. So, IDE warnings alone are no longer enough. Developers also need to use SAST tools when developing an application.
Despite the necessity of using SAST, some myths and doubts circulate among executives and developers. We'd like to discuss some of them.
Unfortunately, some people don't see the benefit of using SAST regularly. Developers or security specialists run a code analysis of the product, write out some bugs or fix them immediately, and forget about the SAST tool until the next security audit. If there are no useful warnings in the report, a team may decide that it's not worth implementing SAST in the project that has been checked once.
One-time static analyzer checks of actively developing projects may not be informative because most serious vulnerabilities may have already been fixed through testing, code review, and other methods. The advantage of using SAST is that it detects errors early, right at the code-writing stage. However, to make it possible, use it regularly.
When developers analyze a legacy project for the first time, they may get hundreds or even thousands of different warnings. It will take weeks to fix them. Prior to checking, an application may have been stable, there may have been no security-related issues, or they may have been quickly fixed. Now, a developer sees a multipage report with unknown acronyms on the screen: CWE, OWASP, and others.
Of course, there's no point in rushing to fix all the warnings right away. They may not all be serious bugs or vulnerabilities. Typically, modern static analyzers filter warnings by category: from the most critical errors to minor enhancements, from performance issues to potential vulnerabilities. Critical warnings may be exactly what you need to pay attention to first.
In fact, you can eliminate most false positives by properly configuring the SAST solution. This will significantly reduce the percentage of false positives. However, it won't relieve you of the need to continue fixing detected issues. If you want to learn how not to demotivate developers when they start using SAST, you can read our article: "How to introduce a static code analyzer in a legacy project and not to discourage the team".
SAST tools may seem difficult to configure. While some think that static analyzer is a simple tool, others may postpone its introduction because they find it too complicated and confusing.
For an average developer, configuring SAST isn't difficult. Just install the analyzer first, register a license if necessary, and run your project build. Many SAST solutions support incremental analysis, so the application code is checked as soon as it's built. Typically, the tools come with the extensive developer documentation and provide technical support that you can contact at any time. So, there should be no serious configuration issues.
Everything is simple and easy. However, the fear of a first-time run can cause a company to lose something as useful as SAST is.
Another problem that can arise when introducing SAST is choosing a good tool. So, how do you choose the right one for your project when there are so many different solutions on the market?
When choosing a static analyzer, first consider the programming languages that are used in the project and the platforms on which the project is developed. Today, analyzers are available for almost all programming languages and platforms, and the tools have plugins for the most popular IDEs. The SAST market is also quite large, so don't settle for just one option. Compare multiple analyzers and choose the one that best suits your project.
Since SAST solutions are designed to detect vulnerabilities in source code, we recommend checking whether a tool meets the requirements of secure development standards and can search for vulnerabilities included in relevant databases and the CWE, OWASP ASVS lists of potential vulnerabilities.
When we talk about introducing SAST into the development process, we can't help but mention CI/CD. The third thing to consider when choosing a static analyzer is integration with CI/CD systems. It's important to consider not only whether the tool is easy to configure, but also the variety of report formats and whether it is easy to view them.
It's worth paying attention to the usability of the SAST tool in general, as the analyzer is designed not to interfere with product development but to help with code review and vulnerability detection. A good tool should highlight erroneous code fragments, point to the right file and line in the report, and have the capability to quickly suppress false positives.
When researching the SAST market, start by studying and comparing popular analyzers. Such tools should be capable of performing deep analysis, they should be easy to use, and they should detect most of the potential vulnerabilities. Let's take a look at the PVS-Studio SAST solution as an example.
PVS-Studio is a static code analyzer designed to detect errors and potential vulnerabilities in the C, C++, C#, and Java code. The analyzer supports Windows, Linux, and macOS operating systems. The tool can be integrated into the most popular CI/CD systems.
As a SAST solution, PVS-Studio supports the detection of potential CWE vulnerabilities and monitors whether an application complies with secure development standards such as OWASP ASVS and SEI CERT Coding Standards. If your product has safety requirements, PVS-Studio can check whether the code complies with the MISRA C, MISRA C++, and AUTOSAR C++14 Coding Guidelines.
If your project is written in C#, you can use PVS-Studio as an SCA solution: the analyzer can detect vulnerabilities in the components used.
You can get the PVS-Studio free trial for 7 days. Just download the analyzer at this link.
What makes PVS-Studio so handy for regular use? For easier integration into development processes, PVS-Studio provides a mechanism for suppressing warnings. You can use it for baselining analysis results, which is useful for both regular checks and introduction into a legacy project. The suppression mechanism is based on the use of special suppress files that store warnings marked as "unnecessary" for the project being checked. You can suppress messages directly in the plugin. Just highlight them in the analyzer report.
Another useful PVS-Studio feature is the blame-notifier utility, which is designed to automate email notifications to developers for whose code the analyzer has issued warnings. The report can be sent either to each developer in charge of the code on which the analyzer has issued warnings, or to a team leader – specifying developers, warnings, and erroneous code fragments.
Let's sum it up: using SAST solutions is a must in the modern software development process. More and more companies are choosing to build web applications, and among all the security incidents, web service attacks aren't the rarest. To minimize reputational and financial risks, address your product security by aligning SSDLC and DevSecOps and consistently implementing SAST into your development process.
However, don't treat static analyzers as a magic bullet for all issues and vulnerabilities. SAST tools aren't perfect and probably never will be. Their primary purpose is to help you spot suspicious code fragments, but not every suspicious fragment may be a defect. However, this doesn't mean that using SAST is pointless. Most vulnerabilities can be the result of developers' carelessness. You can avoid such issues by using a tool like a static analyzer.
Viktoria Pelipenko is a user support specialist and C# programmer in the internal development department at PVS-Studio. She helps people introduce the SAST tool into their development processes and uses the analyzer in her own development work. Viktoria is interested in information security and is passionate about building secure systems.