Skip to content
Hez's Docs

What DevSecOps Actually Is: From DevOps Culture to Day-to-Day Practice

“DevSecOps” gets used as a job title, a buzzword, and a pipeline diagram with a padlock icon stuck in the middle. Underneath that, it’s a fairly specific idea, and understanding it starts one layer earlier — with what DevOps actually meant before “Sec” was added to it.

DevOps: a culture before it’s a toolchain

Section titled “DevOps: a culture before it’s a toolchain”

DevOps is often described by its tools — CI/CD, containers, infrastructure as code — but those are the result of a cultural shift, not the definition of it. DevOps emerged as a response to a specific organizational dysfunction: development teams built software and “threw it over the wall” to operations teams, who were responsible for running it but had no say in how it was built. Each side optimized for a different, conflicting goal — dev for shipping change, ops for stability — and the wall between them turned every release into friction.

DevOps is the practice of collapsing that wall: the same people (or at least closely collaborating teams) are responsible for building software and running it in production. A commonly cited framework for what that actually requires is CALMS:

  • Culture — shared ownership and blameless learning from failure, instead of blame when something breaks.
  • Automation — removing manual, error-prone steps from building, testing, and deploying.
  • Lean — small batches of change, shipped frequently, instead of large infrequent releases.
  • Measurement — using real data (deployment frequency, change failure rate, time to recover) to know whether things are actually improving.
  • Sharing — knowledge and incidents are shared across teams, not siloed.

The tools you associate with DevOps — CI/CD pipelines, Docker, Kubernetes, Terraform — exist to make that culture practically possible at scale. But adopting the tools without the culture (a team using Kubernetes while dev and ops still work in separate silos with a ticket-based handoff) is not actually DevOps; it’s the old wall, automated.

From DevOps to DevSecOps

Section titled “From DevOps to DevSecOps”

DevOps solved the dev/ops wall. It didn’t solve a very similar wall that still existed between both of them and security — security teams doing a review at the very end of a release cycle, usually as a gate that either delays shipping or gets skipped under deadline pressure. That’s the same dysfunction DevOps was built to fix, just with a different second team.

DevSecOps is the extension of DevOps culture to include security as a shared responsibility from the start, not a gate at the end. The shorthand for this is “shift left” — moving security activities earlier in the development lifecycle, where issues are cheaper to fix and don’t block a release that’s already built.

Concretely, shifting left means things like:

  • A SAST scan running on every pull request, not a security team reviewing code after it’s merged.
  • Developers writing Terraform that’s checked for misconfigurations before it’s applied, not after an auditor finds an open S3 bucket.
  • Threat modeling happening during design, not as an afterthought once the architecture is fixed.
  • Security findings routed back to the engineer who can fix them directly, through the same tools they already use (a PR comment, not a separate ticketing system weeks later).

The previous article on this site, why a firewall alone isn’t enough, covers the individual tools this touches — SAST, DAST, SCA, IDS/IPS, SIEM. DevSecOps is the practice of integrating those tools into the development and deployment pipeline itself, rather than treating them as a separate team’s concern.

Core principles, in practice

Section titled “Core principles, in practice”
  • Security is everyone’s job, not one team’s job. The security team sets standards, builds guardrails, and handles what automation can’t — but they don’t review every line of code or approve every deploy. That doesn’t scale and recreates the gate problem.
  • Automate the checks, not the judgment. Automated scanning (SAST, DAST, SCA, IaC scanning) handles known, repeatable patterns at the speed of CI. Humans handle novel threats, business-logic flaws, and architectural risk — the things automation structurally can’t catch.
  • Make the secure path the easy path. If doing things securely requires extra manual steps, people will skip it under deadline pressure. A good DevSecOps setup makes the secure default the path of least resistance — a golden container base image with patches already applied, a Terraform module with sane defaults baked in, a service template with auth already wired up.
  • Fail fast, fail cheap. A vulnerability caught in a PR costs a few minutes. The same vulnerability caught in production can cost an incident, a disclosure, and a postmortem. Every stage you push a check earlier reduces the cost of catching the same issue.

Where security fits in the pipeline

Section titled “Where security fits in the pipeline”

Mapping DevSecOps practices onto a standard CI/CD pipeline:

Plan → Code → Build → Test → Release → Deploy → Operate → Monitor
 │       │       │       │       │         │         │         │
 threat  SAST,   image   DAST,   sign &    policy    IDS/IPS,  SIEM,
 model-  secrets scan,   SCA     verify    enforce-  runtime   alerting,
 ing     scan    SBOM            arti-     ment      protect-  incident
                                  facts     (admiss-  ion       response
                                            ion
                                            control)

A concrete example as a CI pipeline:

.github/workflows/pipeline.yml
name: build-test-deploy
on: [pull_request, push]


jobs:
  security-checks:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4


      - name: SAST
        uses: returntocorp/semgrep-action@v1
        with:
          config: p/owasp-top-ten


      - name: Dependency / SCA scan
        run: govulncheck ./...


      - name: Secrets scan
        uses: trufflesecurity/trufflehog@main
        with:
          extra_args: --only-verified


      - name: IaC scan
        uses: bridgecrewio/checkov-action@master
        with:
          directory: infra/


  build:
    needs: security-checks
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Build container image
        run: docker build -t myapp:${{ github.sha }} .
      - name: Scan image for known CVEs
        uses: aquasecurity/trivy-action@master
        with:
          image-ref: myapp:${{ github.sha }}
          severity: CRITICAL,HIGH
          exit-code: 1 # fail the build on critical/high findings


  dast:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - name: Deploy to staging
        run: ./scripts/deploy-staging.sh
      - name: DAST baseline scan
        run: zap-baseline.py -t https://staging.myapp.com

Notice the checks get progressively more expensive and realistic as the pipeline goes on — SAST and secrets scanning are cheap and run on every commit; DAST needs a running environment, so it runs later, against staging, before a production deploy.

What a mid-level DevSecOps engineer needs to know

Section titled “What a mid-level DevSecOps engineer needs to know”

This is a broad role by nature — it sits across development, infrastructure, and security. A mid-level engineer isn’t expected to be an expert in all of it, but should be competent across most of the following and deep in a few:

CI/CD and automation

Section titled “CI/CD and automation”

Building and maintaining pipelines (GitHub Actions, GitLab CI, Jenkins), understanding build caching, artifact management, and how to add quality/security gates without making every PR painfully slow.

Infrastructure as Code

Section titled “Infrastructure as Code”

Terraform or equivalent (Pulumi, CloudFormation) for provisioning cloud resources in a reviewable, version-controlled way, plus the discipline of treating infrastructure changes like code — PRs, reviews, plan-before-apply.

Containers and orchestration

Section titled “Containers and orchestration”

Docker fundamentals (image layers, multi-stage builds, minimizing image size and attack surface) and Kubernetes (Deployments, Services, RBAC, admission controllers, network policies). See the microservices with gRPC, RabbitMQ, and Kubernetes article on this site for how services actually run on top of this.

Cloud platforms

Section titled “Cloud platforms”

Working knowledge of at least one major cloud provider (AWS, GCP, or Azure) — IAM and least-privilege access design, networking (VPCs, security groups), and the provider’s native security tooling (GuardDuty, Security Command Center, Defender for Cloud).

Application security fundamentals

Section titled “Application security fundamentals”

SAST, DAST, and SCA tooling and how to interpret their findings — not necessarily how to build the tools, but how to triage a result, tell a true positive from noise, and know when a finding is actually exploitable versus theoretical. Familiarity with the OWASP Top 10 and OWASP API Security Top 10 as a shared vocabulary with developers.

Secrets and identity management

Section titled “Secrets and identity management”

Why secrets don’t belong in source control or plain environment variables, and how tools like HashiCorp Vault, AWS Secrets Manager, or Kubernetes Secrets (with encryption at rest) are used to manage them. Understanding OAuth 2.0/OIDC well enough to review how services authenticate to each other.

Observability and incident response

Section titled “Observability and incident response”

Structured logging, metrics, and tracing (the same tools covered in the backend engineering concepts article) — but from a security angle: knowing what “normal” looks like well enough to recognize when something isn’t, and participating in incident response when it does.

Scripting and general programming

Section titled “Scripting and general programming”

Enough Python, Bash, or Go to write and maintain automation — custom CI steps, a Slack bot that posts vulnerability summaries, a script that reconciles IAM policies against a baseline. You don’t need to be a senior software engineer, but you need to be comfortable writing and debugging real code, not just YAML.

Compliance literacy (useful, not always required)

Section titled “Compliance literacy (useful, not always required)”

Awareness of common frameworks relevant to the org you’re in — SOC 2, ISO 27001, PCI-DSS, HIPAA — enough to understand why a particular control exists and translate it into something the engineering team can actually implement, rather than treating it as paperwork bolted onto the pipeline.

What the job actually looks like day to day

Section titled “What the job actually looks like day to day”

The title covers a wide range of actual work. A representative (not exhaustive) week might include:

  • Triaging security scan findings from the last few days of CI runs — most are noise or low-severity, a few need a real fix, and figuring out which is which is a constant part of the job.
  • Reviewing infrastructure PRs — a Terraform change opening a new ingress rule, a Kubernetes manifest with an overly broad ClusterRole, a new service missing resource limits.
  • Maintaining and improving CI/CD pipelines — adding a new check, speeding up a slow build, fixing a flaky integration test that’s blocking every deploy.
  • Responding to vulnerability disclosures — a new CVE drops in a widely used dependency; figuring out which of the org’s services are actually affected and coordinating patching.
  • Participating in incident response — when an alert fires (from the SIEM, from monitoring, from an on-call page), helping diagnose what happened, contain it, and write the postmortem.
  • Writing or reviewing threat models for new features or architectural changes, usually in collaboration with the engineers actually building the thing.
  • Automating something that used to be manual — a recurring access review, a certificate rotation, a compliance evidence collection step.
  • Working directly with developers, not just handing down policy — pairing on how to fix a finding, explaining why a control exists, or adjusting a noisy rule that’s wasting everyone’s time.

That last point matters more than the tool list: a DevSecOps engineer who only produces reports and tickets isn’t actually practicing the culture the term describes. The job works when it reduces friction for developers doing the right thing, not when it adds a new gate they have to get past.

A practical learning path

Section titled “A practical learning path”

If you’re building toward this role, roughly in order of leverage:

  1. Get comfortable with Linux, networking, and scripting — the foundation everything else sits on.
  2. Learn Docker and Kubernetes deeply enough to deploy and debug a real application, not just follow a tutorial.
  3. Build and break a CI/CD pipeline — set one up from scratch, then deliberately add security gates (SAST, dependency scanning, image scanning) to an existing one.
  4. Learn Terraform and provision real cloud infrastructure with it, including IAM — most security incidents in cloud environments trace back to overly broad permissions.
  5. Study the OWASP Top 10 and API Security Top 10, and ideally get hands-on with the tools from the security engineering article — SAST, DAST, and a vulnerability scanner.
  6. Pick up one cloud provider’s security tooling in depth, rather than a shallow pass across all three.
  7. Participate in — or simulate — an incident response. Reading a postmortem is useful; being part of writing one, even for a minor incident, teaches more.

Final thought

Section titled “Final thought”

DevOps closed the gap between building software and running it. DevSecOps closes the next gap — between building software and keeping it secure — using the same underlying idea: shared ownership, fast feedback, and automation that supports people instead of replacing their judgment. The tools matter, but they’re in service of that culture, not a substitute for it. A pipeline full of security gates staffed by a team still working in a silo, disconnected from the engineers shipping code, is the wall DevOps was built to tear down — just rebuilt with a different team on the other side.

Learning resources

Section titled “Learning resources”