Last updated: October 4, 2026
By Jennifer Burdick, Recruiting Manager, KORE1
A DevSecOps engineer job description should name the CI system, repository count, clouds, open findings backlog, licensed tools, who can bypass a failed security check, and a pay range, typically $120,000 to $195,000 base in 2026. Most postings list tools instead. Tool lists do not tell a candidate what the job is, so the people who could do it scroll past and the people who cannot do it apply.
Security engineering reqs have taken up a bigger share of my desk at KORE1 every year for most of the last decade, and DevSecOps postings are the ones I send back for a rewrite most often. Not because they are short. They are long, usually. Long in the wrong places.
A health-records software company in Durham, North Carolina, called us in January after ten weeks on its own. Roughly 180 engineers. The posting was titled “DevSecOps Engineer” and named twenty-three security tools, from Snyk and Checkmarx to Burp Suite, Nessus, Splunk, and a static analyzer the company had stopped paying for in 2023. “CISSP required.” “5+ years in a security role.” It had drawn 212 applicants. Two hundred twelve. Most of them came from vulnerability management and security operations, and the VP of engineering told me, a little unhappily, that he could not find one who had written a GitHub Actions workflow.
Nothing in the posting asked for that. Nothing in it said what the job was. No wonder the applicants looked the way they did.
So we asked. The company ran GitHub Enterprise Cloud with about 340 repositories, 41 of which deployed to production on AWS, most of them onto EKS. Dependabot showed a little over 4,100 open alerts. Not one production repository had a security check marked as required, which meant any engineer could merge past a failed scan, and several did every week. The SOC 2 Type II renewal was in May. Those five facts were the job, and the VP knew every one of them already.
One afternoon fixed it. The title became “DevSecOps Engineer (GitHub Actions, AWS and EKS, 41 Production Repositories).” The tool list dropped from twenty-three names to six, two of them marked as decisions the new hire would make. The backlog number went in. CISSP moved to the optional list, and the range went up to $160,000 to $185,000 base. Forty-seven people applied over the next three weeks. The company hired a platform engineer from a payments company in Cary, North Carolina, at $176,000, and she started six weeks after the new posting went live.
Our DevSecOps engineer staffing desk sees some version of that posting in most of its intake calls, which is why I wanted to write this one down. Deciding which DevSecOps engineer you need comes first, and our DevSecOps hiring guide sorts the three versions of the job. This page starts after that decision, at the moment someone opens a blank document and has to describe the seat in public.
Here is how KORE1 makes money from this, so you can weigh what follows. Our fee comes due only when a candidate we introduced accepts your offer and starts. A posting like the Durham rewrite sometimes lands a hire on its own, without us, and I think you should have it anyway. Clear postings make my job easier even when they cost me a fee.
A Security Engineer Who Ships Code
A DevSecOps engineer builds security checks into the pipelines that build and deploy software, so code, dependencies, containers, and infrastructure definitions are tested automatically on every change. The role writes pipeline code and policy, not just reports, and usually sits between platform engineering and the security team.
The Bureau of Labor Statistics has no separate code for the role. The closest fit is information security analysts, an occupation with a May 2025 median pay of $129,180 and projected growth of 21 percent from 2025 to 2035, with about 14,100 openings a year. That category also holds SOC analysts, GRC staff, and people who mostly read scanner output. Different jobs. Different people.
That overlap is the trouble. A candidate cannot tell from the words “DevSecOps Engineer” which of those jobs you mean, and the tool list does not settle it either, because a vulnerability analyst and a pipeline engineer have both used Snyk. One of them triaged its findings. The other wrote the workflow that runs it. A senior candidate reading your posting wants to know which one you are hiring, how big the estate is, and whether the security checks have any teeth. Adjectives cannot answer that. Numbers can.
Count What the Engineer Inherits
Seven numbers. Someone with admin rights in GitHub and the AWS console can collect all of them before lunch, and I have yet to meet a security lead who thought publishing them gave an attacker anything useful. Most postings print none.
| The number | Where to find it | How it reads in the posting |
|---|---|---|
| Repositories, and how many deploy to production | Your GitHub or GitLab organization settings | “About 340 repositories. 41 of them ship to production.” |
| The CI system, and whether there is more than one | The workflow folders in those repositories | “GitHub Actions everywhere except two legacy services still on Jenkins.” |
| Clouds, accounts, and clusters | The cloud bill and the account list | “AWS, 14 accounts under one organization, three EKS clusters.” |
| Deploys per week | The deployment history in your CD tool | “Around 120 production deploys a week.” |
| Engineers per security engineer | The org chart | “Two security engineers, counting this hire, for 180 developers.” |
| Open findings today | The dashboards of whatever scanners you run | “Roughly 4,100 open dependency alerts, most of them older than a year.” |
| Security checks that block a merge | Branch protection rules or rulesets | “No security check is required on any production repository yet. Changing that is the first project.” |
Steal the third column. Swap in your numbers. Done.
Look hard at the ratio row. Sole security engineer for 60 developers? That person builds everything, alone, and probably answers the auditor too. Fourth of four for 600 developers is a specialist job with a team behind it. I have watched one finalist light up at the first description and another turn pale at it. Same afternoon. Hide the ratio and you interview people who wanted the other job.
Then the last row. Hiring managers hate printing it. Print it. A check nobody has to pass is a suggestion, and good DevSecOps engineers have met plenty of suggestions. Saying you have zero required checks will not scare them off. For the engineer who wants to be the one who turns them on, that line is why they apply.
A List of Twenty-Three Tools Is Not a Job Description
Tool lists. They are the most common thing I cut from a DevSecOps posting. They get long the same way every time. Someone pastes the security team’s software inventory, someone else adds the tools from a competitor’s posting, and nobody takes anything out. By the time it goes live, the list includes tools the company retired, tools it is evaluating, and at least one product the hiring manager could not describe if asked.
A candidate reads that list and draws one of two conclusions. Either the company wants a person who has used all of them, which describes nobody, or nobody decided what the job is. Neither one makes a strong engineer apply. Both make them close the tab.
Sort your tools into three groups and say which is which.
- We run it today. Name the product and what it covers, such as “Semgrep for static analysis on every pull request” or “Wiz across all AWS accounts.”
- You would choose it. If you have no secrets scanner, or the container scanning is a trial license that expires in March, say the decision belongs to the new hire. Senior candidates like this line more than any other in the posting.
- We are retiring it. One sentence. “We are moving off Jenkins this year” tells a candidate there is a migration in the job, which some will want and some will not.
Six to eight named tools are enough for most postings. Past that? Categories. Software composition analysis, infrastructure-as-code scanning, image signing. An engineer who has done the work will recognize the categories and will not care much which vendor sits in each one, because the next vendor is usually a configuration change away.
Certifications belong in the same conversation, briefly. CISSP is a broad credential aimed at people who design and manage security programs, and asking for it as a requirement on a hands-on pipeline role screens out exactly the engineers the Durham posting was missing. ISC2, which issues it, bills it as a cybersecurity leadership certification. Put it under optional, if at all.
The Backlog Number Recruits for You
An outdoor gear retailer in Portland, Oregon, one that sells almost entirely online, posted a DevSecOps role last spring with a line I have read in some form a hundred times. “Build our security program from the ground up.” About 60 engineers, mostly on Google Cloud, with a monorepo and a scattering of older services.
The ground was not empty. Three scanners were already running, bought by three different people over four years. Between them they reported about 6,800 open findings, and two of the three dashboards had not been opened since the people who bought them left.
The strongest finalist found that out in her third interview, when she asked the director of engineering how many open findings there were and he went to look. She did not mind the number. She had cleared a bigger one at her last job. What bothered her was that the posting had called it a blank page, and she withdrew the next morning with a polite note saying she was not sure what else she had not been told.
Fair. I would have left too.
The company rewrote two sentences. “You will inherit about 6,800 open findings across three scanners, two of which nobody has looked at in a year. You decide which scanner we keep.” The next slate had five candidates, and three of them brought up the backlog in their first call, unprompted, as the reason they applied. The engineer they hired had the count under 900 by the end of her fifth month, mostly by turning off rules that flagged code nobody shipped.
A backlog number does two jobs. It tells a candidate the size of the work, and it tells them you are willing to say true things in writing, which matters more to a security engineer than to most hires. Their whole job is finding the gap between what a system claims and what it does. They will notice the gap in your posting first.
Who Is Exempt From the Gate
Every strong DevSecOps candidate asks it eventually. A security check fails. Who can merge anyway?
The honest answer at a lot of companies is “anyone with admin rights,” and often nobody chose that on purpose. GitHub’s own documentation says that by default, branch protection restrictions do not apply to people with admin permissions on a repository, or to custom roles granted permission to bypass them. Applying the rules to administrators too is an option you have to turn on. Plenty of teams never have. Check yours. So the gate exists, and the people most likely to be in a hurry walk around it.
Your posting does not need to describe your branch settings. It needs one sentence about authority. Who can mark a security check as required? Who approves an exception, and does an exception expire? Can a release manager override a failed check the night before a launch, and does anyone hear about it if they do?
“You will own which security checks are required on production branches, and exceptions go through you and the VP of engineering, with a 30-day expiry.” That sentence tells a candidate the job has teeth. The opposite sentence works too. If it is true. “Security checks report findings, and the owning team decides whether to merge.” Some engineers want an advisory role. Write for them. Just write it down. What costs you finalists is leaving it out, because the good ones will ask in the second interview, and an answer that starts with “well” ends a lot of searches.
Our cloud security engineer job description covers the related question of who owns the fix once a finding lands, and the two lines usually belong in the same paragraph of the posting.
Which Org Chart the Seat Lives On
Colorado Springs, 2025. A defense subcontractor writing ground-station software for satellite programs had us on its DevSecOps search, and its posting read like pure engineering. Pipelines. GitLab. Kubernetes. Infrastructure as code. What it left out was the box on the org chart. The seat reported to the information system security manager, a compliance role, held by a capable man who had never once managed an engineer.
Our first finalist had four years on a platform team and an active Secret clearance. Late in the final round, she wanted to know who would review her merge requests. Silence. Then an honest answer, which was that nobody in software engineering would, so she would have to find reviewers on her own. Would she be in sprint planning? “Sometimes.” Two days later she turned the offer down. The program lead called me afterward, not angry. He said he would have turned it down too.
The org chart got fixed first. The posting second. The seat moved under the director of software engineering, keeping a dotted line to the security manager for accreditation paperwork, and the new posting said so in its second paragraph. One more edit mattered. “Secret clearance required” became “Active Secret clearance required at start. We do not sponsor clearances for this role.” Clearable people stopped applying. On a contract with a fixed start date, clearable and cleared are not the same candidate, and the old wording had been inviting both.
Put the reporting line in the posting, by title. “Reports to the Director of Platform Engineering” and “Reports to the CISO” attract different people. Both are legitimate structures. Candidates care. A lot. They have strong preferences between them, and they should learn which one they are joining from the posting, not from the offer letter.
Pay Follows the Inventory
With the inventory written down, choosing a band is mostly arithmetic. The figures below come from our DevSecOps engineer salary guide, which carries KORE1’s pay data for this role, and I have copied them exactly so the two pages never disagree.
| Level | Typical years | 2026 base salary |
|---|---|---|
| Junior | 0 to 2 | $85,000 to $115,000 |
| Mid-level | 3 to 5 | $120,000 to $155,000 |
| Senior | 5 to 8 | $155,000 to $195,000 |
| Staff | 8 to 12 | $195,000 to $245,000 |
| Principal or lead | 10 or more | $240,000 to $295,000 |
Years are the loosest column in that table. Ignore them a little. The inventory moves the number more. A sole security engineer for 200 developers, expected to make checks required across 40 production repositories and clear a five-figure backlog, is a senior seat whatever the years line says. A third engineer joining an established team to own container scanning is usually mid-level. Price the seat you described, and if the range you were handed does not fit it, change one of the two before posting. A mismatch there is the fastest way to lose a finalist at the offer.
Print the range. In New Jersey you have no choice. The state’s pay and benefits transparency law, in effect since June 1, 2025, covers any employer with at least ten people on payroll for twenty or more calendar weeks that does business or takes applications in the state. For jobs located wholly or substantially in New Jersey, the posting has to show the pay or a pay range, summarize the benefits, and mention any other compensation programs the hire would be eligible for. Several other states have their own versions. Even where nobody requires it, a DevSecOps posting with no range reads to a senior candidate as a number nobody has agreed on yet, and they are usually right.
Pricing one seat in one metro is quicker with our salary benchmark tool, which costs nothing and gives finance a defensible opening number.
DevSecOps Engineer Job Description Template
Fill each bracket from something you can open today, mainly your source control organization settings, your cloud account list, and last week’s scanner export. Anything in brackets marked “For the hiring team” is guidance for you, and none of it belongs in the version candidates see.
Job Title
[DevSecOps Engineer / Senior DevSecOps Engineer / Platform Security Engineer] ([CI system], [cloud and runtime], [N] production repositories) [For the hiring team: the parenthetical is the most important part of the title. It is what makes the right engineer stop scrolling.]
The Team and the Estate
[Company] builds [product] for [customers]. Our engineering organization is [N] developers across [N] teams, and this seat makes [one / two / N] security engineers in total. We run [GitHub / GitLab / Azure DevOps] with about [N] repositories, [N] of which deploy to production on [AWS / Azure / Google Cloud], mostly onto [EKS / AKS / GKE / Lambda / VMs]. We ship to production about [N] times a week.
Where Things Stand
Today we run [tool] for [coverage] and [tool] for [coverage]. [Our dependency and code scanners report about [N] open findings, most of them older than [N] months.] [No security check is required on a production branch yet / Security checks are required on [N] of [N] production repositories.] [For the hiring team: this is the paragraph strong candidates read twice. Use real numbers, even unflattering ones.]
What You Will Do in the First Six Months
- Decide which security checks become required on production branches, and roll them out without stopping the teams that ship most often
- Reduce the open findings backlog to a number the team can actually work, starting with [exploitable / internet-facing / production] code
- Choose and set up [secrets scanning / container image scanning / image signing], which we do not have today
- Write policy as code for [Terraform / Kubernetes admission / cloud guardrails] using [OPA / Kyverno / Sentinel / your choice]
- Replace long-lived cloud keys in CI with short-lived credentials [through OIDC federation]
- [Prepare the evidence for our [SOC 2 Type II / PCI DSS / FedRAMP / HIPAA] review in [month]]
Authority
You will [own which security checks are required on production branches / advise the owning teams, who decide whether to merge]. Exceptions are approved by [you and the VP of engineering / the security lead] and expire after [N] days. Administrators [are / are not yet] subject to the same rules. [For the hiring team: if the honest answer is “anyone with admin rights can merge past a failed check,” say so and say you want that changed. That is a selling point for the right candidate.]
Reporting Line
This role reports to the [Director of Platform Engineering / VP of Engineering / CISO], [with a dotted line to [title] for compliance work].
What You Bring
- [N] or more years building or running CI/CD pipelines, with at least [N] years adding security checks to them
- Working code in [Python / Go / Bash] and comfort reviewing a pull request in a language you do not write daily
- Hands-on experience with [the cloud named above] identity and access management
- Infrastructure as code in [Terraform / CloudFormation / Pulumi]
- Experience making a security check required and handling the pushback that follows
Optional
- [CKS / OSCP / AWS Certified Security Specialty / GIAC credentials] [For the hiring team: none of these should be required on a hands-on role]
- Experience with SBOMs, artifact signing, or provenance attestations
- Prior work in [healthcare / payments / defense / your industry]
Pay, Location, and Clearance
Base pay of $[minimum] to $[maximum] a year, [target bonus of N percent] [and equity]. [One or two lines on health coverage, retirement, and time off.] [Fully remote from [states or time zones] / in the [metro] office on [days] / on site at [facility].] [Active [clearance level] clearance required at start / This role does not require a clearance.] [For the hiring team: in New Jersey and several other states, the range and a description of benefits are required by law for jobs located there.]
What the Platform Lead Crossed Out
Should the title say DevSecOps, or something more specific?
Keep DevSecOps in the title because that is what candidates search for, and add a parenthetical naming the CI system, the cloud, and the production repository count so the title itself does the first round of filtering.
“Platform Security Engineer” draws a slightly more engineering-heavy pool and is worth testing if your first posting is full of analysts. Avoid titles with three nouns stacked in front of “Engineer.” Nobody searches for those.
We are the whole security program. Does the posting have to admit that?
Say it in the second paragraph, because being the only security engineer for an entire engineering organization is a different job from holding one seat on a team, and different people want each.
Some engineers spend years waiting for that job. Others have done it once and never want to again. You want the first group, and the only way to reach them is to say it.
Can one posting cover DevSecOps and application security together?
One posting rarely covers both well, because pipeline automation and secure code review draw different candidates, and a posting that asks for both usually gets strong people in one and weak in the other.
If you truly need both, pick the one you need first and put the other under optional. Our hiring guide lays out how the pipeline, application security, and cloud security versions of this role differ, which helps if the team is still arguing about it.
Is printing a pay range legally required, or just good manners?
$120,000 to $195,000 base covers most mid and senior DevSecOps seats in 2026, and in New Jersey, among other states, posting a range for jobs located there has been a legal requirement since June 1, 2025.
Where it is not required, print it anyway. Security engineers assume the worst about missing information. Habit. They are paid to.
The role needs a clearance. What changes in the posting?
State the exact level, whether it must be active on day one, and whether you will sponsor one, since a cleared engineer and a clearable engineer are different candidates on different timelines.
Also say whether the work happens in a SCIF or other restricted space, and how many days a week. That one line decides more cleared searches than pay does.
Should we name a tool we have not bought yet?
Name the category and say the new hire will choose the product, which most senior DevSecOps candidates read as a sign of trust rather than a gap.
Naming a specific product you are only evaluating backfires. Candidates who dislike it skip the posting, and the candidates who love it may be disappointed when procurement picks something else.
Let the Settings Page Write the First Draft
The Durham engineer made her first security check required on all 41 production repositories in her seventh week. Two teams complained. One of them was right. She changed the rule. By the SOC 2 renewal in May, the auditor’s request for evidence of security testing on every production change took her about an hour to answer, mostly spent exporting results. The VP of engineering forwarded me the email. No comment, just the email.
Nothing in that posting was written from scratch. Every line came from a settings page or a dashboard somebody already had open. That is the whole method. Pull the numbers first and write around them, and the posting will read like a security engineer wrote it, because in a sense one did. Once it is live, our DevSecOps interview questions pick up where the posting leaves off, and the DevSecOps role guide covers the job itself for anyone on the panel who is new to it. If the seat is closer to pipelines than to security, our DevOps engineer job description template may fit better.
When a draft has real numbers in it, send it to our recruiters. We will read it the way a candidate would and tell you which engineers it is likely to pull in. We fill DevSecOps seats as direct hires and through contract staffing when the work is a six-month project, and when we look back a year after placement, 92 percent of the people we sent are still employed by the client.
