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
In the fifth and final part of our Software Security Blog series, our experts talk about possible approaches for software products that are already running: Detecting vulnerabilities with dynamic code analysis and avoiding gateways in open source components with vulnerability management.
Stephan Neumann: " Now we are in the phase in which the application is not yet final, but already runs in certain parts and a program part is executable. This is a good time to talk about the possibility of dynamic code analysis, because unlike static code analysis, dynamic code analysis requires an executable program. I can only urge you not to wait until the software is released to identify potential vulnerabilities in your software. Check it before an attacker will try it with the help of other tools. Such an analysis can be performed at this stage of the development process using vulnerability scanners. To perform the scans, it is again important to have some know-how, but most importantly, don't be afraid and just start.
Two different approaches can be used to identify vulnerabilities in the application: One is to use a fully automated web application scanner, such as Qualys, Netsparker or Arachni. These scanners run automatically over the application after an initial configuration and identify vulnerabilities. However, one disadvantage of these scanners is that they reveal little insight into their coverage and methods.
Personally, I'm more of a fan of taking a smaller and dedicated approach with so-called intercepting proxies like Burpsuite or OWASP ZED Attack Proxy. These can intercept requests from a browser or an API platform like Postman for manual testing or automated scanning in the next step. The tool gives me direct indications of which requests I should take another look at for potential vulnerabilities and also gives developers more insight into network communications."
Torsten Schlotmann: "I can only agree with Stephan here, but I would also like to mention that the topic of vulnerability analysis cannot be fully covered with the use of purely automated tools. These tools are always limited to a certain extent in what they can check within the software and thus identify vulnerabilities. Particularly errors in the business logic can largely only be found via manual tests - internally or externally. A combination of automated and manual testing therefore certainly brings the best results here as well.
As a final approach to greater security, I would like to address a topic which, in my opinion, is becoming increasingly important in software development: Vulnerability Management and, in this context, especially Vulnerability Management for Open Source components. Nowadays, very few software products work without open source. It is therefore essential for software manufacturers, but also a first challenge, to identify and document all open source components used in their own applications. Only in this way is it possible to analyze whether components are used in the latest version or in a version without vulnerabilities. Without this documentation, there is a risk that integrated open source components will be forgotten and may have vulnerabilities in their outdated version.
Commercial tools and open source solutions can help to regularly check whether vulnerabilities are known for the version in use and, if necessary, update the version accordingly. Among other things, they search databases and check whether the version of the component in use has known vulnerabilities or whether more up-to-date versions are available. Vulnerability management should be performed not only during active development, but also in the maintenance phase after release.
My final recommendation for this blog series, and I'm sure Stephan agrees with me here: All the measures and tools presented should be used regularly. Remember to embed security in all phases of the software development lifecycle, i.e. also after release and in the active or passive maintenance phase. The threat landscape is constantly evolving, with new vulnerabilities being identified all the time. Therefore, stay up-to-date and test your application regularly - for example, through penetration tests, static or dynamic code analysis, or manual code reviews."
