Our website uses cookies to enhance your browsing experience.
Hello, dear readers!
The author invites you to read three interviews with representatives of three large, modern and interesting projects to learn about their software development methodologies and about how they use static code analyzers in particular. The author hopes that you will find this article interesting. The following companies took part as interviewees: Acronis, AlternativaPlatform, Echelon Company.
Sincerely yours, Aleksandr Timofeev
The author addressed three companies to take the interviews:
— Acronis, developer of the Acronis Backup product designed for data backup and subsequent recovery
— AlternativaPlatform, developer of the "Tanki Online" project, a multiplayer browser game
— Echelon Company, developer of a series of products for code revision in the field of information security
All the companies were asked the same questions save Echelon – the questions were changed a bit for this company to better reflect the specifics of their work.
The interviewee is Kirill Korotaev, Acronis Backup product development vice-president
The main point of the Acronis Backup product we develop is about creating backup copies of users' data on their computers, notebooks and servers so that they could use these copies to recover the data later. Recovery may be needed when the computer starts malfunctioning, for example; or when one needs an earlier version of some file or document, or a file was lost.
99% of our entire project is written in C++. There are about 70 developers working on it. On average, we make 100 to 300 commits per week. We use SVN (Subversion).
We have architects and leaders who are well familiar with the code of those project parts they are responsible for; therefore, they carry out analysis of this code and know how to improve it. Every commit is passed through the code review system – that is, any change is first analyzed by programmers responsible for the corresponding code fragment.
Presently, the number of our testers is comparable to the number of developers. We employ both automatic and manual tests. For example, we have build validation tests, i.e. a set of tests to verify every new build. Ideally, a new build should be compiled after every commit into the code and tested immediately.
The process of addressing a revealed issue is the following. Any issue found by the testing department is registered in the Jira system (a more advanced paid counterpart of BugZilla). And all that is integrated with SVN – when, for example, a commit is made which addresses a particular issue, we add a reference to this commit to Jira. We may also learn about an issue from our users. They first contact our technical support service and if they reveal any bugs that should be analyzed, then, again, the information about them first gets to Jira, and we release bugfixes in the next few updates.
Among analyzers we used earlier or use currently are various tools – for example, both free open-source Cppcheck and PVS-Studio. Of course, code analyzers should be used in any project. But they all are very different, each of them being good at catching a certain type of bugs – that's why I'm totally for employing a wide variety of development means.
We do find some interesting potential bugs every now and then. For example, one of the most difficult to find bugs is the one found by PVS-Studio when standard auto pointers from the STL library are used incorrectly. Or, here is another interesting error: when you multiply a sizeof from one structure or parameter by another sizeof, PVS-Studio reasonably notices that it is pretty strange, to put it mildly, to multiply one sizeof by another, for this operation logically implies getting a quadratic quantity result.
Sometimes static analyzers can figure out when a pointer is not checked for null before being used. But these are more complex checks as it is not always obvious if a pointer can be null in a certain code fragment. It's quite a good practice to run static analyzers over the code once per day. And we also get bugs to automatically be recorded into that very Jira system, which is very useful for the product under development.
Automated tools are and will go on developing. For example, there is not a single automated system nowadays that could pick tests relying on the modifications made to the code – that is, select only those tests that need to be run for some particular modification.
What the future of static analyzers is concerned, I think they will gradually learn to handle more and more issues. At the same time, they will be shifting towards more complex analysis and perhaps even become a guarantee of code's compliance with some protocol, for instance.
Write high-quality code, test it and don't forget to use a wide variety of methodologies – including static analyzers.
The interviewee is Aleksey Kviring, CTO of "Tanki Online" LLC
Currently we have only one product like that which is the Tanki Online game. The server part is written in Java, the client part in AS3. We have about 20 programmers. We add approximately 5K lines of code per week. We use GIT as a VCS.
We use an approach typical of GIT. All the code runs through obligatory Code Review. We also use continuous integration, and the build server regularly checks code and runs tests over it.
Testing is done in a number of stages: first automatic testing, then manual testing by developers themselves (through playing the game), then by the tester team. If everything is alright, community testers join the testing process. And only after that, all the changes get into production. Our tester team is small – only three persons. But we intensively employ community testers: there are a few dozens of volunteers.
If some bug still gets into production somehow, it is fixed right after we detect it. Usually all such errors are fixed in a couple of days.
We don't use such tools at the company level. In the past, I launched a couple of static analyzers just for interest, but they found nothing serious (JetBrain IDEA checker).
I think static analysis is very useful for complex languages such as C and C++. But for simpler languages like Java, it's not that relevant. Java is not subject to memory-related issues as a class. Its syntax is plain and clear, no alternative interpretations are allowed, many issues are caught by the compiler at the compilation stage. Development environments provide convenient refactoring tools, which excludes accidental errors resulting from manual code modifications.
There is one area I'd use static analysis in when working with Java. It has to do with checking a program for correct multithread execution. But there are simply no tools capable of that at present. Generally speaking, if a static analyzer is quality and can find real bugs, it will be useful for one's project.
Future belongs to automated testing systems, continuous integration systems, and code analyzers. What I expect from static analysis is the ability to analyze multithread applications and architectural solutions.
Don't be afraid of incorporating new technologies into your development cycle. Learn from more experienced fellow programmers. Revise your old solutions. And then you certainly will succeed.
The interviewee is Andrey Fadin (a.fadin@cnpo.ru), chief designer of Echelon Company
Echelon Company is both a developer of information security analysis means and an active user of these products within the framework of information protection means certification and commercial code audit projects.
Means of information security analysis developed by our company include the following:
The Echelon team managing code security analysis and penetration testing is an association of highly skilled IT and information security specialists established on the personnel, research, and engineering bases of Echelon Company and the leading technical university of Russia, Bauman Moscow State Technical University.
We work with most of the popular programming languages such as PHP, Java, C#, C/C++, Perl, Python, JavaScript, including their most recent standards.
Program code audit conducted by Echelon Company specialists allows us to solve the following tasks:
Software that has successfully passed the audit can be certified according to information security requirements in Echelon's test laboratory.
The code audit team is formed from specialists of two basic types:
Specialists of the first type are Echelon test laboratory's experts experienced in establishing cooperation with developers of large-scale software projects (operating systems, firewalls) and also in team review of large amounts of code.
Specialists of the second type are developers (personnel of Echelon's Research&Development departments) who have high technical qualifications in various programming languages, their frameworks and typical libraries. Whenever possible, we try to cooperate with static analysis tools' developers themselves when conducting code audit, which allows them to appreciate the convenience of our analysis means directly from their own experience. Besides, since developers are better skilled in implementing new signatures for static analyzers, it does make sense to employ them for timely updates of defect base when required by the specifics of a software project under testing.
Speaking generally, the process of software development and testing is made up of the following stages:
Stages 3, 4 and 5 are usually repeated 3-4 times because, depending on tne analysis results for each potential construct, either the software project is revised to eliminate the defect (which is followed by repetition of stages starting with Stage 3) or the issue is found to be an expert's incorrect assumption or false positive by a static analyzer (which is followed by repetition of stages starting with Stage 4).
In their work, auditors use both our own solutions (AK-VS2, AppChecker) and open-source tools (Cppcheck, PMD) as well as purchased third-party commercial tools.
The algorithm of addressing issues was described in section 2. What the statistics of using analyzers is concerned, the ratio of false positives in large projects is usually above 50%, so we in any case have to employ an expert to compose the final list of potentially dangerous constructs found in project code. However, since the expert does not review the entire code but only a few critical parts of it which on average make not more than 5% of the entire code size, we can save a considerable amount of time on code analysis.
To avoid breaching any non-disclosure agreements, we unfortunately cannot tell you about errors found in particular products. But as our experience shows, most of interesting errors are related to:
In our opinion, software verification will be getting more tightly connected with development processes, both within the framework of continuous integration systems and continuous delivery systems.
Tight integration with these systems will in future allow developers to fully control software development and delivery; that is, static analyzers will serve as kind of an IPS within these processes, blocking code failed to pass the quality gate at the level of commits and releases. From this viewpoint, any CI/CD system is also an interesting source of events for SIEM systems.
Rich prospects are also provided by the introduction of static analyzers into the model-driven development paradigm; tight integration with CASE-means will allow developers to reveal errors at the levels of syntax, software components and their interfaces, and even at the level of business requirements so that an analyst, for instance, could already at the system designing stage substantiate to customers why adding a certain access control role is necessary.
Dear colleagues, during the last decade, emphasis in the field of enterprise information security was put on network security as well as endpoint security.
However, when dealing with such tasks as detection of zero-day exploits, beetles and "implants" (code fragments and configurations planted into software for the purposes of state and industrial espionage), we appear to be facing the issue when classic network- and node-level information security means (intrusion detection systems, antivirus software) cannot efficiently handle such threats.
To solve these issues, we need a comprehensive approach that on the one hand implies centralization of enterprise information security management (SIEM-systems), and on the other, makes use of software structural decomposition into components with control over their origin, as well as static analysis of their contents and materials for their production (including source texts).
The author thanks the press services and experts of the companies that took part in these interviews for prompt and detailed answers to the interview questions. The author is also thankful to the OOO "Program Verification Systems" company, developer of a contemporary static code analyzer PVS-Studio and sponsor of this article. Without their support, it might hardly have been published at all.
0
0
0
Your message has been sent. We will email you at
If you do not see the email in your inbox, please check if it is filtered to one of the following folders:
0