Security and reliability play a central role in software development – for developers as well as for users. Reports of data leaks and security breaches are now almost a daily occurrence.
In fact, this is not just a media phenomenon, as the number of known security vulnerabilities in software systems is rising steadily every year. The National Vulnerability Database (NVD), the de facto primary source for documented software vulnerabilities, recorded over 28,000 new entries last year. In 2016, the number was around 6,000 new entries – and this year, the 30,000 mark will most likely be exceeded.
For software manufacturers, this trend is accompanied by the increasing risk that their own products will also be affected by security vulnerabilities. Especially in the context of legal requirements such as the GDPR and the Cyber Resilience Act, this poses significant legal risks. It is therefore hardly surprising that a variety of measures are being taken in software development to raise awareness of security risks and to identify and eliminate vulnerabilities as early as possible in the development cycle. Security testing tools play an important supporting role in achieving this goal.
This article provides an overview of the most relevant categories of tools in this area, how they work, and their strengths and weaknesses.
1. Overview of Security Testing Techniques
A variety of techniques are used when testing software for security risks. These can be roughly divided depending on the required level of access to the system and its internal structure (including source code). These are referred to as black box (no access), white box (full access), or gray box (partial access) techniques. There are automated and manual approaches for each of these categories.
Manual approaches primarily involve classic code reviews and penetration testing (also known as pentesting). In manual code reviews, developers examine the source code of the application and search for possible errors and vulnerabilities. Since such reviews are recommended for software quality assurance anyway, it makes sense to pay closer attention to possible security risks here as well. In contrast, penetration testing does not necessarily require access to the source code of the application. This technique involves exposing existing security vulnerabilities in the system by putting oneself in the position of a potential attacker and carrying out security-related attacks using appropriate tools and methods. Accordingly, the only mandatory requirement here is a functioning system (as close as possible to the production system), although additional knowledge of the structure and code of the system can be helpful when performing such tests.
Manual security testing techniques have proven to be very effective in practice, and their regular use is essential to ensure a secure software system. However, they have some key disadvantages:
- The success of manual security testing depends heavily on the experience and expertise of the respective developers/testers in the field. Often, the relevant skills must first be developed within the team.
- The techniques can be time-consuming, which is why they often cannot be used with the appropriate frequency.
This is where automated security testing tools come into play, as they can be used to counteract these issues. The most commonly used tools are static application security testing (SAST) and dynamic application security testing (DAST) tools. SAST tools statically scan the application code for vulnerabilities, errors, or code smells (suspicious patterns), while DAST tools simulate attacks to scan the running application being tested for exploitable vulnerabilities. In a later section, we will take a closer look at SAST and DAST tools, as well as some related tool categories.
2. Why Are Automated Security Testing Tools Important?
Security testing tools can usually be easily integrated into the project’s CI/CD pipeline (continuous integration/continuous deployment). After an initial effort to integrate them into the project, the time required is greatly reduced and all developers can benefit from regular security tests – even those who do not yet have much experience in this area.
Another crucial factor in the relevance of such tools is the fast-paced nature of the security world. New attack techniques on software systems and vulnerabilities in popular libraries are published practically every day. The current security status of a system is therefore only a snapshot, and software that is considered secure today may be vulnerable to new types of attacks tomorrow. Even application code that has already been reviewed should therefore be regularly retested for current security risks.
A good example of this is the Log4Shell vulnerability, which was caused by a popular Java library and caused panic among many development teams worldwide at the end of 2021. Given the number of libraries that modern software projects integrate, manually searching for vulnerabilities is virtually impossible in practice, making the support of tools absolutely essential.
The same applies to new types of attack techniques that may not yet be known to the entire development team. Security tools highlight such risks and thus also help to spread knowledge in this area throughout the team and raise awareness among developers about new dangers.
Incidentally, many tools also offer functions for license checks of dependencies in the project, thus helping to minimize compliance risks.
3. SAST and SCA Tools
The most commonly used security tools in development are probably the SAST tools mentioned above. They analyze the application code (either at source code or bytecode level) and search for security vulnerabilities. Depending on the tool, the code is converted into different representations and models in order to better identify certain conspicuous patterns. Through the use of so-called taint analysis, modern tools are usually well suited to identifying known vulnerabilities that can be exploited by malicious user input (such as SQL injections in web applications). However, some tools tend to generate many false positives.
How well such tools are suited to your own project depends heavily on the technologies, programming languages, and frameworks used. Fortunately, there are a variety of commercial and free solutions in this area, so the team can try out a wide range of tools. As a guide, the Open Worldwide Application Security Project (OWASP) offers an overview with tips for selecting such tools. For an initial assessment of the effectiveness of the tools in the Java environment, it is also worth taking a look at the OWASP Benchmark Project.
In addition to the pure analysis of your own code, there are also Software Composition Analysis (SCA) tools that focus on detecting vulnerabilities in project dependencies. For example, they compare integrated libraries with NVD entries to identify security risks and in some cases even point out potential licensing problems.
4. DAST and Fuzzing Tools
In addition to static evaluation of the application code, it is also possible to perform dynamic analysis using DAST tools. This involves testing the running application for security risks using partially randomly generated inputs; access to the application code is usually not necessary. Vulnerabilities based on dynamically generated output (such as cross-site scripting/XSS) or configuration problems that only become apparent at runtime (e.g., during authentication) can often be identified more effectively with these tools than with static methods. In addition, false positives are rare with such tools, as an error that occurs in a running application can usually be transferred to a production-like environment.
The requirement for ongoing application is also one of the biggest disadvantages of these tools, as it means that they can only be used much later in the development cycle. Additional effort must also be planned for configuring the test environment, and the tools are usually not as powerful as static analyses.
There are also numerous providers and variations of DAST tools. So-called fuzzing tools are often used in this context, which can also be used outside the security context to check the behavior of the application for unexpected inputs. An overview of numerous DAST tools is provided on the OWASP website.
5. Conclusion
Security testing tools are no substitute for regular security training or manually testing your own application for potential security risks. However, they play an essential role in the development of secure software, as they perform tasks that are difficult to carry out manually to an adequate extent in everyday development work. Once integrated into the CI/CD pipeline, the entire team benefits from automatic testing for potential security and compliance risks and becomes more aware of these issues.
With the wide range of SAST, SCA, and DAST solutions and helpful resources available online, a suitable solution can be found for almost any project—some of them even completely free of charge. To get started, we recommend taking a look at the OWASP listings of popular SAST and DAST tools.
Secure Your IT!
Don’t leave potential security vulnerabilities undetected. Our IT security team will help you optimize the security of your systems.
Autor
Fabian Ochmann
Fabian ist als Softwareentwickler bei der BREDEX tätig. Neben der Java- und Web-Entwicklung beschäftigt er sich mit Themen rund um das Gebiet Application Security.
Ihr Ansprechpartner
Gerne erzählen wir Ihnen mehr zu diesem Thema.
Jobs
