What is DevSecOps?
DevSecOps doesn't cover the entire scope of a Security team's work. It focuses on applying security practices to the existing responsibilities of a DevOps Engineer: CI/CD, observability, IaC, access management, policies, governance, and so on.
With the growing threat of AI models that can autonomously discover zero-day vulnerabilities, security in general — and security in the software development process specifically — will only get more attention going forward.
How do you measure a DevSecOps team's performance?
At most jobs we have a yearly company goal, which breaks down into department goals, which then breaks down into team goals. Hit the goal and there's a bigger bonus; miss it and things get lean — so let's start with what a DevSecOps team's goals actually look like.
DORA metrics — Deployment Frequency, Lead Time for Changes, Change Failure Rate, and Time to Restore Service — are a fairly common set of metrics for measuring a DevOps team's performance, centered on the DevOps Engineer's goal of speeding up product development. For a DevSecOps Engineer, though, DORA metrics only tell part of the story — on top of them we add a number of security-related metrics, for example:
Depending on the team, you can pick whichever of these metrics feel like the right fit to measure your team with.
What does DevSecOps do differently from a DevOps Engineer?
Building toward a different goal requires the team to work differently, integrating tools and methods to hit the targets above.
CI/CD Pipeline
This is the area that gets built out the most. Instead of just running Build → Test → Deploy, a DevSecOps Engineer adds extra steps:
Before deployment:
- Secrets scanning: Gitleaks
- Static Application Security Testing (SAST): Sonarqube, Semgrep,...
- Dependency scanning: Trivy, Grype, Snyk,...
- Image signing: Cosign
- Container image scanning: Trivy,...
After deployment:
- Dynamic Application Security Testing: ZAProxy, Burp Suite,...
- Runtime threat detection: Falcon, Defender for Containers,...
Infrastructure as Code
IaC is now a standard practice followed by most teams. It's where infrastructure gets built in the first place, so securing it at the source matters a lot. A DevSecOps Engineer makes sure to:
- Integrate static code analysis for Helm and Terraform code: Checkov, tfsec
- Review changes to check: are unnecessary ports being opened? Are permissions misconfigured or overly broad?, etc.
Access and Identity
Instead of granting permissions manually or carelessly to stakeholders, DevSecOps focuses on Zero Trust principles using tools that grant access to developers and other teams:
- No credential lives forever — credentials always expire after a period and a new one must be requested (Managed Identity on Azure, Workload Identity on GCP, etc.)
- Least-privilege by default — users request and get approved for any extra permission they need (PIM on Azure).
- Privileged access is granted for a short window only (PAM)
- Service usernames/passwords get rotated periodically (every 3-6-12 months)
Policies and governance
The easiest way to make sure all resources follow a standard is to build out policy sets applied broadly across resources — rejecting the creation of anything that doesn't comply.
Container workloads (Kyverno, OPA/Gatekeeper,...)
- Only allow signed, trusted images
- Require a non-root user inside containers via K8s
securityContext - Apply network policies to control traffic inside the K8s cluster
- ....
Observability
Sometimes we've done everything to control things at the entry point, but a vulnerability still slips through and ends up in production. That's why continuous monitoring matters — to catch strange, abnormal behavior in the running environment. Here are a few things worth monitoring:
- Detecting privilege escalation inside containers (Falcon, Defender for Containers,...)
- Detecting abnormal numbers of authentication requests (Prometheus exporter & Grafana,...)
- Tracking abnormal input data (tracing tools)
- ....
Incident response
As a DevSecOps Engineer, I believe building out playbooks for responding to security incidents matters just as much. Not just a generic "fix it and restore the system" script. A proper playbook needs:
- Preserving evidence — logs, metrics, traces, etc. — during the incident
- A method for containing the affected part of the system
- Specific actions for each type of threat: data encrypted by ransomware, a DDoS attack, etc.
Wrapping up
Thanks for reading all the way through. This post is based on what I've learned about DevSecOps myself. Security is a huge topic and this post is certainly still missing plenty. If you have other opinions, feel free to leave them in the comments.
Hope this gives you a few ideas for your own work. Have a good day!