PVS-Studio finds security defects and provides application security. Report by Forrester Research on SAST, Q3 2020
- Approaches to code safety and security
- Development of PVS-Studio as a SAST solution
- The future of SAST and safety directions in PVS-Studio
- Additional links
PVS-Studio, originally developed as a universal tool for finding errors in software code, is now gradually focusing on ensuring safety and security of applications, identifying potential zero-day vulnerabilities. This was facilitated by the support of CERT and MISRA standards, the classification of analyzer warnings in accordance with the CWE standard, the development of data flow analysis mechanisms for tainted data checking, and so on.
On August 6, 2020, Forrester Research released a study called "Now Tech: Static Application Security Testing, Q3 2020", which included the PVS-Studio analyzer as a SAST-specialized solution. Forrester is one of the leading researchers of the impact of new and innovative technologies on business processes and the market, so the inclusion of PVS-Studio in this study is a decent confirmation (both for our users and for us) of the relevance of this direction in which our product is developing. The research report is available for purchase to subscribers and customers of Forrester Research.
Approaches to code safety and security
There are various methodologies for improving code quality and reliability. From a security point of view, their task is to identify as many vulnerabilities as possible at the development/testing stage, so that attackers wouldn't be able to do the same and exploit the defects for their own purposes. We can't say that any methodology is the most important and useful, since they all complement each other.
Such methodologies include:
- Improving the culture of writing code in general. What is meant here is the use of coding standards, implementing code reviews in the development process, and so on.
- DAST (Dynamic application security testing). Dynamic analysis tools allow you to identify vulnerabilities in code, such as SQL injections, buffer overflow, and the like. Disadvantage: the need to run applications on a large number of different tests and the necessity to spend large amounts of time. Advantages: almost total absence of false positives, or the need to have access to the code of applications. An approach that also requires access to the source code is called IAST (Interactive Application Security Testing).
- SAST (Static application security testing). A type of static code analysis focused on finding existing and potential vulnerabilities. It can reveal a large number of defects, including even those that haven't revealed themselves yet. Disadvantages: analyzers emit false positives and require the presence of the source code of the program. Advantages: no need to run tested applications, high speed.
- RASP (Runtime application self-protection). Runtime application self-protection is one of the security tools that is used when running a program. RASP analyzes the behavior of an application and thus provides continuous security analysis.
- Other methods or varieties of the above ones.
These methodologies are organically integrated into the development process, and we can say that their implementation turns DevOps into DevSecOps.
In this article, we will focus more on SAST, which in turn is divided into two major directions.
First direction: search for known vulnerabilities
The first type of analyzers work on the principle of antivirus. They know how code fragments containing known vulnerabilities (CVE) look like. They search for these fragments in the code of projects being checked. In practice, everything is a little more complicated, but the general idea is very similar to this one.
The analyzers of this type will help you detect, for example, that your code uses an old version of the library that contains a known and long-found vulnerability. Tools that search the database almost do not emit false positives, but they are powerless when it comes to finding errors in new code (zero-day vulnerabilities).
Second direction: search for zero-day vulnerabilities
The application may contain an error that will remain unnoticed for some time. If a hacker finds such an error and comes up with a way to exploit it, it will turn into a new vulnerability. Such a dangerous identified defect is called "zero-day vulnerability". The term itself means that developers had 0 days to fix the defect.
The analyzers of this type help detect errors that can potentially cause a vulnerability. A large number of such error patterns are collected in CWE and many analyzer developers rely on this database.
Static analyzers are usually not able to understand whether an error can turn into a vulnerability or not, but this is not necessary. Let's say the analyzer detects an array index out of bounds. If the person investigating the analyzer report is not an attacker, but a project developer, then it doesn't make sense for them to figure out whether this error is a security threat or not. They just need to fix this error. By fixing the error, the developer could have eliminated a vulnerability. On the other hand, this may just be an error that causes the app to work incorrectly. In any case, it is useful to find and fix the error.
PVS-Studio is one of the tools that implement the second direction of security defect detection, and now we will look at it in more detail.
Development of PVS-Studio as a SAST solution
Initially, PVS-Studio was developed as a classic static code analyzer. It allows you to find a wide range of errors in the code of programs written in C, C++, C#, and Java. You can check out various articles about checking open projects using it in order to evaluate its diagnostic capabilities.
Over time, it became clear that much of what the PVS-Studio analyzer can do is nothing more than code security testing. In other words, the analyzer is good at finding potential vulnerabilities (see examples).
It should be understood that the reason for most vulnerabilities is not some complex problems in the security system, but ordinary software errors in the code.
The National Institute of Standards and Technology (NIST) reports that 64% of software vulnerabilities stem from programming errors and not a lack of security features.
Security errors are all the same familiar classic errors, such as an array index out of bounds, incorrect conditions, typos, and so on. That's just the negative consequences of such errors in some cases that are much more noticeable and expensive.
PVS-Studio has already been able to find a large number of these errors, and its use allows you to make the program code more reliable and secure. However, this does not mean that our team just assigned the word SAST to PVS-Studio and that's it :).
Earlier in the article, we mentioned Common Weakness Enumeration (CWE). We studied this resource and took examples of errors that PVS-Studio was not able to detect yet. Over time, when developing new diagnostic rules, we began to increase the number of rules that can be classified as potential vulnerabilities. In addition, for the convenience of users, we have mapped the messages generated by the analyzer according to the CWE classification. Now you can enable displaying CWE IDs in the analyzer.
To enhance the capabilities of PVS-Studio, our team also paid attention to the SEI CERT Coding Standard. It is a set of standards for writing software in C, C++, Java, and Perl, developed by the CERT (CERT Coordination Center, CERT/CC) to improve software reliability and security. See the PVS-Studio warning classification table according to the SEI CERT Coding Standard.
Another area of work is support for the MISRA C and MISRA C++ standards. These standards do not directly relate to vulnerabilities. CWE and CERT standards can be called by the common word "security", whereas MISRA standards relate to the "safety" category. The purpose of MISRA standards is to improve safety, portability and reliability of programs for embedded systems. In any case, the MISRA standard is often mentioned in the context of SAST or as a related topic. Mapping table.
Having done all this work, we can now honestly say that the PVS-Studio tool is a SAST solution and its regular use will help prevent many zero-day vulnerabilities in your code.
The future of SAST and safety directions in PVS-Studio
As we already mentioned at the beginning of the article, we see the inclusion of PVS-Studio in the Forester Research report as a good indicator of the correctness of the chosen direction of development. Of course, while developing the analyzer's SAST capabilities, we didn't forget about classic general purpose diagnostics, support for new compilers, languages, embedded systems, CI/CD infrastructure for using the analyzer, and other areas that PVS-Studio has traditionally being covering. Moreover, these directions complement each other very well.
We will not remain complacent and will continue to develop SAST and safety directions in PVS-Studio. Support for MISRA C / MISRA C++ standards will be expanded. We plan to consider implementing rules from the OWASP standard in Java and C# analyzers. As for the C and C++ analyzer, we think it is promising to develop towards supporting the AUTOSAR standard.
- PVS-Studio static analyzer as a tool for protection against zero-day vulnerabilities.
- Technologies used in the PVS-Studio code analyzer for finding bugs and potential vulnerabilities.
- Why you should choose the PVS-Studio static analyzer to integrate into your development process.
- Now Tech: Static Application Security Testing, Q3 2020.