Security integration (DevSecOps)
Security built into every phase of the pipeline. Automated vulnerability scanning, secret detection, compliance checks. Shift security left to find issues early. Security as code, not an afterthought.
Security gate in the pipeline
a1c4e07feat: export invoices to ERP
- Secret scanningWaiting
- Static code analysisWaiting
- Dependency scanWaiting
- Infrastructure scanWaiting
Release gate
Waiting for the security checks
$ dotnet list package --vulnerable --include-transitive
Illustrative example
Security at every stage
Shifting left means finding issues where they are cheapest to fix, without dropping the checks further down the line.
While coding
Analysers in the IDE, secret detection before a commit and branch policies that require a reviewed pull request.
In the build
Static code analysis such as CodeQL, dependency scanning for known vulnerabilities and licenses, and secret scanning on every push.
Before deployment
Infrastructure templates checked against policy, container images scanned, and production approvals recorded.
In production
Microsoft Defender for Cloud for security posture and threat detection, with its alerts flowing into the same on-call process.
Securing the pipeline itself
A pipeline that can deploy to production is a valuable target for attackers. I treat it as a production system.
- No secrets in code or YAML. Secrets live in Azure Key Vault and are read at run time; secret scanning catches anything committed by mistake.
- Workload identity federation. Service connections to Azure use federated credentials instead of stored client secrets that expire or leak.
- Least privilege. Each pipeline identity can deploy only to the resource groups and environments it needs.
- Protected environments. Production deployments require approvals and checks, and every run is logged for audit.
- Trusted, pinned dependencies. Packages come from trusted feeds such as Azure Artifacts, versions are locked, and updates are proposed automatically by tools such as Dependabot or Renovate.
Audit evidence as a by-product
Because every change passes through the same pipeline, you get a traceable record of who changed what, which checks ran and who approved the release. That record supports audits under frameworks such as ISO 27001 or NIS2 with far less manual evidence gathering.