Breaking the Build to Save the App: A Story of SAST & DAST in Azure DevOps

It was a late Friday evening when the DevOps team at a fintech startup got an urgent message from the security team:

“We’ve found hard-coded secrets in production code. Immediate remediation required.”

The room went silent. The developers knew what this meant—late-night firefighting, patches, and a weekend full of hotfixes. But more than that, they realized something deeper: security wasn’t baked into their pipeline.

That moment became the turning point. They decided to adopt a Shift-Left Security approach—bringing security checks early into their Azure DevOps CI/CD pipelines. This is the story of how they learned to configure and maintain SAST (Static Application Security Testing) and DAST (Dynamic Application Security Testing).

🛠️ Act 1: Discovering the Power of SAST

The team’s first stop was Static Application Security Testing (SAST)—a method to scan source code for vulnerabilities before it ever runs.

They started with Microsoft Security DevOps (MSDO), a native extension in Azure DevOps. With just a few YAML lines, their build pipeline transformed into a security-first checkpoint:

steps:
- task: MicrosoftSecurityDevOps@1
  inputs:
    outputDirectory: '$(Build.SourcesDirectory)/.security'

Suddenly, every pull request was scanned for:

Hard-coded secrets
Insecure coding patterns
SQL injection risks
Dependency vulnerabilities

At first, developers grumbled:

“Why is my build failing for a warning?”

But soon they saw the benefits. No more emergency patches. No more Friday night panic. Security had become part of the developer workflow.

For more mature scanning, they integrated SonarQube, visualizing code smells, bugs, and vulnerabilities in beautiful dashboards. Developers started fixing issues before merging code—a small step that prevented massive downstream risks.

🔍 Act 2: Facing Real-World Attacks with DAST

But code scanning wasn’t enough.
The app needed protection from real-world attackers trying to exploit it in runtime. That’s where DAST came in.

The team chose OWASP ZAP, a lightweight open-source tool, and embedded it into their release pipeline:

steps:
- task: CmdLine@2
  inputs:
    script: |
      docker run --rm -v $(System.DefaultWorkingDirectory):/zap/wrk/:rw \
      owasp/zap2docker-stable zap-baseline.py \
      -t "https://$(testAppUrl)" \
      -r zap_report.html

When the app was deployed to a staging slot, ZAP ran simulated attacks—probing for XSS, CSRF, insecure headers, and more.

The output? An HTML report, uploaded as a build artifact:

- task: PublishBuildArtifacts@1
  inputs:
    PathtoPublish: 'zap_report.html'
    ArtifactName: 'DAST-Reports'

Now, instead of waiting for production incidents, they caught vulnerabilities in pre-production.

📊 Act 3: Making Security a Culture

The real breakthrough wasn’t the tools. It was the culture shift.

Security results were automatically converted into Azure Boards work items.
Pipeline policies blocked deployments if critical vulnerabilities were detected.
Weekly dashboards showed vulnerability trends, helping management track progress.
Developers began treating security just like unit tests: a part of the definition of done.

The team had gone from reactive firefighting to proactive prevention.

⚡ Epilogue: Lessons Learned

Months later, the same fintech team faced an external security audit. The auditors were surprised:

“You’ve embedded SAST and DAST directly into Azure DevOps? That’s enterprise-grade security.”

The once-panicked team had become confident defenders of their codebase.

Here’s what they learned along the way:

SAST belongs in CI: Run static scans on every PR and commit.
DAST belongs in CD: Test running applications in staging/test environments.
Automate everything: From bug creation to dashboarding.
Set thresholds: Don’t block builds for minor issues but fail them for critical ones.
Educate developers: Tools matter, but awareness matters more.