To get a trial key
fill out the form below
Team License (a basic version)
Enterprise License (an extended version)
* By clicking this button you agree to our Privacy Policy statement

Request our prices
New License
License Renewal
--Select currency--
USD
EUR
RUB
* By clicking this button you agree to our Privacy Policy statement

Free PVS-Studio license for Microsoft MVP specialists
* By clicking this button you agree to our Privacy Policy statement

To get the licence for your open-source project, please fill out this form
* By clicking this button you agree to our Privacy Policy statement

I am interested to try it on the platforms:
* By clicking this button you agree to our Privacy Policy statement

Message submitted.

Your message has been sent. We will email you at


If you haven't received our response, please do the following:
check your Spam/Junk folder and click the "Not Spam" button for our message.
This way, you won't miss messages from our team in the future.

>
>
PVS-Studio finds security defects and p…

PVS-Studio finds security defects and provides application security. Report by Forrester Research on SAST, Q3 2020

Sep 01 2020

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.

0759_PVS-Studio_SAST_Forrester/image1.png

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.

Additional links

Popular related articles
SAST in Secure SDLC: 3 reasons to integrate it in a DevSecOps pipeline

Date: Apr 19 2022

Author: Sergey Vasiliev

Vulnerabilities produce enormous reputational and financial risks. That's why many companies are fascinated by security and desire to build a secure development life cycle (SSDLC). So, today we're go…
What's new in PVS-Studio in 2021?

Date: Dec 31 2021

Author: Maxim Stefanov, Oleg Lisiy, Sergey Vasiliev

2021 is coming to an end, which means it's time to sum up the year! Today we'll tell you about the new features we added to PVS-Studio in the past year. Buckle up and let's go!
VSCode: how to view reports of static analyzers that support SARIF

Date: Aug 09 2021

Author: Nikolay Mironov

People increasingly start optimizing the process of finding code errors using static analyzers. Nowadays, we can choose from a variety of products to view analysis results. This post covers the ways …
PVS-Studio new features for notifying developers about errors found

Date: May 18 2021

Author: Maxim Stefanov

PVS-Studio user support often receives clients' suggestions on product improvement. We are happy to implement many of them. Recently one of the users suggested refining the automatic notification uti…
How to speed up building and analyzing of your project with Incredibuild?

Date: May 17 2021

Author: Maxim Zvyagintsev

"How much longer are you going to build it?" - a phrase that every developer has uttered at least once in the middle of the night. Yes, a build can be long and there is no escaping it. One does not s…

Comments (0)

Next comments
This website uses cookies and other technology to provide you a more personalized experience. By continuing the view of our web-pages you accept the terms of using these files. If you don't want your personal data to be processed, please, leave this site.
Learn More →
Accept