Last updated: October 3, 2026
By Robert Ardell, Co-Founder and Strategic Advisor, KORE1
DevSecOps engineer interview questions worth asking in 2026 test whether a candidate can defend the build system itself, keep scanner noise low enough that developers still read it, and respond when a trusted dependency turns hostile. Tool definitions are easy to study. Those three things are not.
Look at what ranks for this search. Explain shift-left. Name three SAST tools. What is the difference between SCA and DAST? How would you add security to a CI/CD pipeline?
Fair questions, every one. They also share a blind spot. Each treats the pipeline as the place where security gets added, a conveyor belt you bolt scanners onto. Nobody asks how the candidate would protect the conveyor belt.
That gap got expensive in March 2025. Between March 12 and March 15, someone compromised a popular GitHub Action called tj-actions/changed-files and pointed its version tags at code that dumped CI secrets into the workflow logs. CISA’s alert lists what leaked, access keys, GitHub personal access tokens, npm tokens, and private RSA keys. Any workflow that referenced the action by tag ran the bad code on its next build. Nobody had to click anything. Nobody had to approve it either.
A payments software company in Tempe had hired a DevSecOps engineer about four months before that weekend. Good hire, by every measure the loop used. He had wired Semgrep and Snyk into their GitHub Actions, tuned the severity gates, and cut the open critical count by more than half. Their public SDK repository used tj-actions by tag. Its logs were public too. He found out from a thread in a community Slack on Monday morning and spent the rest of the week rotating every credential that build could reach.
Was that his fault? Mostly no. Tag pinning was the default almost everywhere. But when the CTO went back through the interview notes, the gap was obvious. Eleven questions about finding vulnerabilities in code. Zero about what runs inside the pipeline with access to production credentials. Nobody had asked, so nobody knew how he thought about it.
Before the questions, the disclosure. KORE1 has filled technical seats since I helped start it in 2005, and our DevSecOps engineer staffing desk, part of a broader cybersecurity staffing practice, fills this one, so we’re paid when a company hires someone we introduced. None of what follows needs us. If you have not yet decided which kind of DevSecOps engineer the role actually is, our how-to-hire walkthrough for this role covers that scoping, including a broken-repository exercise worth running alongside the session below. Pay lives in the DevSecOps engineer salary guide. What’s here is the interview and nothing else.
The Build System Is Where the Keys Live
Think about what a CI runner can touch on an ordinary Tuesday. Cloud credentials to deploy. A registry token to push images. Signing keys, sometimes. Database migration access. A package-publishing token if you ship an SDK. Most companies lock the production console behind SSO, hardware keys, and an approval chain, then hand the same power to a YAML file that pulls code from strangers on every commit. Odd trade.
Attackers noticed years ago. Verizon’s 2025 Data Breach Investigations Report, built on 12,195 confirmed breaches, found the share involving a third party doubled in one year, to 30%. Software dependencies are third parties. So is every action in your marketplace list.
Three incidents from the last two and a half years make the point better than any statistic, and each one translates straight into an interview question.
| Incident | What it abused | The question it hands you |
|---|---|---|
| XZ Utils backdoor, CVE-2024-3094 (March 2024) | A trusted open-source maintainer role, with malicious code shipped in versions 5.6.0 and 5.6.1 | How would you know which of our images contain a specific version of a system library, today? |
| tj-actions/changed-files, CVE-2025-30066 (March 2025) | Mutable version tags on a CI action, plus secrets readable from build logs | What does our pipeline trust that someone else can change without us noticing? |
| Shai-Hulud npm worm (September 2025) | Stolen developer tokens used to publish poisoned versions of more than 500 packages | If a developer’s npm or GitHub token were stolen tonight, what could the thief publish? |
Sources for the table are CISA’s alerts on XZ Utils and the npm compromise, plus the tj-actions alert linked above. A candidate who has worked through even one of these from the inside will tell you about it without being asked. Let them. The story is the interview.
Questions About the Pipeline Itself
Four questions. Each takes ten minutes if the candidate knows the ground and about ninety seconds if they don’t.
“Your workflows pull third-party actions by version tag. What’s wrong with that, and what would you change first?”
A tag is a pointer, and whoever controls the repository can move it. GitHub’s own secure use reference says pinning to a full-length commit SHA “is currently the only way to use an action as an immutable release.” Strong candidates know that cold. Better ones keep going. Pinning by hand rots, so they’d let Dependabot or Renovate propose pin updates as reviewable pull requests, keep a short allowlist of approved actions, and treat any new action like a new dependency with its own review.
The weak answer sounds reasonable. “We only use popular, well-maintained actions.” tj-actions was popular and well maintained.
“A pull request comes in from a fork. Which secrets can that job see?”
You are testing whether they understand triggers. On GitHub, a plain pull_request run from a fork gets no repository secrets and a read-only token. The pull_request_target trigger runs in the context of the base repository, with secrets, which is exactly why GitHub warns that combining it with a checkout of untrusted code exposes the repository. Listen for two follow-ups a senior person brings up unprompted. Setting the GITHUB_TOKEN to the minimum permissions at the top of every workflow. And script injection, where a pull request title or branch name gets pasted into a shell step and runs as code.
GitLab and Jenkins have their own versions of this problem. Protected variables, protected branches, which agents run untrusted builds. The platform matters less than whether they can draw the trust boundary on a whiteboard.
“How does your pipeline authenticate to AWS?”
Short question. Long answer, if they’re good.
You want to hear OpenID Connect federation. The workflow requests a short-lived token, the cloud provider checks claims like the repository and branch, and nothing long-lived sits in the secrets store waiting to be dumped into a log. A senior engineer will mention scoping the trust policy so a feature branch can’t assume the production deploy role, because a trust policy that accepts any branch in the organization is barely better than a static key. If they say the access key lives in repository secrets and gets rotated once a year, you have learned something important about their last employer, and possibly about them. Write it down.
How deep to go on IAM depends on the seat. If cloud identity is the bulk of the job, the questions in our cloud security engineer interview guide will serve you better than these.
“Prove to me that the container running in production was built from this commit.”
Most candidates can’t, and that is fine at mid-level. What you’re listening for is whether they recognize it as a real question. The strong ones talk about build provenance, signed attestations, and verifying the signature at deploy time with an admission controller, so an image that didn’t come from your pipeline never starts. Some will reference the SLSA build levels, where Level 1 means provenance exists but is “trivial to bypass or forge” and Level 3 means forging it requires exploiting a vulnerability “beyond the capabilities of most adversaries.” Nobody needs to recite that. They do need to know the difference between a log that says the build happened and evidence that it did. Big difference.
Admission control is its own rabbit hole. Our Kubernetes engineer interview questions go further into it than a DevSecOps loop usually needs to.
When a Trusted Package Turns
If you run only one scenario in the whole loop, run this one.
Read it to the candidate straight. It’s 10 a.m. CISA has just published an alert that a self-replicating worm compromised more than 500 npm packages, stealing GitHub tokens and cloud API keys from every machine that installed one. Your company ships three Node services and a React front end. Walk me through the first two hours.
Then stop talking. Let the silence do some work.
What good looks like, roughly in order. They find out whether you’re affected before they change anything, using lockfiles, an SBOM if one exists, and the cache in your artifact repository, because the build that matters may have run on Saturday. They work out which credentials were present on any machine or runner that installed a bad version, since the worm’s whole purpose was theft, and they rotate those first. They block the bad versions at the registry proxy so the next build doesn’t reinstall them. CISA’s actual recommendations read almost identically, including pinning to versions published before September 16, 2025, and requiring phishing-resistant MFA on developer accounts for GitHub and npm.
The answer to be wary of starts with “I’d run npm audit.” It isn’t wrong. It just checks for known CVEs in the advisory database, and on day one a fresh compromise may not be in there yet. Somebody who leads with it has mostly been the person reading the scanner, not the person who gets paged.
A good follow-up question, once they’ve finished. How would you decide whether a brand-new dependency gets in at all? Some teams wait a few days before accepting any freshly published version. Some check maintainer count and release history. Some just require a second reviewer on any lockfile change that adds a package. Any of those is a real answer. “The developers decide” is not.
Questions About Noise
Here’s the part of the job that never shows up in a tool demo. A DevSecOps engineer who turns on every scanner at default settings will produce thousands of findings in a week, the developers will learn to click past all of them, and the program will have negative value, because now there’s a dashboard full of red that everyone has agreed to ignore. Ask about noise. It’s the fastest way I know to find out whether someone has actually run a program or only installed one. If the seat is mostly threat modeling and code review rather than pipeline work, you may be closer to an application security engineer hire than a DevSecOps one.
“Your SCA tool shows 1,400 open findings. Which ones get fixed this sprint?”
Weak answer, every critical by CVSS score. Strong answer, it depends on four things, and they can name them.
| Signal | What it tells you | Where it misleads |
|---|---|---|
| CVSS base score | How bad the flaw is in the abstract | Says nothing about whether anyone is exploiting it or whether your code can reach it |
| CISA KEV catalog | Confirmed exploitation in the wild | Lags new attacks, and absence from the list proves nothing |
| EPSS probability | Modeled odds of exploitation in the next 30 days | A forecast, not an observation, and it ignores your environment |
| Reachability and exposure | Whether your code calls the vulnerable function and whether the service faces the internet | Tools disagree, and “unreachable” can change with the next commit |
CISA describes the Known Exploited Vulnerabilities catalog as “the authoritative source of vulnerabilities that have been exploited in the wild,” and it now holds more than 1,700 entries. FIRST defines EPSS as a model estimating “the probability that a published CVE will be exploited in the wild in the next 30 days.” A candidate who sorts the 1,400 by KEV first, then by exposure and EPSS, and then argues with you about where reachability belongs has done this before. You don’t have to agree with their order. You want to see that they have one.
“A gate you own blocked 30 merges this week. How do you find out whether it should exist?”
I like this one because there’s no textbook answer. Good engineers pull the 30 and read them. How many were real? How many were the same false positive on a test fixture? How long did each developer wait, and how many found a way around the gate? Then they make a call. Tune the rule, move it from blocking to warning, or keep it and go explain to the team why it’s worth the friction. Bad engineers defend the gate on principle. Every time.
“Tell me about an exception you approved.”
Every real program has them. A vendor library with an unfixable CVE, a deadline that couldn’t move, a finding that was technically true and practically irrelevant. Ask how it was recorded, who signed, and when it expired. An exception with no expiry date is a permanent hole with paperwork attached. Push on it. If a candidate says they have never approved one, either the program was tiny or someone else was making the hard calls.
Secrets, Including the Ones Already Out
One scenario. Ask it exactly like this. A developer pushes an AWS access key to a public GitHub repository at 4:50 on a Friday. Go.
The first move is to revoke the key. Not delete the commit, not force-push, not open a ticket. Bots scrape public repositories for credentials continuously, so you have to assume it was copied within minutes, and rewriting git history only hides the evidence from you. Revoke first. After the key is dead, they should want to know what it touched, which means pulling CloudTrail for every call made with it. Then prevention, things like push protection on the host, a pre-commit hook such as gitleaks on developer machines, and asking why a long-lived key existed on a laptop in the first place.
Order matters more than vocabulary here. A candidate who says all the right words in the wrong sequence, history rewrite first and revocation third, has read about the incident and has not worked one.
Two Questions That Didn’t Exist Two Years Ago
The first is about regulation, and it only applies if you sell software or connected devices into Europe. Since September 11, 2026, the EU Cyber Resilience Act has required manufacturers of products with digital elements to report actively exploited vulnerabilities through a single platform. The European Commission’s reporting page sets the clock at an early warning within 24 hours of becoming aware, a fuller notification within 72 hours, and a final report no later than 14 days after a fix is available. Twenty-four hours is not much time to work out which shipped versions contain the bad component. So ask. If a vulnerability in one library were confirmed exploited at 9 a.m., could your pipeline tell us by lunch which releases we have shipped that contain it? A candidate who answers with SBOMs generated at build time and stored next to each release is thinking about the right problem. A candidate who would grep the repositories is going to miss the deadline.
U.S. federal suppliers have a cousin of this in NIST’s Secure Software Development Framework, SP 800-218. Whether a candidate has filled out an attestation against it tells you whether they’ve sat on the evidence side of a real compliance conversation.
The second question is about AI. A lot of the code reaching your pipeline in 2026 was drafted by a model, and some of the dependencies it suggests are ones nobody on your team chose. Ask what, if anything, they’d change. There’s no settled answer yet, which is exactly why it’s useful. Nobody has one. I want to hear something concrete. Stricter review on lockfile changes, scanning for packages that don’t exist on the public registry, and rules for what the assistant may access. “AI changes everything about security” is not concrete, and in fairness neither is “ban it.” Our security engineer interview questions go further on securing AI features themselves.
Run It as a Working Session, With Your Own Files
Questions asked across a table get rehearsed answers. So skip the table for one round.
Take one real workflow file from your repository and redact the names. Print last week’s scanner output, or the top 50 findings from it. Give the candidate 45 minutes with both, a pen, and someone from your platform team who can answer questions. Ask them to mark up the workflow with what they’d change and in what order, then sort the findings into fix now, fix later, and close. No laptop required. Paper is fine and slightly better, since it keeps the conversation on judgment instead of tool speed.
A healthcare SaaS company in Salt Lake City ran exactly this with two finalists last spring. On paper they were close. Similar years, similar tools, both certified. The first sorted the 50 findings by severity, flagged eleven criticals, and recommended fixing all of them before the next release. The second asked which services were internet-facing, checked the CVE numbers against the KEV list on her phone, and came back with three that needed fixing that week and a note that two of the “criticals” sat in a test dependency that never shipped. She also circled a pull_request_target trigger in the workflow file that nobody on the panel had noticed. The client hired her. Six weeks in, she had their open-critical count down from just over 600 to 23 that anyone actually needed to care about, and the developers had stopped muting the channel.
That round took one hour. It told them more than the other three combined.
Answers That Should End the Loop
Some weak answers are coachable. Some aren’t. These are the ones I’d stop over.
- “Our scanner shows zero criticals.” A program with zero findings either has no scanner coverage or has suppressed everything inconvenient. Ask which.
- Delete the commit and force-push. Already covered, but it comes up often enough to repeat.
- Security reviews everything before release. Fine at a five-person company. At fifty engineers it’s a queue, and queues get routed around.
- “We pin to major version tags. That’s the standard.” It was, for years. After March 2025, it’s an answer from someone who hasn’t been paying attention.
- They can’t describe a single time they were wrong about severity. Everybody who has triaged at volume has a story about a “low” that turned out to matter. No story usually means no volume.
One more, and it’s subtler. Watch how they talk about developers. “Developers don’t care about security” is a mood, not an answer, and people who carry it into a new job tend to build gates instead of guardrails. The ones who succeed talk about developers the way a good product manager talks about users.
Things We Get Asked Mid-Search
Our engineers use GitLab, and the strongest candidate only knows GitHub Actions. Does that matter?
A candidate who only knows GitHub Actions can do well on GitLab if they explain the trust model in real detail, because runners, secrets scoping, and protected branches map closely between the two platforms.
The syntax takes a couple of weeks to learn. Judgment about what an untrusted build should be able to see takes years. Hire the judgment.
We don’t have a security lead. Who should run these rounds?
Without a security lead, put your most senior platform or DevOps engineer on the pipeline questions and let a product developer score the noise questions, since the developer is the person the new hire has to win over.
If nobody in the building can evaluate the supply chain answers, borrow an hour from a fractional security leader or an outside assessor. That’s cheaper than a wrong hire. Our DevSecOps recruiters can also sit in on a debrief.
Should candidates be allowed to use an AI assistant during the working session?
Allow an AI assistant in the working session if your engineers use one at work, then score what the candidate accepts, what they reject, and whether they catch a suggestion that would weaken the pipeline.
Banning it tests a version of the job that no longer exists. Just say the rule up front so nobody guesses.
What should a strong DevSecOps candidate ask us?
A strong DevSecOps candidate asks who owns the pipeline today, how many open findings exist and how old they are, and whether security can block a release, because they’re checking whether the job can succeed.
A candidate with no questions about your current state is planning to apply a template from their last company. That works sometimes. It’s not what you’re paying for.
Can a candidate describe an incident at a former employer without breaking confidentiality?
Removing the names, systems, and dates that could identify the company, while keeping the sequence of decisions intact, lets a candidate describe a past incident without breaking confidentiality, and how they handle it is part of the test.
If they name the company and the customer without hesitation, that’s how they’ll talk about yours. Weigh it.
Isn’t the supply chain material overkill for a team of twelve engineers?
Supply chain questions aren’t overkill for a twelve-engineer team, because small teams run the same third-party actions and npm packages as large ones, and the tj-actions compromise hit workflows that referenced it by tag regardless of company size.
What changes at twelve is the depth. You probably don’t need someone who has built signed provenance across a hundred services. You do need someone who would pin an action, scope a token, and revoke a leaked key in the right order on a Friday afternoon.
Read Your Own Workflow File First
Before you schedule the first interview, open one of your pipeline files and read it the way an attacker would. What does it pull from outside your organization? What credentials can it reach? Who could change either one without a review? If you can’t answer those, you’ve found the job description, and the questions above will tell you which candidate can.
When you’re ready to fill the seat, talk to a KORE1 recruiter about the search. Across IT roles we average 17 days from intake to hire, and a year after the start date, 92% of our placements are still working there. Most first DevSecOps hires go through our direct hire search. If the work is a defined hardening push with an end date, a contract DevSecOps engineer often makes more sense, and if you’d rather pressure-test the band before the offer, the salary benchmark tool gives you a live number for your market.
