There are two talent shortages defining enterprise technology hiring in 2026.
The first is cybersecurity. 4.8 million unfilled roles globally, a regulatory environment that has made security headcount a compliance requirement rather than a discretionary investment, and a threat landscape expanding faster than any education system can train practitioners to defend against it.
The second is DevOps and cloud engineering. 300,000 unfilled roles across Europe alone, demand from AI infrastructure buildout layered on top of cloud migration work that is still far from complete, and a senior practitioner pool being competed for simultaneously by every large organisation running a digital transformation programme.
DevSecOps sits exactly at the intersection of both.
Not adjacent to both. Not drawing loosely from both. At the point where security and DevOps are not two disciplines that need to cooperate, but one integrated practice where the boundary between them has been deliberately dissolved — where security is not a gate at the end of a development pipeline but a property of the pipeline itself, built in from the first line of infrastructure code.
The practitioners who occupy this intersection in 2026 are operating in a market that has two simultaneous shortages competing for one profile. The salary and career trajectory implications of that position are significant. So is the practical challenge of getting there — because the role requires genuine depth in two disciplines that most practitioners have built their careers choosing between.
This guide covers both: the market reality that makes DevSecOps the most strategically positioned technical role of 2026, and the practical path to building the profile that occupies it.
Why DevSecOps Went From Aspiration to Urgent Requirement
The concept of integrating security into the development and operations pipeline is not new. The term “DevSecOps” has existed since at least 2012, and the principle — shift security left, make it a developer responsibility rather than a security team handoff — has been a fixture of technical conference talks for over a decade.
What changed in the 2023 to 2026 period was not the concept but the urgency. Three forces converged to transform DevSecOps from a best-practice aspiration into a non-negotiable operational requirement for organisations deploying software at scale.
Regulatory mandates made it compulsory
DORA — the EU Digital Operational Resilience Act — took full effect across financial services in January 2025, requiring organisations to demonstrate that security testing, vulnerability management, and incident response are embedded in their software development and deployment processes. Not documented in a policy. Demonstrated in practice, with evidence that regulators can examine.
NIS2, covering critical infrastructure across EU member states, carries equivalent requirements for operational technology and connected systems. The UK’s Cyber Resilience Act, the SEC’s cybersecurity disclosure rules for US-listed companies, and FDA software guidance for medical devices all point in the same direction: regulators have moved from accepting security as a stated organisational priority to requiring evidence that it is an operational one.
Organisations that were doing DevSecOps as a philosophical commitment before 2025 have found it much easier to produce that evidence. Organisations that were doing it aspirationally — with a security policy layer sitting above a development pipeline that had no security controls built in — have had to hire, restructure, and rebuild quickly.
The cloud attack surface made it necessary
The expansion of enterprise cloud estates has created an attack surface that perimeter-based security cannot defend. In a world where infrastructure is code, where cloud resources are provisioned through APIs, where development pipelines have access to production environments, and where a misconfigured S3 bucket or an overprivileged IAM role can expose an entire organisation’s data — the separation of security and operations is not just inefficient. It is structurally insufficient.
Traditional security models assumed a defined boundary: inside is trusted, outside is not, and a security team guards the perimeter. Cloud-native architectures dissolve that boundary completely. Security must be embedded in how infrastructure is provisioned, how applications are built, and how deployments are managed — which means it must live in the development and operations pipeline, not in a team that reviews the pipeline after the fact.
AI-generated code raised the vulnerability surface
The adoption of AI coding assistants — GitHub Copilot, Amazon CodeWhisperer, and their equivalents — across enterprise development teams in 2024 and 2025 has materially increased the volume of code being written and deployed. It has also materially increased the vulnerability surface within that code.
AI-generated code is not secure by default. Studies conducted across enterprise development environments in 2025 found that a significant proportion of AI-suggested code contains security vulnerabilities — hardcoded credentials, SQL injection vectors, insecure dependency imports, and authentication logic errors — that developers who are not specifically reviewing for security miss at significantly higher rates than in human-written code, partly because the code reads as confident and correct even when it is not.
DevSecOps practitioners who build automated security scanning into the development pipeline — Static Application Security Testing (SAST), Software Composition Analysis (SCA), secret detection, Infrastructure as Code scanning — catch these vulnerabilities before they reach production. Organisations without this layer are deploying AI-generated vulnerabilities at the speed of AI code generation. The implication for hiring urgency is direct.
What DevSecOps Actually Means: The Role in Practice
DevSecOps is frequently described as a philosophy or a cultural approach, which is accurate and also unhelpful for understanding what practitioners who hold this title actually do from Monday to Friday.
At the core, a DevSecOps engineer is responsible for making security properties of software and infrastructure verifiable, automated, and continuous — removing the human bottleneck of a security review that happens once before a release, and replacing it with automated controls that run on every commit, every build, and every deployment.
In practice, this translates into five areas of technical work:
Pipeline security automation.
Designing and implementing CI/CD pipeline stages that run security checks automatically — SAST tools (Checkmarx, Semgrep, Veracode) that scan code for vulnerabilities, SCA tools (Snyk, Dependabot, OWASP Dependency-Check) that identify vulnerable dependencies, secret scanning tools (GitGuardian, TruffleHog) that detect credentials committed to version control, and container scanning tools (Trivy, Grype) that check container images before deployment. The engineering challenge is integrating these tools without making the pipeline so slow or noisy that developers route around it.
Infrastructure as Code security.
Scanning Terraform, Pulumi, CloudFormation, and Kubernetes manifests for misconfigurations before they are applied to production environments. Tools like Checkov, tfsec, and KICS do this work, but configuring them appropriately for an organisation’s specific cloud environment and compliance requirements is a non-trivial engineering task. IaC security is one of the highest-impact intervention points in cloud security — misconfigured infrastructure is the root cause of a disproportionate share of cloud breaches.
Cloud Security Posture Management (CSPM).
Continuous monitoring of cloud environments for security misconfigurations, compliance violations, and drift from defined security baselines. Platforms like Prisma Cloud, Wiz, and AWS Security Hub provide the tooling; the DevSecOps practitioner designs the detection rules, manages the alert pipeline, and works with engineering teams to remediate findings without becoming a bottleneck.
Developer security enablement.
The cultural and technical work of making security a developer capability rather than a security team dependency. This includes building pre-commit hooks that catch common vulnerabilities before code is even pushed, creating security-as-code libraries that give developers secure-by-default building blocks, running security champions programmes within engineering teams, and building the developer tooling and documentation that makes the secure path the easy path. This is where the cultural dimension of DevSecOps becomes a technical discipline — and where communication skills become as important as engineering skills.
Security observability and incident response integration.
Connecting the security visibility of the development and deployment pipeline with the operational visibility of the production environment — ensuring that security events in production can be traced back to the pipeline decisions that produced them, and that the feedback loop between production incidents and development practices is short, automated, and actionable. SIEM integration, security telemetry pipelines, and the automation of incident response playbooks are the technical manifestations of this work.
The Salary Architecture: What the Intersection Pays
The intersection of two significant talent shortages produces predictable compensation dynamics. DevSecOps practitioners are not competing in a single market; they are effectively competing across two simultaneously — which means that when they receive an offer, the competing offers they are using to benchmark are drawn from both the cybersecurity market and the DevOps market, each already operating above general technology salary levels.
The result is one of the strongest salary profiles in the technical hiring market.
DevSecOps Engineer — £70,000–£100,000
Mid-level practitioners with three to five years of combined DevOps and security experience, demonstrated capability with pipeline security tooling, and at least one relevant certification (AWS Security Specialty, Certified DevSecOps Professional, or equivalent) are pricing in this band in UK markets. London sits at the upper end; regional UK markets and European cities outside London price at 10% to 20% below.
The spread within this band is driven primarily by specialism depth: practitioners who are strong on the cloud security and CSPM side but weaker on the pipeline automation engineering side price lower; those with genuine depth in both the DevOps tooling layer and the security controls layer price higher and convert offers faster.
Senior DevSecOps Engineer — £95,000–£130,000
Senior practitioners with six or more years of experience, a track record of designing and implementing DevSecOps programmes from the ground up (rather than inheriting established tooling), and cross-functional credibility with both engineering leadership and security leadership are in the range most acutely competed for in 2026.
Financial services, defence-adjacent technology, and life sciences organisations are paying at the top of this band and above — driven by regulatory requirements that make the hire non-discretionary and by the specific compliance knowledge (DORA, GxP, ISO 27001, SOC 2) that practitioners in these sectors carry alongside their technical credentials.
DevSecOps Lead / Principal — £120,000–£155,000
Principal and lead practitioners who combine deep technical expertise with the ability to set security engineering strategy, influence engineering culture at the organisational level, and communicate risk posture to executive and board audiences are a genuinely scarce profile. The role at this level is as much about leading change as it is about building tooling — and the communication, stakeholder management, and strategic planning capabilities required are not common in the practitioner population that has the technical depth.
Organisations building DevSecOps capability from scratch — which describes a significant proportion of the enterprise market in 2026 — are seeking this profile to lead the programme, and are finding it among the hardest hires in their technical hiring portfolio.
DevSecOps Architect — £140,000–£180,000
The architect profile — designing the security architecture of development and deployment systems at enterprise scale, across multi-cloud environments, with compliance frameworks embedded in the design — commands premiums that reflect both the rarity of the profile and the strategic importance of the decisions the architect makes. A DevSecOps architecture decision made poorly is a security debt that compounds through every subsequent development cycle. Organisations in regulated sectors understand this and price accordingly.
The Profile Requirements: What Genuine Capability Looks Like
The DevSecOps title has spread faster than the genuine capability it describes — producing a candidate market in which the label is more common than the substance, and in which the organisations seeking genuine depth are developing increasingly precise assessment processes to find it.
Understanding what genuine DevSecOps capability requires — as opposed to what a well-written CV in the space looks like — is essential for both candidates building toward it and organisations attempting to evaluate it.
The non-negotiable DevOps foundation
A DevSecOps practitioner who has added security knowledge to an insufficient DevOps foundation will be able to configure security scanning tools but will not be able to integrate them into a pipeline they do not understand deeply. The DevOps foundation required:
CI/CD pipeline design and operation — not just using existing pipelines but understanding how they are built, where their failure modes are, and how to modify them without breaking the development workflow they support. Git-based workflows, pipeline-as-code (Jenkinsfile, GitHub Actions, GitLab CI), and the operational disciplines of continuous delivery.
Container and orchestration fluency — Docker, Kubernetes, and the security implications of container architectures. Container security is a primary DevSecOps domain: image scanning, runtime security, network policies, secrets management in containerised environments, and the specific vulnerabilities of supply chain attacks on container registries.
Infrastructure as Code depth — Terraform and/or Pulumi to the level of being able to write, review, and secure IaC rather than simply operate it. The practitioner who cannot read Terraform code cannot identify misconfigurations within it.
Cloud platform competency — genuine operational knowledge of at least one major cloud platform (AWS, Azure, or GCP) at the level of understanding how security controls are configured, how IAM policies work, how network security is implemented, and where the most common misconfiguration patterns occur.
The security knowledge layer
Above the DevOps foundation, the security knowledge required is specific rather than broad:
Application security fundamentals — OWASP Top 10 and the specific vulnerability classes it describes: injection attacks, broken authentication, sensitive data exposure, security misconfigurations. The ability to read code and identify common vulnerability patterns, even without being a penetration tester, is required for meaningful code review and SAST tool configuration.
Secrets and credential management — understanding how secrets (API keys, database passwords, certificates, tokens) should be stored, rotated, and accessed in cloud and containerised environments. HashiCorp Vault, AWS Secrets Manager, Azure Key Vault — both the tooling and the principles behind it.
Network security in cloud environments — VPC architecture, security groups, network policies in Kubernetes, private connectivity (PrivateLink, private endpoints), and the network-level controls that limit blast radius when a component is compromised.
Compliance and framework literacy — NIST Cybersecurity Framework, CIS Benchmarks, SOC 2 control requirements, ISO 27001 control domains, and the specific regulatory frameworks relevant to the sector being worked in. This is not theoretical knowledge — it is the ability to translate control requirements into specific tooling configurations and pipeline checks.
The rarest component: the boundary-dissolving capability
The practitioners who are most effective in DevSecOps — and who are consequently most competed for — are not those who have simply accumulated the technical knowledge of both disciplines. They are the ones who can operate fluidly in the intersection: who can have a credible conversation with a security team about threat modelling and then implement the findings as automated pipeline controls that developers will actually use.
This boundary-dissolving capability requires something that certification cannot directly teach: genuine comfort in both professional communities, understanding of both professional vocabularies, and the ability to translate between them in both directions. The security professional who can tell a developer what to fix but cannot help them fix it in a way that fits their workflow is not operating in the intersection. The DevOps engineer who can build any pipeline stage asked of them but cannot independently identify what security controls that stage should contain is not operating in the intersection.
Building genuine intersection capability takes time and deliberate exposure to both sides of the boundary — not as a student of each, but as a practitioner contributing to real work in both domains.
The Path In: Two Entry Routes and What Each Requires
DevSecOps practitioners in 2026 are arriving from two primary backgrounds, and the path from each requires different emphasis.
From DevOps and Cloud Engineering
DevOps engineers moving into DevSecOps are starting from the stronger foundation for the role’s engineering demands. The pipeline knowledge, the IaC fluency, the cloud platform understanding — these are already present and need to be extended rather than built.
What needs to be added:
Security certification to signal the transition. The AWS Certified Security Specialty or the Microsoft SC-200 (Security Operations Analyst) signals cloud security knowledge to hiring managers who may not be able to assess it through conversation alone. The Certified DevSecOps Professional (CDP) from Practical DevSecOps is the most directly relevant certification available, combining pipeline security concepts with hands-on assessment.
Deliberate exposure to application security tooling. Installing, configuring, and integrating SAST, DAST, SCA, and secret scanning tools in a real pipeline — even a personal project — produces the hands-on familiarity that enables credible technical conversation about these tools in interviews and in practice.
Security community engagement. OWASP local chapters, security-focused meetups, and security-oriented conference tracks (Black Hat, BSides, OWASP AppSec) expose DevOps practitioners to security thinking, vocabulary, and problem framing that builds the boundary-dissolving capability described above. This is not credential-building. It is perspective-building, and it takes time.
From Cybersecurity
Security practitioners moving into DevSecOps need the inverse emphasis: the security knowledge is present; the DevOps engineering foundation needs development.
What needs to be built:
Practical DevOps and pipeline engineering skills. This means building CI/CD pipelines, not just running vulnerability scans against them. Setting up GitHub Actions or GitLab CI pipelines for real projects. Writing Terraform or Pulumi to provision cloud infrastructure. Building and deploying containerised applications. The security practitioner who has only ever examined DevOps systems from the outside is not ready to build security into them from the inside.
Cloud platform engineering depth. A security practitioner who holds a cloud security certification but has not operated cloud infrastructure operationally — provisioning resources, managing access, troubleshooting deployments — will struggle with the engineering demands of DevSecOps roles. Hands-on cloud engineering experience, even through personal projects or lab environments, is necessary to develop the platform intuition required.
Developer empathy. The security mindset, when applied to development teams, can produce friction — security controls that are burdensome, alerts that are too noisy, gates that slow pipelines without proportionate risk reduction. The security practitioner moving into DevSecOps needs to develop genuine understanding of developer workflow, velocity concerns, and the business cost of security that adds friction. The best DevSecOps practitioners are security advocates who make security easier for developers, not security enforcers who make development harder.
How AI Is Changing the DevSecOps Role
AI is not a peripheral influence on DevSecOps in 2026 — it is restructuring two central aspects of the role simultaneously.
On the threat side: AI-generated code, as described earlier, is creating new vulnerability patterns at new velocities. The static analysis tools that were calibrated for human-written code are being retrained and reconfigured for AI-generated code patterns, and the DevSecOps practitioners responsible for those tools are having to understand the specific vulnerability signatures of AI-assisted development to configure detection appropriately.
On the tooling side: AI is being integrated into the security tooling layer itself. SAST and CSPM platforms are adding AI-powered analysis that reduces false positive rates, prioritises findings by exploitability rather than just severity, and suggests remediations that are specific to the codebase being analysed. DevSecOps practitioners who understand how to evaluate, configure, and govern AI-enhanced security tooling — and who understand its failure modes, including the overconfidence in AI-generated remediation suggestions that parallels the vulnerability risk in AI-generated code — are ahead of the practitioners treating these tools as black boxes.
The net effect: the DevSecOps role in 2026 requires not just security and DevOps knowledge, but a specific understanding of how AI changes both the threat environment being defended against and the tooling being used to defend it. This is the AI crossover dimension of the role, and it is evolving quickly enough that practitioners who are actively tracking it — through community engagement, tool experimentation, and deliberate learning — have a meaningful advantage over those who are not.
The Career You Are Building
The argument for DevSecOps as a career investment in 2026 is not primarily about the current salary premium, though the premium is real and significant. It is about the structural durability of the position.
The two shortages that create the intersection — cybersecurity and DevOps — are both structural, not cyclical. Neither is expected to materially ease before the end of the decade. The regulatory pressure driving mandatory security investment is increasing, not plateauing. The cloud and AI infrastructure work driving DevOps demand is in its middle innings, not its final ones.
The practitioner who builds genuine depth at the intersection of these two disciplines is building a career position that is structurally defended from the automation and commoditisation that is narrowing the value of more specialised roles elsewhere in the technology market. The judgment required to design security into complex, AI-augmented, cloud-native development systems — and to do so in a way that improves rather than impedes development velocity — is not a judgment that AI tools can replace. It is precisely the kind of human judgment that becomes more valuable as AI handles more of the routine work around it.
DevSecOps in 2026 is not the easiest technical career to build. It requires genuine competency in two disciplines that most practitioners choose between. Communication skills is required to operate across the security-development boundary. It also requires continuous learning in a field where both the threat environment and the tooling are evolving at unusual speed.
What it offers in return is a position at the intersection of the two biggest talent shortages in technology — where two markets are competing for one profile, where the work is genuinely consequential, and where the investment in building the capability compounds into one of the most durable career positions the technical hiring market currently has to offer.
