Development teams now ship many times a day through pipelines that hold production credentials, pull thousands of third-party packages and deploy infrastructure from code, and the DevSecOps engineer is hired to make that machinery secure without slowing it down. The role combines software engineering, platform engineering and security: building security checks into CI/CD, hardening the pipeline itself, managing secrets and machine identities, and helping developers fix what the tools find. This guide covers what DevSecOps engineers do, the skills and tools employers test, routes from development, operations or application security, certifications that help and where the role leads. It is written for developers and platform engineers moving into security, application security engineers moving closer to the pipeline, and managers hiring for the role. The practice itself is covered in the DevSecOps Guide; broader routes are in the Cybersecurity Careers Guide.
Key takeaways
- You are an engineer first. Employers expect you to write code, read pipelines and fix build failures; security knowledge without engineering skill does not land in this role.
- The pipeline is an attack surface. Build systems hold deployment keys and run untrusted code, so hardening CI/CD, runners and artefact integrity is as important as scanning application code.
- Signal over noise. A scanner that blocks every build with low-value findings gets switched off; tuning, triage rules and developer-friendly feedback are the real job.
- Machine identity is central. Pipelines, runners and deployment jobs are non-human identities; replacing long-lived secrets with short-lived federated credentials is one of the highest-impact changes you can make.
- Frameworks give you the vocabulary. NIST's SSDF (SP 800-218), the OWASP CI/CD Top 10 and SLSA are what employers and auditors use to describe the work.
What the role does
The NICE Framework (components v2.2.0, April 2025) has no DevSecOps work role; the work spans DD-WRL-003 Secure Software Development, DD-WRL-005 Software Security Assessment and PD-WRL-004 Infrastructure Support. NIST SP 800-218, the Secure Software Development Framework (SSDF) Version 1.1 (final, February 2022), organises secure development into practice groups for preparing the organisation, protecting the software, producing well-secured software and responding to vulnerabilities; DevSecOps engineers implement much of it in tooling. The US Bureau of Labor Statistics notes that software developers determine requirements "such as security".
| Area | Typical work | Read next |
|---|---|---|
| Pipeline security controls | Integrate SAST, dependency (SCA), secret scanning, container image and IaC scanning into CI with sensible gates | CI/CD Security Guide |
| Pipeline hardening | Branch protection, required reviews, runner isolation, least-privilege pipeline permissions, pinned actions and dependencies | GitHub and GitHub Actions Security Guide |
| Secrets and machine identity | Move pipeline secrets to a vault, adopt OIDC federation to cloud, rotate and scope tokens | CI/CD Pipeline Identity Security Guide |
| Supply chain integrity | SBOM generation, artefact signing and provenance, dependency policy | SBOM Guide, Software Supply Chain Security Guide |
| Infrastructure as code | Policy checks on Terraform and similar, guardrails for cloud accounts | Infrastructure as Code Security Guide |
| Containers and Kubernetes | Image baselines, admission control, runtime policy | Kubernetes Security Guide |
| Developer enablement | Secure templates, paved roads, fixing guidance, threat modelling sessions, security champions | Application Security Engineer Career Guide |
Rolling out a new check without breaking delivery
- Baseline: run the tool in report-only mode across repositories and measure finding volume and false positives.
- Tune: disable or downgrade noisy rules, add suppressions with reasons, agree severity thresholds with engineering leads.
- Pilot: enable blocking for one or two willing teams on new findings only, not historic debt.
- Measure: pipeline time added, findings fixed, bypass requests.
- Expand: roll out by team or repository tier, with a documented exception process.
- Rollback plan: a single configuration switch returns the check to report-only if it blocks releases unexpectedly.
Core skills and tools
| Skill | What good looks like | How to practise |
|---|---|---|
| Programming | Comfortable in at least one language (Python, Go, Java, JavaScript or C#) and able to read others; can review a pull request for security bugs | Contribute fixes to an open source project's security issues |
| CI/CD platforms | Write and debug pipeline definitions, understand runners, caching, triggers and permission scopes | Build a pipeline for a sample app with scanning stages |
| Cloud and IaC | IAM roles and policies, network controls, Terraform or similar, state file protection | Deploy a small environment from code and scan it |
| Containers | Dockerfiles with minimal base images, non-root users, image scanning, Kubernetes RBAC and pod security | See the Container Image Security Guide |
| Application security | OWASP Top 10 classes, secure code review, threat modelling, triaging SAST and DAST results | Fix intentionally vulnerable apps and write up root causes |
| Secrets management | Vault patterns, dynamic secrets, OIDC workload federation, detecting leaked keys (T1552 Unsecured Credentials) | See the Secrets Management Guide and Git Secret Scanning Guide |
| Supply chain | SBOM formats, signing and provenance, dependency confusion and typosquatting defences, ATT&CK T1195.002 Compromise Software Supply Chain | Generate and sign artefacts for your sample app |
| Communication | Explains a finding to a developer with a fix, not just a rule ID; negotiates gates with engineering leads | Run a short secure coding session for a team |
Tool categories you will meet: SAST, SCA and dependency management, secret scanners, container and IaC scanners, DAST, policy engines for admission control and IaC, artefact signing tools, secrets managers and ASPM platforms that aggregate findings. Learn the category and its failure modes; specific products change.
Where identity fits
Every pipeline runs as a non-human identity: a CI service account, a runner token, a cloud deployment role, a package registry key. These are high-value targets because they can change production. The OWASP CI/CD Top 10 lists inadequate identity and access management (CICD-SEC-2) and insufficient credential hygiene (CICD-SEC-6) as top risks. DevSecOps engineers who replace stored cloud keys with OIDC federation, scope tokens to a single repository and environment, and alert on pipeline identity misuse make one of the biggest practical security gains. See the GitHub Actions OIDC Federation Hardening Guide and the OWASP CI/CD Top 10 CICD-SEC-6 Insufficient Credential Hygiene Guide.
Routes into the role
- Software developer: strongest base. Volunteer as a security champion, own your team's scanning setup and fix findings across the codebase.
- DevOps, SRE or platform engineer: already owns pipelines and infrastructure; add application security and threat modelling.
- Application security engineer: knows vulnerability classes and code review; add pipeline and cloud engineering depth.
- Cloud security engineer: overlapping skills in IAM and IaC. See the Cloud Security Engineer Career Guide.
- System administrator: automation and Linux depth; build coding and CI/CD skills first.
Market context: DSIT's Cyber security skills in the UK labour market 2026 found automation requested in 15% of core cyber job postings in 2025, up from 11% in 2024, and Microsoft Azure in 16%; Security Engineer roles were 21% of postings. DSIT gives no DevSecOps salary; the mean advertised salary across core cyber roles was £60,800. The US Bureau of Labor Statistics reports a median of $135,980 (May 2025) for software developers, about 1.72 million jobs and projected growth of 10% from 2025 to 2035; that is a broader occupation than DevSecOps.
Portfolio: a public repository with a sample application, a pipeline that runs SAST, SCA, secret, container and IaC scans with documented tuning, signed artefacts with an SBOM, and OIDC-based deployment instead of stored keys is a strong demonstration. Keep it free of real credentials.
Certifications that help
Hiring managers weight demonstrable engineering above certificates, but these structure learning and help screening. Check current outlines and fees with each body; the table is descriptive, not a ranking.
| Awarding body | Certification | Relevance | Facts checked 27 October 2026 |
|---|---|---|---|
| GIAC | GIAC Cloud Security Automation (GCSA) | Cloud-native tooling, DevSecOps practices and security controls across CI/CD pipelines | 75 questions, 2 hours, 66% to pass (versions from 29 June 2024) |
| ISC2 | CSSLP | Security across the software development lifecycle | ISC2 lists four years' required work experience; see the ISC2 CSSLP Certification Guide |
| Linux Foundation and CNCF | Certified Kubernetes Security Specialist (CKS) | Hands-on Kubernetes and container security | See the Certified Kubernetes Security Specialist (CKS) Guide |
| Cloud providers | Cloud security specialty certifications | Provider IAM, logging and guardrails | See the Google Professional Cloud Security Engineer Guide |
| CompTIA | Security+ | Fundamentals for developers new to security | Entry level |
Progression
| Next role | What changes | Build this now |
|---|---|---|
| Senior or staff DevSecOps engineer | Sets platform-wide standards and paved roads | Reusable templates, metrics, influencing engineering leads |
| Product or platform security lead | Owns security for a product line or the internal platform | Threat models, risk decisions, roadmap |
| Software supply chain security specialist | Provenance, signing, dependency governance across the organisation | SLSA levels, SBOM operations. See the NIST Secure Software Development Framework (SSDF, SP 800-218) Guide |
| Security architect | Designs secure systems and patterns across teams | See the Security Architect Career Guide |
| Head of application security | Owns AppSec programme, people and budget | See the AppSec Programme Metrics Guide |
Small versus large employers: in a start-up the DevSecOps engineer may be the whole security team, covering cloud, application and pipeline security at once. In a large organisation the role is usually part of a platform or product security team, with more focus on reusable tooling across hundreds of repositories.
Framework mapping
| Framework | Where DevSecOps work sits |
|---|---|
| NICE Framework v2.2.0 | DD-WRL-003 Secure Software Development, DD-WRL-005 Software Security Assessment, PD-WRL-004 Infrastructure Support |
| NIST SP 800-218 SSDF 1.1 | Practices across preparing the organisation, protecting the software, producing well-secured software and responding to vulnerabilities |
| NIST CSF 2.0 | PR.PS-06 secure software development practices integrated and monitored |
| NIST SP 800-53 Rev. 5 | SA-8 Security and Privacy Engineering Principles, SA-11 Developer Testing and Evaluation, SA-15 Development Process, Standards, and Tools, SR-3 Supply Chain Controls and Processes |
| OWASP CI/CD Top 10 | CICD-SEC-1 to CICD-SEC-10 risks for pipelines, for example CICD-SEC-4 Poisoned Pipeline Execution. See the CICD-SEC-4 Guide |
| MITRE ATT&CK v20 | T1195.002 Compromise Software Supply Chain, T1552 Unsecured Credentials |
Measuring your impact
- Coverage: share of active repositories with the agreed scanning and branch protection baseline.
- Fix rate and time: median days to fix critical and high findings in new code.
- Noise: share of findings marked false positive or suppressed, trending down.
- Pipeline cost: minutes added to build time by security stages.
- Static secrets removed: pipelines moved from stored cloud keys to federated short-lived credentials.
Common failure patterns
- Blocking on day one: enabling hard gates on historic findings, which triggers mass bypasses.
- Scanning code but not the pipeline: runners with broad cloud rights and unpinned third-party actions left untouched.
- Secrets in variables forever: long-lived deployment keys stored in CI settings and never rotated.
- Dashboards nobody acts on: findings aggregated without owners or fix guidance.
- Security as a separate stage: a team that reviews at the end instead of supplying secure templates up front.
Practitioner checklist
- Get fluent in one programming language and one CI/CD platform.
- Build a public sample pipeline with SAST, SCA, secret, container and IaC scanning, tuned and documented.
- Replace stored cloud keys in that pipeline with OIDC federation.
- Generate an SBOM and sign build artefacts.
- Read SSDF 1.1 and the OWASP CI/CD Top 10 and map your pipeline to them.
- Practise rolling out a check in report-only mode, then gating new findings only.
- Pick one certification that matches your gap: cloud, Kubernetes or secure lifecycle.
- Track fix time and noise, not just finding counts.
Standards and references
- NIST: SP 800-218, Secure Software Development Framework (SSDF) Version 1.1
- NIST: NICE Framework current versions
- OWASP: Top 10 CI/CD Security Risks
- MITRE ATT&CK: T1195.002 Compromise Software Supply Chain
- GIAC: Cloud Security Automation (GCSA)
- ISC2: CSSLP certification
- US Bureau of Labor Statistics: Software Developers, Quality Assurance Analysts, and Testers
- DSIT: Cyber security skills in the UK labour market 2026
Related NHI Mgmt Group resources: Cybersecurity Careers Guide · DevSecOps Guide · CI/CD Pipeline Identity Security Guide · Application Security Engineer Career Guide