In practice, it is not an easy task for manufacturers to continuously integrate a strong security mindset into complex software projects. In our blog series, Stephan Neumann, Head of usd HeroLab, and Torsten Schlotmann, Head of PCI Security Services, talk about practicable approaches and ways to still effectively improve software security.
- Part 1: Reasons for more Security
- Part 2: Anchoring Security in the Corporate Culture
- Part 3: Requirement and Threat Analysis
- Part 4: Static Code Analysis
- Part 5: Dynamic Code Analysis and Vulnerability Management
After looking at the Requirement and Threat Analysis in Part 3, we will take it a step further: approaches for more security in the code.
Stephan Neumann: "Until now, we have been talking about preparatory measures for more security. Now we should have a look at what happens during and after implementation. We are often asked which programming language to use for the greatest possible security. In summary, my answer is always the same: The programming language you know well and have the most experience with. Even if more vulnerabilities are known in Java than in PHP at a certain point in time, or one framework is rated better than another, this can change within a few days. Therefore a tip by us: OWASP Web Applications offer numerous cheat sheets for different programming languages, in which you can find hints to vulnerabilities in various topics such as authentication, encryption or password management. Furthermore, I can recommend all companies to train their employees in secure coding. It is essential to understand the attacker's approach and the most important vulnerabilities as well as suitable countermeasures - before they can be exploited.
Now let's think a few weeks or months later: before the software is running, you have thousands of lines of written code in front of you. What can be done at this point to identify errors in the code which can be exploited by attackers? Various tools have been established here, but I would like to start with the Static Code Analysis. During this process, the source code is subjected to several tests that not only check codestyle and comments, but also look for potential vulnerabilities. After the code is fully checked, the developer receives a summary report with hints and potential vulnerabilities. Of course, it's worth mentioning that false positives can happen frequently in the beginning. The tool initially hits everywhere and thus also finds potential errors that may not ultimately be relevant or are not errors at all. Here, it is important to nevertheless also check these messages and include them with appropriate rules if necessary. Since a Static Code Analysis tool automatically checks the entire source code every time again, these findings can, due to low relevance, either never be made visible again or be made visible with a message the next time through suitable adjustment. This is why, among other things, it is so important to not just use the tool once, but to continuously adjust it so it doesn't hit too fine or miss important things."
Torsten Schlotmann: "When performing such an analysis, it is important not to be overwhelmed by the results. Particularly when using the code analysis tool for the first time, the analysis leads to a large number of messages - including many false positives, as Stephan has just described. Therefore, you should be aware of the effort in advance so that you do not immediately close the results report after opening it for the first time because the number of findings initially seems overwhelming. Again, I can only recommend: Start simple. Start with the most critical points and realize that every step helps. Set aside the claim that you can check all reported findings within a week and be able to fix them all immediately. This is simply not realistic.
When it comes to the results of the Static Code Analysis, it is also important to have someone with the appropriate expertise looking at it. Initially, no in-depth security knowledge is required to run the tool, but when it comes to putting the results into the right context and being able to evaluate them, it's best to fall back on your Security Champions again. Only an appropriately trained colleague can expertly review and evaluate the results, discuss them with other colleagues if necessary, and, in the best case, even fix them."
Stephan Neumann: "One final thing I would like to add is that, in addition to the tools I mentioned, it is also possible to choose a manual process. This also has advantages and disadvantages: While an automated tool can search through a large mass of source code, individual, manual checks are of course advantageous for checking particularly critical parts of code. This is, needless to say, much more time-consuming. In my opinion, however, it is not mutually exclusive to integrate both - first to work completely automatically and then to check individual points again manually.“
Do you need support with the manual testing of critical code parts? Contact us, we will gladly support you with a code review.
