🚀 Welcome to the DevSecOps for Java Series

In this blog series, we’re going to build a real-world, security-first CI/CD pipeline for a Java application, deployed on Azure, using some of the best open-source tools out there.

🚨 What Is DAST?

DAST stands for Dynamic Application Security Testing.

Unlike SAST and SCA (which scan your code and dependencies), DAST tools like OWASP ZAP scan the live, running application — like a real attacker would.

They hit your endpoints, look for:

• • SQL injection
• • XSS (Cross-Site Scripting)
• • Directory traversal
• • Broken authentication
• • and more

This is your last line of defense before something hits production.

☁️ Now That Infra Is Ready…

You’ve built infrastructure using Terraform.
Now let’s put it to use — by deploying your actual Java application onto Azure App Service.

This is where we connect the dots between infra and app deployment.

🧾 Prerequisites

Make sure:

• • Your Java app is packaged as a .jar or .war
• • Terraform has already created the App Service + App Service Plan
• • Your code repo has a working build (e.g., mvn package)
• • The app artifact gets generated into target/ directory

⚙️ Step-by-Step: Deploy Java to Azure App Service

Here’s how we’ll do it:

🏗️ Why Automate Infrastructure Deployment?

Scanning Terraform code is great (and we did that in Part 4),
But at some point, you need to actually provision the infrastructure:
Virtual Networks, App Services, Storage, Event Grid, etc.

Doing it manually = slow, inconsistent, and error-prone.
Using Terraform + Azure Pipelines = automated, repeatable, and secure.

🔧 Pre-requisites

Before we write the pipeline steps, make sure you:

• • Have a working Terraform directory (terraform/)
• • Are using a remote backend (Azure Storage or Terraform Cloud)
• • Have created an Azure service connection in Azure DevOps (SPN with Contributor or least privilege)
• • Store secrets like client ID, tenant ID, and secret in DevOps pipeline variables or key vault

🧪 Terraform Directory Structure

Example layout:

🛠️ Why Infrastructure Code Needs Scanning

We’ve secured:

• ✅ Our libraries with Snyk (SCA)

• ✅ Our application code with SonarQube (SAST)

But what about the Terraform code we use to provision our cloud resources?

If we accidentally expose a public IP, open all ports, or skip encryption, it can create massive security holes — before our app is even live.

That’s why we scan our infrastructure as code (IaC).

🔍 What Is Checkov?

Checkov is an open-source tool from Bridgecrew that scans Terraform (and other IaC formats) for security and compliance risks.

🔎 Why Scan Your Code?

In Part 2, we scanned our dependencies with Snyk (SCA).But what about the actual Java code we write?

That’s where SAST comes in — Static Application Security Testing. It’s a fancy term for “scan your source code for security issues and code quality problems before it’s compiled or deployed.”

We’ll use SonarQube to do exactly that.

🧠 What Does SonarQube Do?

SonarQube scans your code and detects:

🧪 Why Dependencies Can Be Dangerous

You might write a thousand lines of clean Java code — but you’re still importing tens of thousands of lines of someone else’s code via pom.xml.

Azure Subscription Vending – What We Built, Why We Did It, and How It Scales

We didn’t plan to build a subscription vending machine.

Honestly, we were just trying to help one team get their own Azure subscription for a new project. Simple enough. But by the time we set up IAM, applied the right policies, configured budget alerts, enabled Defender, and double-checked tags… we realized something.

We were doing the same setup again.
And again.
And again.