Why DAST is launched late and vulnerabilities reach release
Dynamic application scanning in most teams lives separately from the build and delivery pipeline. It is run manually — before a major release or after an external contractor brings another report.
Static analysis, meanwhile, sits in the build and gates merge of changes, while DAST remains a one-off procedure on the side.
The reason is clear: a dynamic scanner needs a deployed environment, accounts for different roles, and populated test data.
Raising this environment for every change seems too expensive, so the check is moved to the end of the cycle — when the application is already fully assembled and "almost ready."
The cost of such savings is vulnerabilities in the production environment. A finding arrives when the code has already been delivered to users, and closing it requires an unscheduled release: an urgent fix, a rebuild, a manual run of affected scenarios.
The window between a defect appearing and being fixed stretches to weeks, and some issues are already visible from outside by then.
The second effect is that security checking before release turns into a one-off approval. The report is read after rollout, priorities are set by intuition, and recurring defects move from release to release.
Below we break down how this is closed: what is needed for dynamic scanning to work inside the common pipeline and return results before rollout.
The effect of finding vulnerabilities on every pipeline build
Automatic scanning on every build compresses the window between a vulnerability appearing and being detected from weeks to hours.
While the environment is raised after rollout, OWASP ZAP crawls the application in active scan mode and puts the report into the same run as the automated tests. The developer receives the defect in the context of their change, not a month later at acceptance.
This changes the structure of findings. The share of vulnerabilities caught before release usually grows from half to nine out of ten — the remainder falls on access logic that the scanner does not check.
The class of failures that is fully closed: routes accessible without authorization, missing security headers, outdated libraries with known defects.
Early vulnerability detection reduces manual checks not through quality but through iteration. The engineer stops walking through typical scenarios manually and focuses on roles and edge states.
Change delivery time drops because the check runs in parallel with the build and does not require a separate approval stage.
Metrics that show the effect: time from change to the scanner's first report, share of builds with findings, ratio of closed defects to open ones per week, number of manual checks per release.
If these numbers do not move, the pipeline is configured formally, and this is the first thing we examine during an audit.
DAST run modes: build, schedule, manual run
Dynamic analysis works not with source code but with a running application: until the environment responds to requests and lets you in under an account, the scanner has nothing to check.
Therefore, the run mode is chosen by environment availability and by how much time the run can take in the pipeline — not by ease of configuration.
| Run mode | When it fits | Limitations and maintenance cost |
|---|---|---|
| On build event | A fast signal is needed for every change: development environment, key routes, security headers | The run occupies the pipeline, false positives slow release — a baseline report and an exclusion list are needed |
| On schedule | A nightly deep crawl of a production-like copy, including active checks | The environment must live permanently, and someone reviews the report in the morning |
| Manual run | Before a major release, after an authorization scheme change, when connecting an external environment | There is no regularity: findings accumulate unnoticed between runs |
| Hybrid: short run on build plus deep run on schedule | Frequent releases in services with a personal account and payment | More expensive to configure: two profiles, environment separation, a single point for reviewing findings |
Requirements for the environment are the same in all modes: the scanner needs an account with crawl rights, an environment with reproducible data, and a baseline report on already known findings.
Without this, every build will be red, and the team will stop opening the report — regardless of the chosen mode.
A practical order is this: first raise a manual run and record what the scanner actually sees in your application, then move it to a schedule, and only after that add a build-event launch with a trimmed profile. This transition provides regular checks without turning the pipeline into a bottleneck.
How we embed DAST into the pipeline: stages of work
DAST implementation begins not with the scanner but with inventory: which services and environments we check, under which roles we log in, which routes are critical for the business.
Without this, the scanner hits the login form and returns a one-page report — the check formally exists, but there is no benefit.
- Inventory of targets. List of addresses, test accounts for each role, load limits and a run window that is safe for the environment.
- Run scheme. A short check runs on every change after rollout, a full one on schedule. Feedback arrives in minutes, not by the end of the week.
- Configuring crawl scenarios. Login, session renewal, crawling by API specification and crawling the interface: forms, parameters, hidden fields that are not in the specification.
- Noise trimming. We record exclusions with justification and a review date, and divide findings into confirmed and those requiring manual review. Otherwise, the report stops being read after a month.
- Build quality threshold. Only confirmed high-severity vulnerabilities on critical routes block; everything else goes as a warning. We agree the threshold with development: one that is too strict is quickly disabled.
- Testing on control vulnerabilities. We plant an intentional vulnerability in the environment and make sure it appears in the report. If it does not, we fix the scenario, not trust in the tool.
- Procedure for reviewing findings. We define who reviews the report and within what time, where the task goes, how closure is confirmed. The report for each run remains in the build artifacts.
After handover of the procedure, the pipeline works without us: new services are added to the scheme via a checklist, and the quality threshold is edited in one place.
Implementation artifacts: settings, schemes, procedures
Before launching DAST in the pipeline, we record everything needed for reproducible operation: otherwise the scanner lives until the first change of environment owner or until the first false positive, after which the check is disabled.
At the output, the customer receives not a one-off run report but a working kit — from configurations to the procedure for reviewing findings.
- Scanner launch configurations: separate profiles for a quick check on every build and a full run before release, binding to the pipeline stage, thresholds at which the build stops.
- Placement scheme: where the scanner is deployed, how it reaches the target environment, which service accounts and network rules are needed.
- Access policies for environments: accounts for authenticated scanning, rate limiting and run windows so the check does not interfere with load and manual tests.
- False-positive trimming rules: exclusion list with justification and review period, labeling of known findings — new defects do not drown in noise.
- Coverage map: which routes and user roles are checked, what is consciously left outside the scanning scope.
- Findings handling procedure: severity levels, response times, who confirms the defect and who closes it, how a finding turns into a development task.
- Documentation and handover: launch and debugging instructions, review of typical errors, team training, and transfer of ownership.
We hand over the procedure together with access and a walkthrough on a real run — so that profiles, exclusions, and thresholds can be changed without us.
Case study: how a one-off audit became an everyday check
The customer is a payment service made up of a dozen services behind a common gateway.
Security checks were ordered once a quarter: the audit took two to three weeks, the report arrived as a separate document, and some findings — an exposed debug endpoint, forgotten headers, an outdated dependency — surfaced after release and required an unscheduled rollout.
What was changed
The OWASP ZAP scanner was deployed in automatic analysis mode and included in the build pipeline: the run starts on every merge to the main branch.
The environment is raised with the same migrations as in production, crawling follows the route map, and the result is compared with the baseline — a new defect is visible against already known ones.
Critical findings stop the build, the rest go to the tracker linked to the commit and the author of the change.
Metrics before and after
- Manual checks: once a quarter → automatic run on every merge and in nightly builds.
- Time from defect appearing to detection: two to three weeks → hours, within the same day.
- Share of findings closed before release: 55% → 96%; the rest are conscious exclusions recorded in the baseline.
- False positives: after configuring rules, noise dropped by about three times, and reports stopped being read in full.
Manual audit was not cancelled: it remained for access scenarios and business operation logic that the scanner does not check. The daily run covers the regular background, so external checking no longer spends time on the obvious.
How DAST differs from SAST and what to launch first
Dynamic and static analysis look at different states of the system, so they do not replace each other but cover different classes of defects — those listed by OWASP.
Static analysis parses source code and configuration as text: it does not need a deployed environment, the check fits into minutes, and it can run on every change.
Dynamic sends real requests to the running application and finds what is not visible in code: authorization bypass by identifier substitution, errors in role permissions, accessible service addresses.
| Check | Place in the pipeline | What it reveals | What it does not see |
|---|---|---|---|
| Static analysis | On every change, before merge to the main branch | Dangerous constructs in code, secret leaks, vulnerable dependencies | The logic of service interaction, behavior under someone else's session and under load |
| Dynamic analysis | On the test environment: nightly run and step before release | Access errors, environment configuration, real service responses | Code branches not touched by the crawl scenario |
The order of connection is set by the cost of feedback. Static analysis responds in minutes, so it is installed first — as a mandatory check on change in the branch.
Dynamic requires a deployed environment with test data and runs longer, so it is moved out of the fast cycle into a nightly run and into a mandatory step before release.
Implementation priority with limited team attention: first static analysis on change, then dynamic before every release, then expanding scenarios to authenticated roles.
Until checks are embedded in the pipeline, they remain a one-off action — and a regular run turns them into a managed process.
Technical doubts: noise, login, test environments
Most doubts around DAST boil down to four questions: how many false positives will have to be reviewed manually, how the scanner passes the login form, what it sees on the test environment, and how much it will stretch the build. Short answers are below.
False positives — how many will there be?
Noise comes from blind injections, templates with script insertions, and custom authorization schemes. We disable rules that consistently err on a specific stack and confirm every finding with a repeat request from another point. The report includes vulnerabilities with a reproducible scenario, not a list of guesses.
How does the scanner pass authorization?
Credentials are substituted from the secrets vault, the redirect chain is repeated, the session is maintained, and when the token expires, login is performed again without manual involvement.
We take different roles — guest, user, administrator: this catches access control bypass too, not only open forms.
What will end up on the test environment?
The environment is populated with a depersonalized copy of the database, access is limited by the run time and build agent addresses, and after scanning the environment is recreated. Checks remain reproducible between runs, and personal data does not enter the environment.
How much does this lengthen the build?
A full run is noticeably longer than unit checks, so the modes are separated: a quick profile on critical paths — on every commit, an extended one — on schedule and before release.
Scanning runs in parallel with other stages and does not block the build until a finding is confirmed.
Let's discuss the task: we will assemble a checking scheme for your pipeline
To make the conversation concrete, bring a description of how your pipeline is currently structured. A ready-made technical specification is not needed — inputs are enough to show where dynamic analysis (DAST) will fit without stopping releases.
- How the build is launched and which environments are raised automatically — from the test environment to pre-production.
- Where it makes sense to put the check: right after deployment to the environment, on schedule outside working hours, or manually before release.
- Which services are raised in an isolated environment and whether they need external dependencies — databases, queues, third-party services.
- Whether there are test accounts and data so the check passes authorization instead of hitting the login form.
- In what form it is convenient for the team to receive the result — a task in the tracker, a file in build artifacts, or a summary on a dashboard.
- Who reviews what is found and at what threshold the build is considered failed: a single finding or their share of the total number of routes.
In response, we bring a check implementation plan: a scheme for placing stages in the pipeline, requirements for the environment, trigger thresholds, and an estimate of work timelines.
Describe the task in a convenient way — a call, correspondence, repository access — and we will return with an estimate and plan.