DAST (Dynamic Application Security Testing) fires attack patterns such as SQL injection and cross-site scripting at a running web application. A tool like ZAP works as a proxy, records the normal traffic first and then injects attacks into those requests. Under the DORA regulation it is one of several security tests banks must run, alongside SAST, SCA and pentests.
Key Takeaways
- SAST inspects source code, SCA checks third-party libraries against vulnerability databases, and Dynamic Application Security Testing (DAST) attacks the application while it runs on a test environment.
- The DORA regulation requires banks and insurers to security-test their internet-exposed applications, and the dynamic test must have run at least once before every production release.
- In DAST testing with ZAP (Zed Attack Proxy), the explore phase records requests and responses between test and application; the attack phase then weaves its patterns into that traffic.
- Existing Playwright or Selenium regression tests feed the explore phase, and a Jenkins job starts the attack run afterwards, for example after deployment to pre-production or over the weekend.
- Daniel Schmuck wants one view per application for findings from SAST, SCA, DAST, pentests and infrastructure scans, because an outdated library otherwise gets reported three times.
Why Does DAST Testing Land in Test Management at a Bank?
Because the DORA regulation demands it, and because the topic falls to the cross-functional unit that owns the software development process, test management and test automation. DAST stands for Dynamic Application Security Testing: automated security tests against the running application, early in development, instead of proving security only in production through a penetration test. Daniel Schmuck is responsible for the IT process test management at a bank. He translates regulatory requirements into in-house testing guidelines and looks after GUI-based test automation. Security testing used to live somewhere else.
The Digital Operational Resilience Act, DORA for short, is binding for financial institutions, banks and insurers alike. The regulation and its Regulatory Technical Standard call for security testing in application development, including static and dynamic checks. DAST on its own does not satisfy DORA; it is one building block of the test program the regulation requires. But that building block is a dynamic, automated test, and whoever is the central contact for test automation in the company inevitably gets it on their desk. That is how the topic ended up with Daniel.
For testers and quality people, this is a late vindication. Shift left, finding defects as early as possible, in this case security vulnerabilities, is something they have wanted for years. Here a regulation forces the issue.
The Regulation Says Source Code Review and Means Something Else
The way in was self-study: the DORA regulation itself and the Regulatory Technical Standard that spells it out in more detail. It talks about static and dynamic source code reviews. To someone with an ISTQB background, a dynamic source code review sounds like a contradiction. Source code gets reviewed statically; dynamic testing works on the running application.
“I have an ISTQB background, and a dynamic source code review somehow seemed like a contradiction to me.”
(Daniel Schmuck)
The research led to three terms that do not appear in the regulation in that form, but do appear in the ISTQB glossary: SAST, DAST and SCA. SAST, Static Application Security Testing, checks the source code without the application running, with tools like SonarQube and its security rules. SCA, Software Composition Analysis, compares third-party and open source libraries against vulnerability databases. DAST tests the application while it runs in a test environment, using attack patterns. Daniel calls the three a trio. The static and dynamic source code reviews in the regulation correspond to SAST and DAST; SCA is the third aspect Daniel adds to the picture.
Then came the tooling question. Daniel has an affinity for open source and prefers to start with a free solution; if it hits its limits, he can still compare commercial tools later. For DAST, that path leads almost inevitably to ZAP, the Zed Attack Proxy, now run as ZAP by Checkmarx and still known to many as OWASP ZAP. He worked his way in through the documentation, the community and videos about the tool.
How Does ZAP Work as a Proxy Between Test and Application?
ZAP sits as a proxy between test execution and the application and works in two phases. The tool is built for web applications, so for HTTP and HTTPS traffic. Whether someone drives the application by hand in a browser or an automated test runs through it, every request and every response passes through ZAP.
| Phase | What happens | Where the input comes from |
|---|---|---|
| Explore | ZAP records the normal traffic and learns what a good interaction with the application looks like | manual use through the ZAP UI, a lightweight call via URL, or functional tests, controlled in detail through the REST API where needed |
| Attack | ZAP builds attack patterns into the recorded requests and fires them at the application: SQL injection, cross-site scripting, the full spectrum | profiles define which check rules run |
The second phase runs on its own; you watch. Profiles control which attack rules come into play, and that also depends on the technology. If a DB2 or an SQLite sits behind the application, only the SQL injection rules for that database run. What shapes the duration and scope of the attacks most, though, is what was recorded during the explore phase.
Despite all that configuration, this remains a black-box test through the system’s interfaces. Those do not have to be a browser. For REST services, ZAP takes an OpenAPI definition, for GraphQL a GraphQL definition, for SOAP services the WSDL. Service-based interfaces can be checked the same way as user interfaces.
Existing Regression Tests Feed the Explore Phase
The goal is to stop feeding the explore phase by hand. Driving the application manually through the UI is fine for getting to know the tool, nothing more. Instead, the existing functional regression tests run through the proxy. Anyone with Playwright or Selenium browser tests configures ZAP as the proxy in that browser, and the complete functional test records every request and response as a side effect. Nobody clicks, nobody takes notes.
The existing test automation pays off twice that way. The regression run still checks the business logic, and the same run gives ZAP the basis for the attack phase. The more of the application the functional tests cover, the more attack surface the tool knows afterwards.
Does the First DAST Report Knock You Off Your Chair?
No, at least not if penetration tests were already running beforehand. DORA explicitly requires the tests for internet-exposed applications, meaning everything anyone can reach from outside, such as the bank’s website with its closed customer area. Exactly those applications have been checked by external experts in penetration tests for quite a while. So Daniel expected the first DAST run to confirm the most recent pentest results. That is what came out: no critical findings, the same results.
The value lies elsewhere. A penetration test is a commissioned expert service at one point in time. The automated test repeats the check in the test environment as often as the pipeline triggers it, and before every production release.
How Often Does the Security Scan Have to Run in the Jenkins Pipeline?
At least once before every production release; that is the regulatory requirement. Everything beyond that is judgment. The bank maps its CI/CD pipelines in Jenkins: build the source code, package it, deploy it to the test environment. End-to-end and GUI tests run in their own jobs. The security scans now have their own Jenkins pipelines per application as well, with the respective ZAP configuration behind them.
Those jobs can hang off different triggers. When a new application version reaches the pre-production environment, the security scan runs after the deployment. Or it runs every weekend. It does not have to run daily like a functional regression test. But it has to have run before go-live.
Plugin Updates Keep the Attack Rules Current
Open source is not all alike, so maintenance deserves a look. ZAP itself has not had a new release since the bank introduced it. The features live in plugins, though, and some of those get updates every two weeks or so, the check rules in particular. Daniel’s impression: an active community stands behind the tool.
For security testing, that is no side issue. New attack vectors show up every day, new ideas for how to break something. A rule set from two years ago checks against the attackers of two years ago. Because the plugins can be updated automatically, the scan stays at today’s level.
One View of All Vulnerabilities, So Developers Don’t Get the Same Finding Three Times
Next, Daniel wants to consolidate the results, because ZAP has no results management of its own. Unlike SonarQube, where findings from static analysis and SAST can be looked up inside the tool, ZAP delivers a report as JSON, XML, PDF or HTML and keeps no data beyond that. Alongside it sit the SCA tool with its own results, the pentest reports from the commissioned agencies, and infrastructure scans run by operations that regularly check PCs, servers and other endpoints for vulnerabilities and outdated libraries.
That is four or five buckets of findings that ideally end up in one view per application. Otherwise this happens: the pentester reports an outdated library. The DAST run reports it too. The infrastructure scan finds it a third time on the test server. Three alerts, one root cause. At some point the developers are swamped with duplicates, and they are supposed to be building features too.
At the same time, vulnerabilities keep moving up the priority list, and there are separate requirements for fixing them promptly. Whoever consolidates the alerts saves developers duplicate work and leaves them time for what is actually open. Avoiding that redundancy is the point Daniel is tackling next.
Frequently Asked Questions
What is the difference between SAST, DAST and SCA?
The three methods check application security at different points. SAST (Static Application Security Testing) analyzes the source code without running the application, with tools like SonarQube and its security rules. SCA (Software Composition Analysis) compares third-party and open source libraries against vulnerability databases. DAST tests the running application in a test environment by executing attack patterns against it.
What security testing does the DORA regulation require?
The Regulatory Technical Standard for DORA speaks of static and dynamic source code reviews, meaning methods like SAST and DAST. They are mandatory for internet-exposed applications, everything customers can reach from outside, and they must have run before every production release. DAST is one building block of that test program; penetration tests by external experts continue alongside it.
Does DAST replace penetration testing?
No. A penetration test remains a commissioned expert service at one point in time. An automated DAST run repeats attack patterns in the test environment as often as the pipeline triggers it and runs before every production release. At the bank, the first run confirmed the most recent pentest results without new critical findings. Both run in parallel.
Is ZAP free to use?
Yes, ZAP is open source and free to use. Its features live in plugins, some of which are updated every two weeks or so, including the check rules for attacks. The tool does not come with its own results management; it delivers reports as JSON, XML, PDF or HTML. Anyone who hits its limits can compare commercial tools later.
Is DAST a black-box test?
Yes, largely. The tool works through the system’s interfaces, so through the browser or the services, and needs no access to the source code. For REST it takes an OpenAPI definition, for GraphQL a GraphQL definition, for SOAP the WSDL. Profiles allow the attack rules to be adapted to the technology, for example SQL injection rules for a specific database.
