Defender for Cloud DevOps Security: Securing Your Pipelines

I’ve been spending a fair bit of time with Defender for Cloud’s DevOps security capabilities lately. It’s one of those features that’s been quietly getting better while everyone’s been distracted by Copilot news, and honestly? It deserves way more attention than it gets.

The idea is simple enough. Your infrastructure-as-code templates, pipeline definitions, secrets management — it all lives in source control. If you’re already using Defender for Cloud for your runtime environments, catching misconfigurations before they ever get deployed just makes sense.

I know, I know. “Shift left” is one of those phrases that’s been beaten to death. So let me skip the buzzwords and talk about what this actually looks like when you set it up.

Connecting Your Repos

You start in the Defender for Cloud portal under Environment settings. There’s a DevOps security section where you onboard connectors for Azure DevOps, GitHub, and GitLab.

For Azure DevOps, you’ll need:

• An Azure DevOps organisation (obviously)
• The Microsoft DevOps Security extension from the Visual Studio Marketplace
• Project Collection Administrator permissions or equivalent
• A service connection between your Azure subscription and Azure DevOps

GitHub works similarly but through a GitHub App installation. You authorise the Microsoft Security DevOps GitHub App against your organisation and pick which repos to include.

One bit of advice early on — start with a handful of repositories, not everything. You want to understand how noisy it is before you roll it out across the whole organisation. My first attempt at this was a disaster because I connected everything at once and got buried in findings I didn’t have time to triage.

The connector setup itself is pretty smooth these days. Microsoft have improved it a lot since the early preview, which was a bit of a nightmare for permissions if I’m being kind. The official documentation walks through each step.

Infrastructure-as-Code Scanning

Once your repos are connected, Defender for Cloud starts scanning your IaC templates. Coverage includes:

• ARM templates — JSON and Bicep
• Terraform — HCL and plan files
• CloudFormation — for multicloud setups
• Kubernetes manifests — Helm charts included
• Docker files

Under the hood it’s powered by Checkov, Template Analyzer, and Terrascan. Findings show up as recommendations in the Defender for Cloud portal, mapped to specific repositories and files.

The thing I really appreciate is that recommendations include the exact file path and line number. No digging around trying to work out which template has the problem — you get a direct link back to the code.

The most common findings I see across environments tend to be:

• Storage accounts without HTTPS enforcement
• Missing network security group rules
• RBAC assignments in templates that are far too broad
• Key Vault configs missing soft delete or purge protection
• Diagnostic settings that haven’t been configured

None of these are surprising on their own. But they’re exactly the kind of thing that slips through code reviews when everyone’s focused on getting the feature working rather than checking security baselines.

Secret Scanning in Pipelines

This is the bit that really caught my attention. Defender for Cloud can spot exposed secrets in your code repositories — API keys, connection strings, passwords hardcoded in config files. The usual suspects.

It uses pattern matching and entropy analysis to flag potential secrets, and when it finds something it raises a high-severity finding with the file and credential type identified.

I want to be fair here though. The secret scanning is good, but not perfect. I’ve seen false positives crop up, especially with test data that looks like a connection string but isn’t actually sensitive. On the other hand, it caught a couple of genuine service principal credentials that had been sitting in a repo for months without anyone noticing. That one find alone made the setup worthwhile.

If you’ve already got GitHub Advanced Security or Azure DevOps credential scanning running, you’ll get overlap. That’s not necessarily a bad thing — belt and braces and all that — but expect duplicate alerts coming through different channels.

DevOps Security Posture

The posture management view brings it all together in one dashboard. You get visibility across every connected repository with findings broken down by severity. There’s a mapping to the MITRE ATT&CK framework for CI/CD too, which is handy when you need to present to leadership.

The feature I like most is pull request annotations. When you’ve got it configured, Defender for Cloud drops comments directly onto PRs with security findings. That puts the information right in front of the developer when they can actually act on it, instead of it sitting in a security portal they’ll never open.

To set this up, you’ll need the Microsoft Security DevOps Azure DevOps extension or the equivalent GitHub Action in your pipeline definitions.

What It Catches and What It Misses

I’ve run this across several environments now, so here’s my honest take.

Where it does well:

• Picking up common IaC misconfigurations before anything gets deployed
• Finding secrets that have been sitting in repos for ages, forgotten about
• Giving you a single view across multiple DevOps platforms
• PR annotations that actually shift developer behaviour over time

Where it struggles:

• Complex logic flaws in templates go undetected — it’s pattern-based, not contextual
• Custom resource types and newer Azure services don’t always have coverage yet
• Remediation guidance can be a bit vague — it tells you what’s wrong but the suggested fix isn’t always something you’d put straight into production
• The initial noise level can be high. Tuning takes time and patience

Thing is, this isn’t meant to replace a proper secure development lifecycle. It’s a safety net. A really useful one, but still a safety net.

Getting Started

To try this out, you need Defender for Cloud with either the Defender CSPM or Defender for DevOps plan enabled. DevOps security features come with Defender CSPM, so if you’re already paying for that, you’re good to go.

My advice: start with your most critical repos, spend a couple of weeks tuning the findings, then expand from there. Don’t try to do everything at once.

The Defender for Cloud DevOps security documentation is thorough and kept reasonably current. I’d also suggest looking at the Microsoft Security DevOps GitHub Action if you want to see exactly what’s running under the hood.

If you’ve had experience with this — good or bad — I’d love to hear about it. Drop me a message on LinkedIn or Bluesky. Always keen to hear how others are tackling it.