Integrating DAST in Kanban and CI/CD: A Real World Security Case Study

Arpit Thool; Chris Brown

arxiv: 2503.21947 · v2 · submitted 2025-03-27 · 💻 cs.SE

Integrating DAST in Kanban and CI/CD: A Real World Security Case Study

Arpit Thool , Chris Brown This is my paper

Pith reviewed 2026-05-22 21:55 UTC · model grok-4.3

classification 💻 cs.SE

keywords DASTKanbanCI/CDAgile securitydynamic testingsoftware securitycase studyaction research

0 comments

The pith

A software organization integrated DAST into its Kanban and CI/CD processes and documented the resulting challenges along with workable mitigations from the developers' viewpoint.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper reports an action-research case study inside one development team that added dynamic application security testing to existing Kanban boards and continuous-deployment pipelines. The authors conducted interviews to surface concrete clashes between iterative delivery and sequential security checks, then recorded the adjustments the team made. A sympathetic reader would care because the work supplies a grounded account of how security scanning can be inserted into fast-moving workflows without requiring a separate security phase. The study focuses on real constraints such as pipeline runtime, false-positive handling, and team coordination rather than abstract frameworks.

Core claim

Through interviews and direct observation inside a single organization, the authors found that DAST can be folded into Kanban and CI/CD by shifting scans to feature-branch pipelines, automating ticket creation for findings, and establishing lightweight triage meetings; the same data set also surfaced recurring obstacles around scan duration, environment parity, and developer ownership of remediation.

What carries the argument

Action-research case study that combines process observation with semi-structured interviews of the development team to capture challenges, mitigations, and practices for DAST insertion.

If this is right

Teams can place DAST runs on feature branches so that security findings appear alongside functional defects in the Kanban flow.
Automated creation of security tickets from scan output reduces manual hand-off between security and development roles.
Short, recurring triage sessions between developers and security staff keep remediation inside the existing iteration cadence.
Environment parity checks become a required step before DAST results are considered actionable.
Developer ownership of remediation increases when scan results are presented inside the same tools used for code review.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

The documented practices may still require adjustment when the organization uses different CI/CD tooling or maintains larger codebases.
Similar integration problems are likely to appear when other security activities such as SAST or manual review are added to the same Kanban and pipeline setup.
Repeating the study in organizations of different size or domain would test whether the reported mitigations scale beyond the original context.

Load-bearing premise

Observations and interview responses from one software organization can be treated as representative of the general difficulties and workable fixes when adding DAST to Kanban and CI/CD.

What would settle it

A second independent team that attempts the same integration following the reported practices but encounters a materially different set of blockers or requires entirely different mitigations would undermine the claim that the documented patterns are broadly applicable.

read the original abstract

Modern development methodologies, such as Kanban and continuous integration and continuous deployment (CI/CD), are critical for web application development -- as software products must adapt to changing requirements and deploy products to users quickly. As web application attacks and exploited vulnerabilities are rising, it is increasingly crucial to integrate security into modern development practices. Yet, the iterative and incremental nature of these processes can clash with the sequential nature of security engineering. Thus, it is challenging to adopt security practices and activities in modern development practices. Dynamic Application Security Testing (DAST) is a security practice within software development frameworks that bolsters system security. This study delves into the intersection of Agile development and DAST, exploring how a software organization attempted to integrate DAST into their Kanban workflows and CI/CD pipelines to identify and mitigate security vulnerabilities within the development process. Through an action research case study incorporating interviews among team members, this research elucidates the challenges, mitigation techniques, and best practices associated with incorporating DAST into Agile methodologies from developers' perspectives. We provide insights into integrating security practices with modern development, ensuring both speed and security in software delivery.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Desk Editor's Note private letter to a colleague

Single-org action research case study on DAST in Kanban/CI/CD reports an attempt but gives no method details or data to support its claims.

read the letter

The paper describes one software organization's effort to fold dynamic application security testing into their Kanban process and CI/CD pipelines. They frame it as action research that includes interviews with team members, and the abstract says this yields challenges, mitigation steps, and best practices from the developers' viewpoint. That is the core contribution: a concrete, practitioner-facing account of where security testing bumps against iterative workflows. The focus on real friction points rather than abstract theory is the part that could interest teams doing similar work. The abstract does not supply any numbers, interview protocol, analysis steps, or raw observations, so the claims rest on unspecified single-case notes. The stress-test concern holds: without sample size, transferability arguments, or cross-checks, the reported mitigations read as local rather than general. This is common in case-study work, but it limits how far the findings travel. The paper is aimed at DevSecOps practitioners who want to see how one team handled the integration. Researchers seeking reproducible evidence or broader patterns will find it thin on its own. I would send it for peer review if the full version adds the missing method description and some direct evidence from the interviews; otherwise it stays an experience report that does not need referee time.

Referee Report

1 major / 0 minor

Summary. The manuscript reports an action research case study in one software organization that integrates Dynamic Application Security Testing (DAST) into Kanban workflows and CI/CD pipelines. Using interviews with team members, it seeks to identify challenges, mitigation techniques, and best practices for embedding DAST within Agile development from the developers' viewpoint, with the goal of reconciling iterative development speed with security requirements.

Significance. If the full empirical details and transferability arguments are provided, the work could offer timely practitioner guidance on a practically relevant tension between modern development practices and security engineering, an area of increasing importance given rising web-application attacks. The real-world, developer-perspective focus is a potential strength for relevance in software engineering.

major comments (1)

[Abstract] Abstract: The central claim that the study 'elucidates the challenges, mitigation techniques, and best practices' for DAST integration rests on action research plus interviews inside a single organization, yet the abstract supplies no information on sample size, interview protocol, analysis method, or how organization-specific observations are separated from transferable findings. This single-case design is load-bearing for any claim to generalizable best practices and requires explicit justification or cross-case comparison to support the stated contribution.

Simulated Author's Rebuttal

1 responses · 0 unresolved

We thank the referee for the detailed feedback on the abstract. We agree that methodological transparency is essential to support the claims and will revise the abstract accordingly. The single-organization action research design is intentional for depth, but we will clarify its implications for transferability.

read point-by-point responses

Referee: [Abstract] Abstract: The central claim that the study 'elucidates the challenges, mitigation techniques, and best practices' for DAST integration rests on action research plus interviews inside a single organization, yet the abstract supplies no information on sample size, interview protocol, analysis method, or how organization-specific observations are separated from transferable findings. This single-case design is load-bearing for any claim to generalizable best practices and requires explicit justification or cross-case comparison to support the stated contribution.

Authors: We accept this critique of the abstract. The current abstract is too concise and omits key methodological details. In the revision we will expand it to state the number of interviews, describe the semi-structured protocol and thematic analysis approach, and add a clause noting that the single-case action research yields context-specific insights presented as transferable practices rather than universal generalizations, with fuller justification and limitations discussed in the body of the paper. No cross-case comparison is available, as this is a single-organization study. revision: yes

Circularity Check

0 steps flagged

No circularity: empirical case study with no derivation chain

full rationale

The paper is a single-organization action research case study that reports observed challenges and practices from interviews. It contains no equations, fitted parameters, predictions, uniqueness theorems, or self-citations. The central claim is simply that the study elucidates insights from the described method; this does not reduce to its inputs by construction and requires no load-bearing external citations for validity within the paper's scope.

Axiom & Free-Parameter Ledger

0 free parameters · 1 axioms · 0 invented entities

The central claim rests on the domain assumption that interview data from one team can yield transferable best practices for security integration; no free parameters or invented entities are introduced.

axioms (1)

domain assumption Action research with team interviews can reveal transferable challenges and best practices for integrating security testing into agile development processes
Invoked in the abstract description of the study method and its goal of providing general insights.

pith-pipeline@v0.9.0 · 5695 in / 1185 out tokens · 27969 ms · 2026-05-22T21:55:03.809685+00:00 · methodology

discussion (0)

Forward citations

Cited by 1 Pith paper

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score.

Integrating Log-Based Security Analytics in Agile Workflows: A Real-World Experience Report
cs.SE 2026-05 unverdicted novelty 6.0

A real-world case study of the Red Flag Project shows that log-based security analytics can be integrated into Agile workflows through weekly iterations, but success depends on addressing developer concerns about work...