Security testing in software development means running security checks continuously in the CI/CD pipeline instead of saving them for a pentest at the very end. Tools like OWASP ZAP or Nuclei scan automatically for vulnerabilities such as broken access control or misconfigured HTTP headers. That cuts pentest findings considerably and saves development effort.
Key Takeaways
- Dynamic security scanners like OWASP ZAP and Nuclei fit into CI/CD pipelines and, without any manual configuration, already check 60 to 80 of the roughly 290 requirements in the OWASP ASVS catalog.
- Teams that put security checks in place before the pentest shrink the typical pentest report from 60 pages to 4 or 5, because standard findings like missing HTTP headers are caught automatically beforehand.
- Broken access control has replaced SQL injection as the most common critical vulnerability: modern frameworks block most injections, but authorization logic is still up to the developers.
- The biggest obstacle to introducing security testing isn’t technical complexity but unclear ownership. Nobody wants to be the one stuck with the topic internally.
Security Is a Test Case, Not an Add-On at the End of the Project
Software security belongs in the whole development cycle, not in a one-off pentest shortly before go-live. Automated security testing in the pipeline is how you get there. Christian Biehler has worked as a pentester for ten years and knows the pattern well: a team builds an application for months, then someone shows up at the end and points at all the open holes. Back to the start, rewrite the code.
DevOps and later DevSecOps brought the tools to do this differently. Security testing can be automated and built into the pipeline early. Much of what a pentester would only find at the end, a tool can report during development.
Security is no different from other non-functional topics here. Performance, architecture, usability: for years, teams did “a bit of testing around” at the end and then found out everything had to change. Moving that work forward isn’t a new idea. Even so, security is still completely missing from many test pipelines.
Which Vulnerabilities Attackers Really Exploit Today
The most critical holes today are no longer classic injections. They sit in logic and access control. SQL injection was the big issue for a long time: an attacker slips their own code into a database query, reads the entire database or overwrites passwords. Standard frameworks now block most of that, so this category has become rarer.
Authorization flaws, on the other hand, have become more common. The textbook example: you log in to your bank and pull up your statement with ID = 1. What does an attacker do? They try ID = 2, ID = 3, ID = 4 and get other people’s statements.
Any application with a role and permission model is affected. That includes sequentially numbered PDF documents as well as hidden admin functions.
A frequent mistake shows up in modern, JavaScript-heavy web applications that only talk to an API. Some developers put the security checks in the front end. That doesn’t work, because an attacker intercepts the API requests, manipulates them and goes straight to the data.
How Automated Security Testing Gets into the Pipeline
Freely available tools cover most of the obvious vulnerabilities without anyone hacking by hand. No real attacker sits in a basement in a black hoodie working through things manually anymore. Attackers automate as much as they can, and the same tools can go into your CI/CD pipeline.
For web security tools, OWASP is a good place to start. OWASP ZAP is the free tool of choice for dynamic application security testing. It integrates into a pipeline, produces XML and HTML reports and can be controlled via API and CLI. It crawls every page and every parameter and then fires the classic injections at them.
The attack patterns have barely changed. In the simplest case, cross-site scripting starts with a script tag plus an alert, and an SQL injection often starts with a single quote. ZAP runs through these patterns for every field, which quickly adds up to tens of thousands of requests for a large application.
There are lighter tools, too. Nuclei is template-based: it calls each page once and checks basics like encryption and HTTP headers. A dependency checker takes care of outdated libraries and their known vulnerabilities.
Why a Full ZAP Scan Doesn’t Fit a Fast Deployment Pipeline
A complete ZAP scan doesn’t fit into a cycle that deploys several times a day. Nuclei finishes in minutes because it only calls each page once and checks the basics. ZAP has to crawl every form and send every request with every payload. Depending on the size of the application, that takes one to four hours.
If you deploy nightly, you might still be able to fit ZAP in. With several deployments a day, take it out of the standard pipeline and schedule it separately.
How Much of the OWASP ASVS Off-the-Shelf Tools Cover
Off-the-shelf tools cover a good share of the requirements, but not all of them. The industry reference is the OWASP ASVS catalog with around 290 controls. The Top 10 is nice, but it isn’t a basis for testing.
Four tool categories take you a long way: a dynamic scanner like ZAP, static code analysis, a dependency checker for updates and libraries, and a look at the operating system. Out of the box, ZAP can dynamically check roughly 60 to 80 of those requirements, and static code analysis does a little better.
A gap remains, and you fill it with your own test cases. If you’re writing unit tests anyway, think about security while you’re at it. Whether an email address conforms to the relevant RFC is testable. What happens when the email field suddenly receives a 400 MB input? Then you need clean error handling, and that belongs in a test case.
For those last few percentage points, just clicking Start isn’t enough. You have to check what the tools really cover and what you need to write yourself.
Why Teams End Up with the Pentest Instead of Building Security in Early
The problem is rarely technical. It’s organizational. Setting up a dynamic testing suite takes about a day and a half. The real question is: who does it, who maintains it, who knows security?
In many companies, someone stands in the meeting room holding a hat, looking for a head to put it on, and whoever wears it does security from then on. Nobody in development or operations is short of work, so everyone ducks. Should each team handle it, or should the security tools be run centrally across several dev teams? Before long you’re deep in roles, responsibilities and power struggles.
On top of that, the threat feels abstract. Nobody can guarantee the attack will actually happen, and often you don’t even notice a hack on your own product. Sometimes people simply have no picture of what an attacker can do.
“We have developers in training courses, especially in web development, who tell us: we’ve defined a dropdown, so 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, point an attack tool at your own application and see it the way an attacker does. It’s an eye-opener.
Frameworks Help with Injections, Not with Authorization
Modern web frameworks are good at catching classic injection flaws, but they leave you on your own with authorization. React, Angular and the like encode output and have SQL injection and cross-site scripting largely under control.
The catch: a framework also gives you the freedom to shoot yourself in the foot. There are cases where the framework did encode, then something looked odd on the page, so someone switched the encoding off again, and you’re back to square one.
With authorization and role models, frameworks barely help. Who has which permission, and whether it gets checked, is defined by whoever builds the application. That’s why access control flaws are among the most critical findings.
Where Security Matters: Desktop, Mobile and API
Security matters wherever data is processed or transmitted, not for an isolated local function. An insecure desktop application isn’t critical until it stores or sends data. If the calculator on a Windows client has a vulnerability, the world won’t end.
In practice, almost every application today talks to a backend over HTTP somewhere. Mobile apps usually have a front end for both major platforms, while the data processing happens on the server. Instead of classic POST requests you get API calls, with a few extra checkpoints, but at heart it’s the web world again.
Mobile apps have their own measures: data stored on the device, or blurring the screen when a banking app moves to the background. The real damage still happens in the communication with the server. Changing the local account balance in the app achieves nothing. Only a request to the backend changes the real balance.
How Current the Checklists Are Against New Attacks
The established vulnerability categories have been stable for years, and new technology is added with a delay. The OWASP checklists are largely independent of language, operating system and database. There are specifics in the details, such as attacks that only work on Linux or only on Windows, but the lists name categories like Local File Inclusion or Remote Code Execution.
These attack vectors barely change when you switch from Debian to Red Hat or from Windows 10 to Server 2022. There are just slightly different ways to exploit them. Besides OWASP, the CWE list helps, since it also covers topics beyond the web. A new edition of the top lists comes out every four to five years or so, and items get reshuffled.
AI is a different story. When someone gets around the restrictions of an AI generator and uses it to trigger actions inside a company, a classic Top 10 doesn’t cover that yet. Here the community is often ahead of OWASP.
Quantum computing also hangs over transport encryption like a sword of Damocles. One attack scenario: capture encrypted data today and decrypt it later once there’s enough computing power. In practice there’s little you can do beyond using current TLS versions, current ciphers and throwaway keys (ephemeral cipher suites), so the same session key isn’t reused.
Where to Start If Security Has Only Happened at the End
Most teams already do some security without calling it that. A scanner with quality gates is often in place but produces thousands of findings nobody looks at. A dependency check for outdated JavaScript or Java libraries runs in many pipelines, too.
The next step is to just go for it. Once the application is deployed and you’re running Selenium tests anyway, run a security tool like Nuclei or ZAP alongside them or on its own. Look at the results and feed them back to the team.
Start without any barriers. Don’t turn the scan into a fail criterion two weeks before go-live, because that kills acceptance. Ease into it. Start with Nuclei and a few templates, and check headers and TLS configuration first. It doesn’t have to be perfect.
The goal isn’t a perfect score with a gold star. It’s not ending up with a black eye. That’s a good start.
Early Testing Shrinks the Pentest Report Dramatically
Building security into development cuts the pentest report from 60 pages down to a few pages of real findings. In a typical report on an application that has never been tested before, about 45 of the 60 pages are standard stuff: HTTP headers, misconfigurations, hardening issues. You don’t need ZAP for that. Nuclei already catches it.
Findings documented over six months show the distribution. Per 100 tests, there’s SQL injection about once and cross-site scripting 30 to 40 times, but in almost 100 percent of cases wrong cipher suites, missing headers, debugging flags left on or static developer files lying around.
Once you filter out that standard stuff automatically, the report is down to the four or five pages only a pentester can find: hidden logic flaws, attacks spread across several form fields. The pentest costs less, developers read less, and two real issues land in the ticket system instead of thirty header findings.
Frequently Asked Questions
Why is Broken Access Control now considered more critical than SQL injection?
Errors in authorization logic have replaced SQL injection as the most common critical vulnerability. Standard frameworks largely block injections, but it is up to the person building the application to define who has which authorizations. A typical pattern: The account statement is retrieved with ID = 1; an attacker tries ID = 2, 3, and 4 and gains access to other users’ statements. Any application with a role- and permission-based model is vulnerable.
Is it enough to implement permission checks in the front end of a JavaScript application?
No. An attacker does not operate through the user interface but intercepts API requests using a proxy, manipulates them, and gains direct access to the data. Even a fixed dropdown menu offers no protection, as the attacker can use the proxy to enter whatever they want. The validation must take place on the server side behind the API.
How long does a complete dynamic security scan of a web application take?
With OWASP ZAP, a full scan takes one to four hours, depending on the size of the application. The scanner crawls every page and every parameter and runs every payload; for large applications, this quickly adds up to tens of thousands of requests. If you deploy nightly, you can fit this in. If you have multiple deployments per day, the scan should be removed from the standard pipeline and scheduled separately. Nuclei completes the scan in minutes.
Do you need your own test cases if automated security scanners are running in the pipeline?
Yes, there’s always a gap. The OWASP ASVS catalog, with around 290 controls, serves as the basis for testing; the Top 10 isn’t sufficient for this. A dynamic scanner checks about 60 to 80 of these requirements without manual configuration; static analysis covers slightly more. You’ll have to write the rest yourself, for example validating an email address against the RFC or handling errors for a 400 MB input.
What is the biggest hurdle in implementing security testing?
Rarely the technology. A dynamic testing suite can be set up in about a day and a half. What remains unclear is who’s responsible: Who oversees this area? Does each team handle it on its own, or are the tools managed centrally across multiple development teams? Since no one in development or operations has the bandwidth, everyone avoids the issue. On top of that, the threat seems abstract, because a hack on one’s own product often goes unnoticed.
Do desktop and mobile applications need to be tested for security in the same way as web applications?
Security becomes relevant wherever data is processed or transmitted. An isolated local function is not critical: If the calculator on the Windows client has a vulnerability, it’s not the end of the world. In practice, almost every application communicates with a backend via HTTP. With mobile apps, that’s where the damage occurs: changing the local account balance does nothing; only a request to the server changes the actual balance.
Should a security scan be included in the pipeline as a failure criterion right from the start?
No. A scan that immediately becomes a failure criterion two weeks before go-live undermines acceptance within the team. It makes more sense to start without any hurdles: Launch Nuclei with a few templates, initially checking only headers and TLS configuration, review the results, and feed them back to the team. The benchmark isn’t a perfect score with an asterisk, but rather avoiding any major issues.
