Integrating Security Feedback into a BDD-Driven Minimum CD Pipeline

Context

This experience report is based on an example system built as part of the book The Effective Software Engineer.
The project’s purpose was to make interactions between otherwise hard-to-combine practices observable in a single CI pipeline, rather than to optimize for feature delivery.

The exploration focused on combining:

BDD-style acceptance testing
Continuous Integration with explicit feedback stages
Automated security feedback (SAST and DAST)

The system was intentionally designed to behave like a real delivery pipeline, while remaining suitable for learning and explanation.

What we explored

BDD-style acceptance tests as executable specifications

BDD-style acceptance tests were used as executable specifications, describing system behavior in domain language and executing against a running system.

This made behavioral claims explicit and continuously verifiable, increasing trust in the system even as it evolved.

Commit stage with early security feedback

The commit stage was kept intentionally fast and included:

Unit tests
Integration tests
Static Application Security Testing (SAST)

SAST ran automatically with each change and surfaced security feedback together with functional feedback, while developers still had full context.

Acceptance stage with runtime security verification

A separate acceptance stage provided slower, system-level feedback:

Full system startup
Execution of BDD-style acceptance tests
Dynamic Application Security Testing (DAST)

DAST exercised the running system, making configuration and interaction issues observable at runtime without slowing down the commit stage.

What worked

Security became observable
Security properties were continuously verified instead of being documented or assumed.
Trust emerged through execution
Executable acceptance tests and automated security checks created confidence in system behavior.
Combining practices became easier
Implementing BDD, CI, and security automation together reduced conceptual friction between them.

Limitations

DAST introduces non-trivial execution time
Automated findings still require judgement
The example does not capture all real-world delivery pressures

Key learning

Security integrates well with Continuous Delivery when treated as feedback, not control.

BDD-style acceptance tests provided a behavioral foundation, while SAST and DAST extended feedback into the security domain without violating Minimum CD principles.