Roadmap

DevSecOps Engineer

The engineer who embeds security into every stage of the software delivery pipeline, making security continuous, automated, and invisible to developers rather than a gate at the end of the sprint.

OPTIMISTIC 2–3 yearsREALISTIC 3–4 years

Stage 00

Computer & IT Fundamentals

DevSecOps engineers build automated systems. Understanding how software runs, how infrastructure works, and how data flows is the foundation everything else sits on.

Computer Hardware & OS Basics

CPU, RAM, storage — resource constraints relevant to CI/CD pipeline performance
Kernel vs user space — security boundary in OS
Processes, threads, memory — understanding what containerized apps actually run
File systems — NTFS, ext4, overlay filesystem (Docker layers)
Boot process — how systems start, startup scripts, user data

Number Systems

Binary, hex, decimal — network addresses, memory, log values

How Programs Work

Compile vs interpreted languages — C/Java vs Python/JavaScript execution model
Static vs dynamic libraries — dependency security relevance
System calls — how applications interact with OS (seccomp restriction context)
Package managers — how software dependencies are resolved and installed

Virtualization & Containers

Type 1 and Type 2 hypervisors — cloud VM context
Docker — container isolation model, how it differs from VMs
Container runtimes — runc, containerd, CRI-O
Snapshots — build caching, image layers

Resources

CS50 (Harvard, free)
Professor Messer CompTIA A+ (free YouTube)
Docker getting started (docs.docker.com, free)

Stage 01

Linux & Systems Administration

The CI/CD pipeline, containers, and cloud workloads all run on Linux. You cannot secure what you cannot operate.

Linux Fundamentals

Filesystem hierarchy — /etc, /var, /proc, /sys, /tmp, /usr
Terminal — full command fluency (navigation, file ops, permissions, text processing)
File permissions — rwx, octal, ACLs, setuid/setgid — container security relevance
Users and groups — /etc/passwd, /etc/shadow, /etc/sudoers
Process management — ps, systemctl, cron — pipeline agent context
Package management — apt, yum/dnf, apk — Dockerfile instruction context
Network tools — ss, ip, curl, dig, nmap — connectivity debugging
Bash scripting — variables, conditions, loops, functions, pipes — pipeline automation
SSH — key-based auth, agent forwarding, config files — CI/CD runner authentication

Linux Security Concepts for DevSecOps

Least privilege on Linux — running CI/CD agents as non-root
File permission hardening — world-writable directories in Docker images
Secrets in environment variables — why they leak into process lists and logs
/proc filesystem — process information exposure in containers
Namespace isolation — PID, network, user namespaces in containers
Capabilities — dropping capabilities in container security contexts

Resources

TryHackMe Linux Fundamentals 1/2/3 (free)
OverTheWire Bandit (free)
SS64 reference (free)

Stage 02

Networking Fundamentals

DevSecOps engineers design service mesh security, API gateway rules, and network policies. Understanding the underlying protocols is required.

Core Protocols

OSI model — all 7 layers, attack surface at each
TCP/IP — handshake, ports, UDP, ICMP
IP addressing — subnetting, CIDR, private ranges, IPv6
DNS — resolution, record types, DNS-based service discovery in Kubernetes
HTTP/HTTPS/TLS — web application traffic, certificate management in pipelines
OAuth 2.0 / OIDC — CI/CD authentication to cloud and registries
gRPC — microservice communication, mTLS requirements

Container and Kubernetes Networking

Docker networking — bridge, host, overlay networks, published ports
Kubernetes networking model — every pod gets an IP, no NAT between pods
Services — ClusterIP, NodePort, LoadBalancer, ExternalName
Ingress — HTTP(S) routing, TLS termination
Network Policies — pod-level firewall rules, CNI requirement
Service Mesh — Istio, Linkerd — mTLS between services, traffic management

Cloud Networking Context

VPC, security groups, NACLs — access control for pipeline infrastructure
Private endpoints — keeping CI/CD traffic off public internet
NAT Gateway — private subnet outbound access for build agents

Resources

Professor Messer Network+ (free YouTube)
Kubernetes networking documentation (free)
TryHackMe networking modules (free)

Stage 03

Security Fundamentals

Understanding what you are protecting against: the security half of the DevSecOps equation.

Security Fundamentals

CIA Triad, AAA, threat/vulnerability/risk, attack surface
OWASP Top 10 — the curriculum for application vulnerability classes; DevSecOps engineers configure scanners to catch these
Authentication and authorization — OAuth, JWT, API keys, session management
Cryptography — symmetric, asymmetric, hashing, TLS, PKI, certificate management
Malware and attack patterns — supply chain attacks, dependency confusion, typosquatting
Shared responsibility model — provider vs customer security boundaries
CVSS scoring — understanding vulnerability severity for prioritization
Compliance frameworks — SOC 2, PCI-DSS, HIPAA, FedRAMP — driving pipeline security requirements

Resources

Professor Messer Security+ SY0-701 (free YouTube)
OWASP Top 10 (owasp.org, free)
OWASP ASVS (Application Security Verification Standard, free)

Stage 04

Software Development Fundamentals

DevSecOps engineers need enough development knowledge to understand what they are securing and to communicate credibly with developers.

Programming Languages — Working Knowledge

Python: Syntax, data types, functions, classes, error handling; File I/O, JSON, CSV handling; HTTP requests (requests library) — API integration for security tools; subprocess — executing security tools from Python scripts; Writing custom security scripts and automation
Bash: Full scripting — variables, conditions, loops, functions, pipes, redirection; CI/CD pipeline scripts — build, test, deploy automation; One-liners for security checks in pipeline steps
Go (awareness): Why Go matters — many security tools (Trivy, Grype, Falco, Nuclei) are written in Go; Reading Go code to understand tool behavior and contribute fixes
JavaScript / Node.js (awareness): npm ecosystem — the largest package ecosystem and primary SCA attack surface; package.json, package-lock.json — dependency management; Common vulnerabilities — prototype pollution, command injection in Node

Version Control — Git

Core concepts — commits, branches, merges, rebases, tags
Git workflows — GitFlow, trunk-based development, feature branches
Pull requests and code review — where security gates integrate
Git hooks — pre-commit, pre-push — local security checks before code reaches CI
Secret detection in git history — why committed secrets never fully go away
.gitignore — preventing accidental secret commits
Signed commits — GPG signing, commit provenance

Software Development Life Cycle (SDLC)

SDLC phases — Plan, Code, Build, Test, Release, Deploy, Operate, Monitor
Agile and Scrum — sprint cycles, backlog, story points — DevSecOps integration points
Shift-left security — moving security earlier in SDLC reduces cost by 100x
Secure SDLC (SSDLC) — incorporating security at each phase: Plan — threat modeling, security requirements, abuse stories; Code — secure coding guidelines, IDE plugins, pre-commit hooks; Build — SAST, SCA, container scanning; Test — DAST, IAST, security regression tests; Release — image signing, SBOM generation; Deploy — IaC scanning, admission controllers; Operate — CSPM, runtime security, secrets rotation; Monitor — SIEM integration, anomaly detection, incident response

Package Management and Dependency Management

npm (Node.js) — package.json, lockfiles, npm audit
pip (Python) — requirements.txt, Pipfile, pip-audit
Maven / Gradle (Java) — pom.xml, dependency:check
Go modules — go.mod, go.sum
Cargo (Rust) — Cargo.toml, cargo audit
Dependency confusion attacks — internal package names resolving to public malicious packages
Typosquatting — malicious packages with near-identical names to popular ones

Resources

Python for Everybody (Coursera, free)
Pro Git book (git-scm.com, free)
OWASP SDLC documentation (free)
TryHackMe Git and DevOps rooms (free)

Stage 05

CI/CD Pipelines

CI/CD is the delivery mechanism DevSecOps secures. You must understand pipelines deeply before you can embed security into them.

CI/CD Concepts

Continuous Integration — automatically building and testing on every commit
Continuous Delivery — automatically deploying to staging on every build
Continuous Deployment — automatically deploying to production
Pipeline stages — source → build → test → security scan → artifact → deploy → verify
Artifacts — build outputs (binaries, container images, packages) that move through stages
Pipeline-as-code — defining pipelines in version-controlled YAML/Groovy

GitHub Actions

Workflow structure — name, on triggers, jobs, steps, actions
Triggers — push, pull_request, schedule, workflow_dispatch
Runners — GitHub-hosted (ubuntu-latest) vs self-hosted
Actions marketplace — reusing community actions (actions/checkout, aquasecurity/trivy-action)
Secrets — GitHub Secrets, OIDC token exchange with AWS/Azure
Environments — staging vs production with required approvals
Security hardening: Pinning action versions to commit SHA — not @main; GITHUB_TOKEN minimal permissions — contents: read only; OIDC over long-lived credentials — no static AWS access keys; Protected branches — requiring security check pass before merge

GitLab CI/CD

.gitlab-ci.yml structure — stages, jobs, scripts, artifacts, dependencies
Runners — shared, specific, group runners
Variables — masked, protected, environment-specific
Include and extends — DRY pipeline configuration
Security scanning — GitLab Ultimate built-in SAST, DAST, dependency, container scanning
GitLab security policies — scan execution policies, merge request approval policies

Jenkins

Declarative vs scripted pipelines
Jenkinsfile — pipeline definition in version control
Plugins — security-relevant: OWASP Dependency Check, SonarQube, Aqua Microscanner
Shared libraries — reusable pipeline functions
Jenkins security hardening — matrix authorization, LDAP integration, script approval

ArgoCD and GitOps

GitOps concept — git as single source of truth for Kubernetes state
ArgoCD architecture — application controller, repo server, API server
Sync policies — automated vs manual, self-healing
RBAC in ArgoCD — limiting who can deploy what
Image updater — automated image tag updates
Flux — alternative GitOps tool

Pipeline Security

Secrets management in pipelines — never hardcode, use vault integration or native secrets: GitHub Actions: ${{ secrets.AWS_ACCESS_KEY_ID }} — encrypted at rest; Jenkins credentials binding plugin; Vault Agent integration — dynamic credentials from HashiCorp Vault; OIDC federation — short-lived tokens exchanged at runtime, no stored credentials
Third-party action security — reading action source code before using
Self-hosted runner security — isolation, clean state between jobs, no persistent credentials
Artifact signing — signing build outputs with Sigstore/Cosign
Pipeline attack vectors — environment variable injection, artifact tampering, dependency confusion

Resources

GitHub Actions documentation (free)
GitLab CI/CD documentation (free)
Jenkins documentation (free)
ArgoCD documentation (free)
GitHub Actions security hardening guide (free)

Stage 06

Security Testing in CI/CD (SAST, SCA, DAST)

This is the core of the DevSecOps engineer role: integrating automated security testing tools into the pipeline so developers get feedback in minutes, not months.

SAST (Static Application Security Testing)

What SAST does — analyzes source code without executing it, finds vulnerabilities by pattern matching
When in pipeline — on every pull request, as a required check before merge
False positive challenge — most SAST tools have high false positive rates; tuning is the real skill

SAST Tools

Semgrep — the go-to for custom rules and broad language support: Rule syntax — pattern, message, severity, languages, metadata; Community rules — semgrep-rules repository, 2,000+ rules; Custom rule writing for application-specific patterns (hardcoded AWS keys, unsafe SQL construction); Running — semgrep --config=auto ./src; CI integration — GitHub Actions (returntocorp/semgrep-action), GitLab template; Findings management — suppressing false positives with nosemgrep comments
SonarQube — enterprise SAST and code quality: Quality gates — blocking builds on critical findings; Languages — Java, Python, JavaScript, C#, Go, PHP, Ruby, Kotlin; Rules and profiles — configuring rule sets per language; SonarCloud — SaaS version with GitHub integration
Snyk Code — developer-friendly SAST with IDE plugin and GitHub App
Checkmarx SAST — enterprise-grade, listed in government postings
Veracode — enterprise SaaS SAST
CodeQL — GitHub's semantic code analysis: GitHub Advanced Security — free for public repos; Query libraries — codeql-go, codeql-python, codeql-java; Writing custom queries

SCA (Software Composition Analysis)

What SCA does — identifies vulnerable third-party dependencies
When in pipeline — on every dependency change, and on schedule for new CVE disclosures
Key outputs — vulnerable packages, license violations, transitive dependency exposure

SCA Tools

Snyk Open Source — dependency scanning with fix PRs: Monitors — ongoing vulnerability alerts for tracked repositories; Fix PRs — automatically generating PRs to upgrade vulnerable dependencies; Priority Score — vulnerability severity × reachability
OWASP Dependency Check — open-source SCA for Java, .NET, JavaScript: NVD data source — CVE database integration; HTML and XML reports; Jenkins, Maven, Gradle plugins
Trivy — multi-purpose scanner covering images, file systems, git repos: trivy fs ./src — filesystem scan; trivy image nginx:latest — image scan; trivy repo https://github.com/org/repo — git repo scan; Supports: OS packages, language-specific packages (pip, npm, gem, cargo)
Grype — Anchore vulnerability scanner, fast and accurate
pip-audit / npm audit / cargo audit — language-native vulnerability checks
Renovate / Dependabot — automated dependency update PRs

DAST (Dynamic Application Security Testing)

What DAST does — tests a running application by sending attack payloads
When in pipeline — against deployed staging environment, not production
Limitations — requires running application, slower than SAST, can't find all vuln classes

DAST Tools

OWASP ZAP (Zed Attack Proxy) — the most common open-source DAST: Active scan — automated attack payload injection; Passive scan — traffic analysis without sending attacks; API scan — OpenAPI/Swagger spec-based scanning; GitHub Actions integration — zaproxy/action-full-scan; Configuring scan policy — reducing active checks to fast, high-confidence rules for CI; Alert filters — suppressing known false positives
Nuclei — fast template-based scanner: Community templates — CVE detection, misconfiguration, exposed panels; Custom templates — YAML-based, write app-specific checks; nuclei -target https://staging.example.com -t cves/
Burp Suite Enterprise — scheduled automated scanning of staging environments

IAST (Interactive Application Security Testing)

What IAST does — instruments the running application to detect vulnerabilities during normal test execution
Seeker (Synopsys), Contrast Security — agents embedded in application
Lower false positives than DAST because it sees actual code execution path

Container Image Scanning

Trivy — most widely adopted, integrated into GitHub Actions, GitLab, Jenkins, AWS ECR: trivy image myapp:latest; Severity threshold — --severity HIGH,CRITICAL for build failure; Ignore file — .trivyignore for accepted exceptions
Grype — fast, accurate, good for local development
Snyk Container — fix recommendations for base image upgrades
AWS ECR Enhanced Scanning — Trivy-powered, free basic scanning, Inspector integration
Image scanning policy: Block on Critical findings — fail the build; Warn on High — require review before promotion; Informational on Medium/Low — ticket creation, not build blocking

Secrets Scanning

GitGuardian — pre-commit hooks and CI integration, real-time secrets detection: Detects: AWS keys, GCP credentials, Stripe keys, database URLs, private keys; Historical scan — finding secrets in git history
TruffleHog — git repository secrets scanner: trufflehog git https://github.com/org/repo; Detecting high-entropy strings and known patterns
Gitleaks — pre-commit hook and CI secrets scanner
detect-secrets — Yelp open-source, baseline management
GitHub Secret Scanning — free for public repos, built into GitHub Advanced Security

Resources

Semgrep documentation (semgrep.dev, free)
OWASP ZAP documentation (free)
Trivy documentation (aquasecurity.github.io, free)
Snyk free tier
Nuclei templates (github.com/projectdiscovery/nuclei-templates, free)
OWASP ASVS (free)

Stage 07

Infrastructure as Code Security

DevSecOps engineers own IaC security scanning in the pipeline. This is nearly identical to Stage 6 in the Cloud Security Engineer path; IaC security is shared between both roles.

Terraform Security

HCL syntax — resources, variables, modules, outputs, data sources
Terraform plan analysis — reviewing planned changes for security impact
Common security misconfigurations in Terraform: aws_s3_bucket without aws_s3_bucket_public_access_block; aws_security_group with ingress 0.0.0.0/0 on 22/3389; aws_db_instance with publicly_accessible = true; aws_ebs_volume without encrypted = true; aws_iam_role_policy with Action: ["*"] or Resource: ["*"]

IaC Scanning Tools

Checkov — primary IaC scanner; deep CI/CD integration: checkov -d ./terraform/ — scan Terraform directory; checkov -f template.yaml --framework cloudformation — CloudFormation; checkov -f deployment.yaml --framework kubernetes — Kubernetes manifests; --skip-check — suppressing false positives with justification; Custom checks — Python class extending BaseCheck; SARIF output — integration with GitHub Code Scanning
tfsec — Terraform-specific, fast, good for local development
Terrascan — multi-IaC, Rego-based policies
KICS — Checkmarx IaC scanner, broad IaC coverage
Infracost — cost estimation alongside security scanning (not security but CI companion)
terraform-compliance — BDD-style Terraform testing

Kubernetes Manifest Scanning

Checkov — kubernetes framework
kube-linter — Kubernetes manifest lint and security checks
Conftest — OPA-based policy testing for Kubernetes manifests
kubesec — security risk scoring for Kubernetes resources
Polaris — Kubernetes configuration validation (Fairwinds)

Policy as Code

Open Policy Agent (OPA): Rego language — package, rule, input, data; deny rules — return reason when policy violated; Testing — opa test ./policies/; Conftest — running OPA against IaC files in CI
Kyverno — Kubernetes-native policy engine: validate — blocking non-compliant resources; mutate — automatically fixing resources on admission; generate — creating related resources automatically

Resources

Checkov documentation (free)
tfsec documentation (free)
OPA documentation (openpolicyagent.org, free)
Kyverno documentation (kyverno.io, free)

Stage 08

Container & Kubernetes Security

Kubernetes is the production platform for DevSecOps pipelines and the applications they deploy. Security at the container and cluster level is a core DevSecOps responsibility.

Docker Security

Dockerfile security best practices — non-root user, minimal base image, multi-stage builds, no secrets in ENV
Image scanning in registry — AWS ECR, Docker Hub, Harbor with built-in scanning
Image signing — Cosign/Sigstore: cosign sign image, cosign verify image
Docker daemon security — TLS for remote access, user namespace remapping

Kubernetes Security

RBAC — roles, cluster roles, bindings — service account least privilege
Pod Security — SecurityContext, runAsNonRoot, readOnlyRootFilesystem, dropped capabilities, allowPrivilegeEscalation: false
Pod Security Admission — Privileged/Baseline/Restricted namespace profiles
Network Policies — default deny, explicit allow rules
Secrets management — why Kubernetes secrets are base64 not encrypted, integration with Vault/KMS
Admission controllers — OPA Gatekeeper, Kyverno blocking unsafe pod specs
Runtime security — Falco rules for container behavior monitoring
EKS/AKS/GKE security hardening — managed Kubernetes security features

Resources

Kubernetes security documentation (free)
Falco documentation (free)
Aqua Security Kubernetes security guide (free)

Stage 09

Secrets Management

Secrets sprawl is one of the most common DevSecOps failures. Managing credentials, API keys, and certificates across ephemeral cloud infrastructure is a primary responsibility.

The Secrets Problem

Why secrets leak — environment variables in logs, hardcoded in source, passed as command arguments
Secrets in git history — even after deletion, commits are permanent
Environment variable exposure — /proc/PID/environ readable by processes on same host
CI/CD secret exposure — masked secrets that appear in logs, build artifact leakage

HashiCorp Vault

Architecture — Vault server, storage backends (Consul, DynamoDB, file), seal/unseal
Secret engines: KV (Key-Value) v2 — versioned secrets storage; AWS — dynamic IAM credentials generated on demand, auto-expire; Database — dynamic database passwords with TTL; PKI — certificate authority, automated TLS certificate issuance; Transit — encryption as a service, key wrapping
Authentication methods: Kubernetes auth — pod-level authentication using service account JWT; AWS IAM auth — EC2 instances and Lambda functions authenticate via IAM; GitHub auth — CI/CD pipeline authentication; OIDC — federated identity from any OIDC provider
Vault Agent — sidecar that fetches and renews secrets automatically
Vault Secrets Operator — Kubernetes operator syncing Vault secrets to K8s secrets
Policies — path-based access control in HCL

Cloud-Native Secrets Management

AWS Secrets Manager: Secret storage — JSON, binary, text; Automatic rotation — Lambda-based rotation for RDS, Redshift, DocumentDB; Cross-account access — resource-based policies; Integration — ECS task definitions, Lambda environment variables, SDK
AWS Parameter Store: Standard vs Advanced parameters; SecureString — KMS-encrypted parameters; Hierarchical naming — /production/database/password
Azure Key Vault: Secrets — key-value pairs with metadata; Keys — cryptographic operations; Certificates — managed TLS lifecycle; Managed Identity integration — no credentials needed from Azure resources
GCP Secret Manager: Secret versions — immutable, can be enabled/disabled; IAM binding — service account access to specific secrets; Automatic rotation — Cloud Scheduler + Cloud Functions

Kubernetes Secrets Security

Base64 is not encryption — native Kubernetes secrets are base64-encoded
Encryption at rest — EncryptionConfiguration with KMS provider
External Secrets Operator — syncing secrets from Vault/AWS/Azure into Kubernetes
Sealed Secrets (Bitnami) — asymmetrically encrypted secrets for GitOps workflows
Avoiding secrets in container images — never COPY secrets files into images

Resources

HashiCorp Vault documentation (free)
AWS Secrets Manager documentation (free)
External Secrets Operator documentation (free)
Sealed Secrets GitHub (free)

Stage 10

Threat Modeling

DevSecOps engineers threat model new services and architecture changes before they ship, finding security issues during design review rather than after launch.

Threat Modeling Fundamentals

What threat modeling is — systematically identifying what could go wrong before building
When to threat model — architecture review, new feature design, significant changes
Output — list of threats, mitigations, open risks, and detection approaches

STRIDE Methodology

Spoofing — impersonating a user or system; mitigations: authentication, MFA, certificate validation
Tampering — modifying data in transit or at rest; mitigations: integrity checks, digital signatures, HTTPS
Repudiation — denying actions taken; mitigations: logging, audit trails, non-repudiation mechanisms
Information Disclosure — exposing data to unauthorized parties; mitigations: encryption, access controls, least privilege
Denial of Service — making a service unavailable; mitigations: rate limiting, auto-scaling, DDoS protection
Elevation of Privilege — gaining unauthorized permissions; mitigations: least privilege, input validation, privilege separation

PASTA (Process for Attack Simulation and Threat Analysis)

Seven stages from business objectives through attack simulation
More business-context aware than STRIDE
Common in enterprise security programs

Data Flow Diagrams (DFDs)

Components — external entities, processes, data stores, data flows
Trust boundaries — where security controls should be applied
Building DFDs for microservices — identifying all data flows and trust boundary crossings

Attack Trees

Root node — attacker goal
Child nodes — alternative methods to achieve parent node
Leaf nodes — specific attack steps
Using attack trees to prioritize controls

Threat Modeling Tools

OWASP Threat Dragon — free, web-based, DFD-centric
Microsoft Threat Modeling Tool — free, STRIDE-focused
IriusRisk — commercial, automated threat generation
draw.io — general diagramming for DFDs

Practical Threat Modeling for DevSecOps

PR-based threat modeling — requiring threat model for features touching sensitive data or external endpoints
Architecture review checklist — authentication method, authorization model, data sensitivity, external dependencies, logging coverage
STRIDE applied to a microservice: Spoofing — does this service authenticate callers?; Tampering — is data validated before processing?; Repudiation — are all state changes logged with caller identity?; Information disclosure — does error handling leak internal details?; DoS — is rate limiting applied?; EoP — can a caller escalate privileges through this service?

Resources

OWASP Threat Dragon (free)
OWASP threat modeling cheat sheet (free)
Adam Shostack "Threat Modeling: Designing for Security" (book)
Microsoft SDL threat modeling (free documentation)

Stage 11

Supply Chain Security

Supply chain attacks are a top threat vector in 2026. DevSecOps engineers own software supply chain security, from dependency management through artifact signing.

Supply Chain Attack Landscape

Dependency confusion — attacker publishes public package with same name as internal package; resolver fetches malicious public version
Typosquatting — malicious packages with near-identical names (colo[u]rs, requets)
Compromised maintainer — legitimate package repository account takeover, malicious code injected
Build system compromise — SolarWinds-style attack on the build pipeline itself
Malicious CI/CD actions — untrusted community actions running in privileged contexts

SBOM (Software Bill of Materials)

What SBOM is — machine-readable inventory of all software components and their versions
SBOM formats — SPDX (Software Package Data Exchange), CycloneDX
Generating SBOMs: syft — generates SBOM from images, file systems, containers; cyclonedx-maven-plugin, cyclonedx-npm-module — language-specific SBOM generation; Trivy sbom — image SBOM generation
Using SBOMs for vulnerability scanning: grype sbom:./sbom.json — vulnerability scan of SBOM; Dependency-Track — SBOM management platform, continuous CVE monitoring
SBOM regulatory requirements — US Executive Order 14028 mandates SBOM for federal software

Artifact Integrity

Sigstore / Cosign — keyless artifact signing: cosign sign --key cosign.key image:tag — signing container images; cosign verify --key cosign.pub image:tag — verifying before deployment; Rekor — transparency log for signed artifacts; Fulcio — certificate authority for keyless signing
SLSA (Supply-chain Levels for Software Artifacts): Level 1 — build documented, provenance generated; Level 2 — build service generates provenance, version controlled; Level 3 — isolated build, provenance non-forgeable; Level 4 — two-party review, hermetic builds
in-toto — framework for supply chain integrity

Dependency Management Security

Private package registries — AWS CodeArtifact, JFrog Artifactory, Nexus Repository: Proxying public registries — scanning before caching; Blocking dependency confusion — only allow packages from private registry; License compliance checking
Package pinning — exact version locks prevent unexpected updates: npm: package-lock.json, shrinkwrap.json; Python: requirements.txt with ==version pins, pip-compile; Go: go.sum for module hash verification
Automated vulnerability updates — Dependabot, Renovate: Auto-create PRs for security updates; Test compatibility before merging; Grouping patches to reduce PR noise

Resources

CISA SBOM resources (free)
Sigstore documentation (free)
syft GitHub (free)
Dependency-Track documentation (free)
SLSA framework (slsa.dev, free)

FAQ

Common questions

How long does it take to become a DevSecOps Engineer?

2–3 years optimistic at 20–25 hours/week, 3–4 years realistic part-time. The fastest path is DevOps-to-DevSecOps, because you already have CI/CD fluency and infrastructure automation depth — you only need the security layer. AppSec-to-DevSecOps takes longer because you have to build pipeline operational depth from scratch. Pure security backgrounds without development experience struggle the most. The role is about embedding security into pipelines that ship daily; if you don't grok CI/CD intuitively, you'll struggle.

Which certifications matter for DevSecOps?

AWS Security Specialty for AWS-heavy organizations. AZ-500 for Azure. Certified Kubernetes Security Specialist (CKS) is increasingly listed. CSSLP for the secure development lifecycle frame. Practical contributions to GitHub Actions security workflows, Checkov policies, or OPA Gatekeeper rules signal more than certs. The cert market is catching up to the role; portfolio work outweighs paper for now.

Do I need a CS degree?

No. The path rewards demonstrated CI/CD security implementation more than credentials. Strong scripting (Python, Bash, Go), Infrastructure as Code (Terraform, Pulumi), and container/Kubernetes security are the technical bar. What you do need: production-aware engineering — you've actually owned a deployment pipeline, not just configured one in a tutorial. The DevSecOps market is projected to exceed $17B by 2028; demand outpaces supply because the role barely existed five years ago.

What separates a hired DevSecOps Engineer?

A working CI/CD security pipeline on GitHub. Show one repo with: SAST scanning (Semgrep), SCA (Snyk or Dependabot), container scanning (Trivy), IaC scanning (Checkov), secret detection (GitLeaks), all wired into GitHub Actions with documented gating decisions. Generic 'I know about DevSecOps' candidates lose to candidates with that exact artifact. Bonus differentiators: Kubernetes admission controller policies (OPA, Kyverno), supply chain attestation (Sigstore, SLSA), and dependency review at scale.

DevSecOps Engineer

Common questions

Related roles