Reintroducing DAST Without Blowing the Merge Request Budget
Northwind Payments runs 38 GitLab projects in one group. Merge request pipelines run SAST, dependency scanning, secret detection, and container scanning. DAST was removed eight months ago after it added 22 minutes to the pipeline and produced 140 findings, of which the team judged roughly 130 to be false positives. Last month a reflected XSS reached production in the customer portal and was found through a bug bounty report. The security lead wants DAST back; the platform team refuses any increase in merge request pipeline duration. The compliance manager wants evidence that no Critical finding can merge. The group has Ultimate, a shared runner fleet with a 30-minute job timeout, and review apps deployed to Kubernetes for every merge request. Only 6 of the 38 projects have a security policy project configured. Two of the projects handle payment card data and change weekly; the rest change daily with small diffs.
1. The platform team refuses a longer merge request pipeline. Describe how you would reintroduce DAST coverage while keeping merge request feedback inside the existing time budget. Explain what each option fails to catch.
Read the worked answer
Option 1: DAST against the review app inside the merge request pipeline. The project already deploys a review app per MR, so DAST can target that URL. Keep it inside budget by limiting the crawl, excluding logout and destructive URLs, running the job in parallel with other scanners, and setting a hard job timeout below the 30-minute limit. This catches issues in the exact code under review, but only for routes the crawler reaches and only after the review app deploys. A slow deploy can still push the pipeline over budget.
Option 2: Scheduled authenticated DAST against staging through a scan execution policy. This costs nothing in the merge request and can scan the full application with credentials. It detects after merge, so it cannot block the MR that introduced the defect. It is a safety net, not a gate.
Option 3: On-demand DAST for high-risk MRs. Trigger DAST as a manual job, or through a policy, only when the diff touches authentication, payment, or session code. The job blocks merge if it fails. This is the best fit for the two payment projects, where a 15-minute scan is defensible; it gives weak coverage for the 36 high-frequency projects.
Recommended mix: scheduled authenticated DAST on staging for all 38 projects; review-app DAST limited to changed routes for the two payment projects and any MR labeled security-sensitive; on-demand scans for incident follow-up. Be explicit with the compliance manager that scheduled DAST findings cannot block a merge, so the merge gate must come from scanners that run in the MR pipeline plus a deployment check against open Critical vulnerabilities.
2. The earlier DAST run produced 140 findings that the team largely called false positives. What tuning and triage changes would make the results actionable, and what should never be dismissed without evidence?
Read the worked answer
Most DAST noise comes from scanning the wrong surface or without context. First, configure authentication so the scanner sees the application as a logged-in user; unauthenticated crawls generate findings on pages that redirect or reject requests. Second, scope the target: exclude logout, delete, and payment-confirmation URLs that mutate state, and cap the crawl depth for large applications. Third, use an OpenAPI specification for the API surface instead of relying on HTML crawling, and disable check categories that do not apply to the technology stack. Fourth, set the scan policy deliberately: a full scan is appropriate for staging nightly, not for every MR.
Triage needs discipline. Every dismissal should carry a reason and a comment with evidence, such as a request and response showing the input is encoded or the endpoint is unreachable. Dismissals should be reviewed by someone other than the author. Track the false-positive rate per rule and per application; a rule that is wrong 90 percent of the time should be disabled globally with a documented rationale, not dismissed 90 times.
Never dismiss a finding merely because exploitation is inconvenient or because the scanner is noisy. Findings on authentication, authorization, injection, and sensitive data exposure need a reproduction attempt before dismissal. Use the vulnerability states Detected, Confirmed, Dismissed, and Resolved, and link confirmed findings to issues so remediation is visible.
3. Only 6 of 38 projects have a security policy project. How would you produce defensible evidence that no Critical finding can merge, and where does that evidence break down?
Read the worked answer
Link a single security policy project at the group level so merge request approval policies apply to all 38 projects without per-project configuration. A policy can require approval when a Critical or High vulnerability is detected in the merge request pipeline, and it can require a named security approver. That gives an auditable policy file, versioned in Git, plus approval records per merge request.
The evidence breaks down wherever the scanner does not run in the merge request. Scheduled DAST and scheduled dependency scans produce findings after merge, so a policy cannot block on them. Container scanning only blocks if the image is built in the MR pipeline; if the image is built on the default branch, the policy sees nothing. Secret detection in a scheduled pipeline has the same gap. State this plainly rather than claiming blanket coverage.
Close the gap with a deployment gate. Before deploying to production, query the vulnerabilities API for open Critical findings on the default branch in that project and fail the job if any exist, with a documented break-glass path that creates an audit event. Pair this with protected branches, required approvals, and a policy that prevents the author from approving their own merge request. Finally, verify enforcement quarterly by sampling merged MRs and checking that the policy evaluated and that no Critical finding existed at merge time.