Security testing in software development means not only carrying out security checks at the end using a pentest, but integrating them continuously into the CI/CD pipeline. Tools such as OWASP ZAP or Nuclei automatically scan for vulnerabilities such as faulty access controls or incorrectly set HTTP headers. This significantly reduces pentest findings and saves development effort.
Key Takeaways
- Dynamic security scanners such as OWASP ZAP and Nuclei can be integrated into CI/CD pipelines and already cover 60 to 80 percent of common security requirements without manual configuration.
- Teams that establish security checks before the pentest reduce the pentest report from a typical 60 to 4 to 5 pages because standard findings such as missing HTTP headers are automatically found in advance.
- Broken access control has replaced SQL injection as the most common critical vulnerability because modern frameworks largely intercept injections, but authorization logic remains the responsibility of the developer.
- The biggest obstacle to the introduction of security testing is not technical complexity, but unresolved responsibility: no team wants to catch the hat who is responsible for the topic internally.
Security is a test case, not an appendage at the end of the project
Software security belongs in the entire development cycle, not in a one-off pentest shortly before go-live. Christian Biehler has been working as a pentester for ten years and knows the pattern: an application is built over months, at the end someone comes along and points the finger at the open gaps. Then the team has to go back to the beginning and rewrite the code.
The DevOps concept and later DevSecOps have provided the tools to solve this differently. Security testing can be automated and integrated into the pipeline at an early stage. A tool can report many things that would otherwise only be found by the pentester during development.
Security is no different from other non-functional topics. Performance, architecture, usability: in these areas too, people have been “testing around a bit” for a long time and then realized that everything needs to be changed. The idea of bringing this forward is not new. Nevertheless, the topic of security is still completely missing from many test tracks.
Which vulnerabilities are really being exploited today
The most critical gaps today are no longer in classic injections, but in logic and access control. SQL injection has long been the big issue: an attacker injects their own code into a database query, reads the entire database or overwrites passwords. Standard frameworks now largely intercept this, which is why this category has become less common.
Errors in authorizations have become more common. The standard example: You log in to your bank and retrieve your account statement with ID = 1. What does an attacker do? He tries ID = 2, ID = 3, ID = 4 and gets other people’s account statements.
Any application with a role and authorization model is affected. This includes the numbering of PDF documents as well as hidden administrative functions.
A common error is found in modern, JavaScript-heavy web applications that only talk to an API. Some developers place security checks in the front end. This does not work because an attacker intercepts the API requests, manipulates them and thus gains direct access to the data.
How automated security tools get into the pipeline
Freely available tools cover most of the obvious vulnerabilities without anyone having to hack manually. No real attacker sits in the basement in a black hoodie and works their way through manually. Attackers automate as much as they can, and these tools can be built into the CI/CD pipeline.
OWASP is a good place to start when it comes to security tools for the web. The OWASP ZAP is the freely available tool of choice for dynamic application security testing. It can be integrated into a pipeline, outputs XML and HTML reports and can be controlled via API and CLI. It crawls every page and every parameter and then sends the classic injections through.
The attack patterns have hardly changed. In the simplest case, cross-site scripting begins with a script tag plus an alert, while an SQL injection often begins with an apostrophe. The ZAP goes through these patterns for each field, which quickly means a few tens of thousands of requests for large applications.
There are also lighter tools. Nuclei works template-based, calls each page once and checks basics such as encryption and HTTP headers. A dependency checker covers outdated libraries and their vulnerabilities.
Long scans break the fast deployment pipeline
A full ZAP scan does not fit into a cycle that deploys several times a day. While Nuclei runs in minutes because it only calls the pages once and checks basics, ZAP has to crawl every form and send every request with every payload. Depending on the size of the application, this takes between one and four hours.
If you deploy nightly, you may still be able to accommodate the ZAP. For several deployments per day, it should be removed from the standard pipeline and scheduled separately.
How much coverage off-the-shelf tools deliver
Off-the-shelf tools cover a good part of the requirements, but not everything. The OWASP ASVS catalog with around 290 controls, which is used as a reference in the industry. The top 10 are nice, but are not suitable as a basis for testing.
Four tool categories go a long way: a dynamic scanner such as ZAP, static code analysis, a dependency checker for updates and libraries and a look at the operating system. Out of the box, the ZAP can be used to check roughly between 60 and 80 of the requirements dynamically, while static analysis is slightly better.
A gap remains, which you fill with your own test cases. If you are writing unit tests anyway, you can also think about security. Whether an email address corresponds to the associated RFC can be tested. What happens if the email field suddenly receives a 400 MB input? Then you need clean error handling, and that should be stored as a test case.
For these last percentage points, “Start Clicky-Bunty” is not enough. You have to check what the tools really cover and what you have to write yourself.
Why teams end up with the pentest instead of integrating security early on
The problem is rarely technical, but organizational. The technical implementation of a dynamic testing suite can be set up in about a day and a half. The real question is: who does it, who manages it, who is familiar with security?
In many companies, someone stands in the meeting room with a hat in their hand and wants to put it on someone who will do security from then on. Nobody in development or operations is bored, so everyone tries to duck away. Should each team do it themselves, or should the security tools be bundled centrally across several dev teams? You quickly end up with roles, responsibilities and power struggles.
What’s more, the threat seems abstract. No one can guarantee that the attack will actually happen, and you often don’t even notice a hacker on your own product. Sometimes you simply don’t have an idea of what an attacker can do.
We have developers on training courses, especially in the web area, who say: We have defined a dropdown, the attacker can’t enter anything else. The attacker has a proxy, he can enter whatever he wants.
Christian Biehler
One antidote is mob hacking: sit down as a team, send an attacker tool over your own application and see how an attacker perceives it. This provides enlightenment.
Frameworks help with injections, not authorizations
Modern web frameworks are good at catching classic injection vulnerabilities, but leave you alone when it comes to authorization. React, Angular and co. encode output and have SQL injection and cross-site scripting largely under control.
The catch: a framework gives you the freedom to shoot yourself in the foot. There are cases in which a framework actually encodes, but then something looked funny on the website, so the encoding was turned off again and the salad is back.
Frameworks are of little help when it comes to authorization and role models. Who has what authorization and whether it is checked is defined by the person building the application. This is why access control errors are among the most critical findings.
Where security counts everywhere: Desktop, mobile and API
Security is relevant wherever data is processed or transferred, not for an isolated local function. An insecure desktop application is not critical until it saves or communicates data. If the calculator on the Windows client has a vulnerability, the world will not come to an end.
Practically every application today communicates with a backend somewhere via HTTP. Mobile apps usually have a front end for both major platforms, while data processing takes place on the server. Instead of classic POST calls, there are then API calls, with a few additional checkpoints, but essentially back to the web world.
Mobile apps have their own measures: Data that resides on the device, or the screen blurring out when a banking app moves to the background. Nevertheless, the real damage is caused by communication with the server. Changing the local account balance in the app does nothing, the real account balance can only be changed by a request to the backend.
How up-to-date the check catalogs are against new attackers
The established vulnerability categories have been stable for years, new technology is added with a delay. The OWASP checklists are largely independent of language, operating system and database. Specifics exist in detail, such as attacks that only work under Linux or only under Windows, but the lists include categories such as Local File Inclusion or Remote Code Execution.
These vectors hardly change if you switch from Debian to Red Hat or from Windows 10 to Server 2022. There are only slightly different ways to exploit them. In addition to OWASP, the CWE list, which also covers non-web-specific topics, helps. A new edition of the top lists comes around every four to five years, when points are moved.
AI is a different story. If restrictions of an AI generator are circumvented and actions can be carried out in the company context, this is still missing in a classic top 10. Here, the community is often ahead of OWASP.
Quantum computing is also a sword of Damocles hanging over transport encryption. One attack scenario: intercepting encrypted data today and decrypting it later with sufficient computing power. In practice, there is little that can be done about this except to use the latest TLS versions, current ciphers and disposable keys (ephemeral cipher suites) so that the same session key is not always used.
Where to start if security has so far only taken place at the end
Most teams already do security without calling it that. A scanner with quality gates is often already there, but produces thousands of findings that nobody looks at. A dependency check for outdated JavaScript or Java libraries also runs in many pipelines.
The next step is to be confident. If the application is deployed and you are running Selenium tests anyway, run a security tool like Nuclei or ZAP along with it or separately. Look at the results and feed them back to the team.
It is important to start without any hurdles. Don’t immediately make the scan a fail criterion two weeks before go-live, as this undermines acceptance. Approach the topic. Start with Nuclei and a few templates, first check the header and TLS configuration. It doesn’t have to be the perfect solution.
The benchmark is not an A+ with an asterisk, but not having a black eye. That’s a good start.
Early testing drastically shortens the pentest report
Integrating security into development reduces the pentest report from 60 pages to just a few pages of real findings. In a typical report for an application that has never been tested before, around 45 of the 60 pages are standard stuff: HTTP headers, misconfigurations, hardening issues. You don’t need ZAP for that, it’s already pulling Nuclei.
The distribution can be seen from documented findings over six months: calculated on 100 tests, about once SQL injection, 30 to 40 times cross-site scripting, but in almost 100 percent of cases incorrect cipher suites, missing headers, set debugging flags or static developer files lying around.
If you subtract this standard stuff automatically, the report still contains the four to five pages that only a pentester can really find: hidden logic errors, attacks across multiple form fields. The pentest costs less, the developer reads less, and two real issues end up in the ticket system instead of thirty header findings.
